Hi > 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, ...).
Yes, I see your point. Unfortunately this sort of refactoring is common place. However, your unit tests should allow you to refactor with confidence as you know they'll pick up any bus you inadvertently add. You do have unit tests, don't you? ;-) > > > 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. There is a nice work around for this. Starting getting into the habbit of using factories. Then you can add a reference to your preference object to the factory and get the factory to automatically pass the reference on when it creates the objects. Btw, what sort of "callbacks" are you using? This strickes me a C type thing, rather than a C++ one. Are you using the WIndows API or something? Regards Paul Paul Grenyer Email: [EMAIL PROTECTED] Web: http://www.paulgrenyer.co.uk Have you met Aeryn: http://www.paulgrenyer.co.uk/aeryn/? Version 0.3.0 beta now available for download.
