Just don't mention singletons!
Hmm that was exactly what I was going to do but in the end decided I wouldn't ;)
What's more is that it is always possible that you'll have to add a preference later where you didn't anticipate it, so you'd have to redo all functions that leadI've not quite with you. If you make you preferences an object or a struct all you will need to do is add a new data member and recompile.
What I meant was that at one point you need to access a preference in a function somewhere deep inside a class where you originally didn't need access to the preferences object so you didn't provide access (through a pointer/reference). Then you have to update all calls that lead or can lead you into the function where you need the preference, which can be quite a bit of work (and break all other code). Of course the standard response to this is 'if you designed your code well, there is very little code to change', but as we all know, in The Big Bad Real World this isn't always true (inherited legacy code, code that wasn't 'designed' but just sort of 'grew' over time, ...).
I think you're wrong.
OK then :)
How do you suggest handling this without globals?As you suggest above you should create your preferences object at the highest level and pass it around by reference or pointer.
I was secretly hoping that you would show me a cool trick that would allow me to get rid of all globals in my code, but alas :) I have too
many callback functions and other cases for this to be the way to go for me.
Like I mentioned before, I used to be religiously against globals after working on a project where 90 % of all variable were global, but I think that the no-global dogma is just that: a dogma and that it should be looked upon with a healthy dose of skepticism: globals are bad, but I stand by my opinion that every now and then they have their place, even in modern C++ design.
cheers,
roel
