Trouble with prefixes and suffixes is that they don't mix with auto generated accessors and mutators.
Trouble with prefixes and suffixes is that they don't mix with auto generated accessors and mutators.
Last edited by King Mir; 09-08-2009 at 04:52 PM.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
I see. I couldn't think of any situation in which a class could not access private members of another instance of the same class, though I did wrack my brain (static variables? variables inherited from some base class?).
I laughed when I read that (no offense, I just thought it was funny) . . . not sure if it was intentional, but the term is usually "mutators".mutilators
*sneaks up behind prefixed member variable and beats upon bits with handy bitmask*
"That's one for unsuffix'd-kind!"
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
Yeah, I spelled it like that first, but my spell check picked it up, and I obviously didn't look closely enough at the choices. Fixed now.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Why have accessors at all? That's like saying "I, as the implementor of this class, do not know how the thing I am implementing is implemented, therefore I will protect myself from my own implementation changes by making my own implementation inaccessible to myself."Originally Posted by dwks
I didn't suggest using public accessors . . . I suggested (at least I hope I did) that one use protected accessors. That way, private data is only used inside a class itself, and if it wants to access data from another instance of itself, it has to go through the protected interface. As I mentioned, it's just a personal opinion, one which will probably disappear the moment I try to code a sticky situation which the abovementioned private access would make much easier.
So suppose you have a protected accessor called GetWidth(). Presumably this guards against changes to the implementation. But if the implementation does change, you now have to change GetWidth() instead of some other piece of code. What advantage does that have?
Now, it's possible that GetWidth() has to perform some complicated calculation in order to return a result, and so logically belongs in its own method. But that's a case of properly abstracting and refactoring code, nothing to do with visibility.
Last edited by brewbuck; 09-08-2009 at 06:47 PM.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
POST EDITED: Was reading protected an still thinking in terms of public. What a nut! Really shouldn't reply to posts at 3am.
Hmm... the alternative would be to have a protected data member, but this may not be desirable if you wish to implement read-only or write-only access to a base-class data member from within derived classes.
I believe it may also be useful if you expect considerably changes to the base-class sometime in the future and want to guard against having to change all of the derived classes. Essentially bringing functional abstraction onto the class hierarchy, if you predict the need.
On a third and final note it may just be that you do trust your own implementation, but you don't want to trust it to anyone deriving from your class
Last edited by Mario F.; 09-08-2009 at 08:58 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
