Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualnoizex

Posted 03 January 2013 - 06:41 AM

I try to design without globals in mind, but things like debugger/profiler that I have to use and I _need_ access to it from basically every part of my code to dump something on the screen or profile execution just require some kind of global var / singleton (which I don't like and prefer just typical global variable). I tried hard to figure how to pass it around and having it passed through all object chains because I may need it at some point is just plain stupid IMO.

Instead I just create a global instance of Debugger class and in any .cpp file that I need access to it to dump some data or profile part of the code, I use extern. I really can't see how this can be done better - I can't use global functions because I need a state (debug drawing requires geometry to be compiled and drawn each frame etc, so instead of one class I'd have to get some global variables anyway and it will be ugly). Its also only for debugging, so in release mode my code is global free anyway.

I think people who are 100% against globals are some hard to convince OO-freaks.

#6noizex

Posted 03 January 2013 - 06:41 AM

I try to design without globals in mind, but things like debugger/profiler that I have to use and I _need_ access to it from basically every part of my code to dump something on the screen or profile execution just require some kind of global var / singleton (which I don't like and prefer just typical global variable). I tried hard to figure how to pass it around and having it passed through all object chains because I may need it at some point is just plain stupid IMO.

Instead I just create a global instance of Debugger class and in any .cpp file that I need access to it to dump some data or profile part of the code, I use extern. I really can't see how this can be done better - I can't use global functions because I need a state (debug drawing requires geometry to be compiled and drawn each frame etc, so instead of one class I'd have to get some global variables anyway and it will be ugly). Its also only for debugging, so in release mode my code is global free anyway.

I think people who are 100% against globals are either OO-freaks.

#5noizex

Posted 03 January 2013 - 06:41 AM

I try to design without globals in mind, but things like debugger/profiler that I have to use and I _need_ access to it from basically every part of my code to dump something on the screen or profile execution just require some kind of global var / singleton (which I don't like and prefer just typical global variable). I tried hard to figure how to pass it around and having it passed through all object chains because I may need it at some point is just plain stupid IMO.

Instead I just create a global instance of Debugger class and in any .cpp file that I need access to it to dump some data or profile part of the code, I use extern. I really can't see how this can be done better - I can't use global functions because I need a state (debug drawing requires geometry to be compiled and drawn each frame etc, so instead of one class I'd have to get some global variables anyway and it will be ugly). Its also only for debugging, so in release mode my code is global free anyway.

I think people who are 100% against globals are either OO-freaks.

#4noizex

Posted 03 January 2013 - 06:40 AM

I try to design without globals in mind, but things like debugger/profiler that I have to use and I _need_ access to it from basically every part of my code to dump something on the screen or profile execution just require some kind of global var / singleton (which I don't like and prefer just typical global variable). I tried hard to figure how to pass it around and having it passed through all object chains because I may need it at some point is just plain stupid IMO.

Instead I just create a global instance of Debugger class and in any .cpp file that I need access to it to dump some data or profile part of the code, I use extern. I really can't see how this can be done better - I can't use global functions because I need a state (debug drawing requires geometry to be compiled and drawn each frame etc, so instead of one class I'd have to get some global variables anyway and it will be ugly). Its also only for debugging, so in release mode my code is global free anyway.

I think people who are 100% against globals are either OO-freaks or some kind of hard to convince fanatics.

#3noizex

Posted 03 January 2013 - 06:40 AM

I try to design without globals in mind, but things like debugger/profiler that I have to use and I _need_ access to it from basically every part of my code to dump something on the screen or profile execution just require some kind of global var / singleton (which I don't like and prefer just typical global variable). I tried hard to figure how to pass it around and having it passed through all object chains because I may need it at some point is just plain stupid IMO.

Instead I just create a global instance of Debugger class and in any .cpp file that I need access to it to dump some data or profile part of the code, I use extern. I really can't see how this can be done better - I can't use global functions because I need a state (debug drawing requires geometry to be compiled and drawn each frame etc, so instead of one class I'd have to get some global variables anyway and it will be ugly). Its also only for debugging, so in release mode my code is global free anyway.

I think people who are 100% against globals are either OO-freaks or some kind of hard to convince fanatics.

#2noizex

Posted 03 January 2013 - 06:40 AM

I try to design without globals in mind, but things like debugger/profiler that I have to use and I _need_ access to it from basically every part of my code to dump something on the screen or profile execution just require some kind of global var / singleton (which I don't like and prefer just typical global variable). I tried hard to figure how to pass it around and having it passed through all object chains because I may need it at some point is just plain stupid IMO.

Instead I just create a global instance of Debugger class and in any .cpp file that I need access to it to dump some data or profile part of the code, I use extern. I really can't see how this can be done better - I can't use global functions because I need a state (debug drawing requires geometry to be compiled and drawn each frame etc, so instead of one class I'd have to get some global variables anyway and it will be ugly). Its also only for debugging, so in release mode my code is global free anyway.

I think people who are 100% against globals are either OO-freaks or some kind of hard to convince fanatics.

PARTNERS