I assumed to make all the data for class like "Object" or "Scene" private with function to return the one I need. The problem is that it end with dozen of function like "getthisvalue" "returnmethat()" and this doesn''t look good , each time I instanciate this class those function are duplicated in memory even I will usually need 5% of them. Getposition() and such are ok but the other Counterpart is if I make those value public I can access the one I need but I wonder and can''t decide which method is the best and I don''t want to end with half class function and other half public value (or whorse mixed) I had seen whole wrapper and other things and they add all private value saying that it''s better. Why ? Anyone have a thought on this ? performance ? design tips ? Thanks Dan (C++, Dx8)

The methods are not "duplicated in memory." Functions exist at absolute positions relative to the application offset; methods simply have the restriction of not being valid on non-objects of that class, but that is resolved at compile time. All your nice C++ is converted to assembly and then machine code.

The only valid concern you may have is that function calls just to get a value may have too much overhead. In such instances you can inline the methods (it's often a good idea to inline access methods anyway). You can also eliminate the need for get() and set() functions by having the get() function return a reference.

Edit: benefits of private variables.

Private variable enforce encapsulation and data hiding, which are good principles of OO methodology. They make your calling functions independent of the implementation of the called object (so you can change the internals of your class without affecting programs that call your class, provided the interface - set of methods - remains unchanged).

Edited by - Oluseyi on October 20, 2001 6:58:41 PM

quote:Original post by Oluseyi
You can also eliminate the need for get() and set() functions by having the get() function return a reference.

But then you''ve just eliminated the purpose of making the variable private/protected, since you can change it in any way you want through the reference.

quote:Original post by Dactylos
But then you've just eliminated the purpose of making the variable private/protected, since you can change it in any way you want through the reference.

Granted - to a point. You may wish to allow free access to the variable, but confirm that it is being given valid values.

// assume class Object has a private data member unsigned int prob// which should vary from 0 - 100 onlyint &Object:: Probability(void) // obviously without the space{  return (prob %= 100);}  

This ensures that even if you assign 500 to prob, it will cycle round (and end up as 0). Alternatively you could use min-max to keep it between 0 and 100 without cycling.

Lax designs, I know, but someone may find a use/need for them.

Edit: this smiley code is waaay out of hand.

Edited by - Oluseyi on October 20, 2001 7:16:12 PM

quote:Original post by Oluseyi

Original post by Dactylos
But then you''ve just eliminated the purpose of making the variable private/protected, since you can change it in any way you want through the reference.

Granted - to a point. You may wish to allow free access to the variable, but confirm that it is being given valid values.

// assume class Object has a private data member unsigned int prob// which should vary from 0 - 100 onlyint &Object:: Probability(void) // obviously without the space{  return (prob %= 100);}   

This ensures that even if you assign 500 to prob, it will cycle round (and end up as 0). Alternatively you could use min-max to keep it between 0 and 100 without cycling.

Lax designs, I know, but someone may find a use/need for them.

Edit: this smiley code is waaay out of hand.

Edited by - Oluseyi on October 20, 2001 7:16:12 PM

This isn''t very good either because you are only resetting that value when you first ask for it. After you get the probability, you could easily use the reference to set it to 500. Suppose you then call some member function that uses that probability directly (without calling your accessor). Then, you will be using all of these out of range values. It is generally much better to use a GetVar()/SetVar() style for accessing and setting member functions where you should only be able to retrieve a constant value.

[EDIT: jaxson already pointed out most of this while I was writing]

quote:Original post by Oluseyi
Granted - to a point. You may wish to allow free access to the variable, but confirm that it is being given valid values.

// assume class Object has a private data member unsigned int prob// which should vary from 0 - 100 onlyint &Object:: Probability(void) // obviously without the space{  return (prob %= 100);}    

This ensures that even if you assign 500 to prob, it will cycle round (and end up as 0). Alternatively you could use min-max to keep it between 0 and 100 without cycling.

Lax designs, I know, but someone may find a use/need for them.

Yeah, ok
I just think it would be cleaner to have a explicit setter-method. Since the probability is only validated on a "get", and not a "set", you would be forced to use the Probability() method to access prob in other methods of Object. Perhaps this is intentional, but I like to be able to access my member-data directly, without worrying about it being invalid. Also you would have locked the class into using an int to represent the probability, thus separation between interface and implementation is lost. Of course the internal implementation could still be changed, but it would make the Probability() method unnecessarily complex, whereas a separate getter and setter could simply cast the internal representation to an int or vise versa.

And code like the following wouldn't work correctly

    void DoSomething(Object *obj){   obj->Probability() = 300;};void SomeOtherFunc(Object *obj){   int &prob = obj->Probability();   DoSomething(obj); // we forget that DoSomething changes obj's probability   cout << "Probability: " << prob << endl; // prints "Probability: 300"};    

Ok, so its a very silly example , my point is simply that it would be safer to use a separate setter. I think you agree with me here, I'm just pointing out the obvious

(btw, whitespace around :: doesn't matter, it's just an operator)

Edited by - Dactylos on October 20, 2001 8:02:15 PM

Oh, I definitely agree with you. I personally always use get/set methods. It was just a case of "it''s possible" thinking.

Hmm, never though about :: as just an operator. It''s that MSVC conditioning (the function name wont come up in IntelliSense if there''s a space...)

Thanks.