Thread: accessing private class data low overhead

is there a faster way to do

ptrClassA->itsval ?

Make it public?

By implement set and get functions you are theoretically doing the right thing, since you are controlling the access to your class members and providing a common interface that users of your class (you and other programmers declaring objects of your class) can expect.

Some may argue that on examples like yours where the setter and getter functions limit themselves to assign to and retrieve the private member, there is no need for those functions and you could simply make itsval public. That would allow you to use ptrClassA->itsval and skip a function call.

I'd be tempted to agree, however there's two disadvantages of the top of my head you should consider:

. You are limiting your ability to maintain the class. If sometime later you decide that after all you want the class to do other things besides itsval = val; or return itsval; when assigning or retrieving that member, you will then need to create those functions. But the problem is that you have code all around that will stop working as intended and needs to be changed. Anywhere where you are doing something like ptrClassA->itsval = 13.5 or double val = ptrClassA->itsval.

. The other problem (maybe less important, dunno. I find it important though) is that by not implementing functions of this type, users of this class cannot expect a common interface. That is, if all your members are private and to access them they need to use Getxxx and Setxxx (or any other consistent nomenclature you decide) it makes your class easier to use.

You may want to consider implementing those functions inline with the class definition first, to see if avoiding the function call overhead has any measurable improvement on performance.

Make the set/access functions inline and forget it. If the compiler refuses to inline them, throw your compiler out the window.

Altering the visibility of a member as a speed optimization is unacceptably wrong

Yes. I was trying to make a case exactly for that. Should have worded it better. Didn't want the OP to think I was suggesting making it public.

Originally Posted by Mario F.

Yes. I was trying to make a case exactly for that. Should have worded it better. Didn't want the OP to think I was suggesting making it public.

It's not really as bad as I make it sound, because making the function inline means you have to expose its internals inside a header file, which means your implementation isn't black-box anymore. One of the fundamental problems with C++, IMHO.

Of course, I can't actually imagine a standard way of allowing specification of inline functions without revealing their code.

No wait, I can, but it involves cryptography and that's just goofy

No. It's alright. It was the OP answer to my post that scared me

Originally Posted by brewbuck

It's not really as bad as I make it sound, because making the function inline means you have to expose its internals inside a header file, which means your implementation isn't black-box anymore. One of the fundamental problems with C++, IMHO.

Of course, I can't actually imagine a standard way of allowing specification of inline functions without revealing their code.

Ah, but both MSVC and GCC 4.x can inline non-inline functions even if they're in different source files, so it's not all that bad.

4.x can't do it. 4.5 will be able to, but you'll have to explicitly request it.

Ah, 4.5+ then. But that's alright. You have to explicitly ask MSVC too.

Originally Posted by Elysia

Ah, but both MSVC and GCC 4.x can inline non-inline functions even if they're in different source files, so it's not all that bad.

I was thinking more along the lines of a user library, where you do not have the source in the first place. What might have been a completely opaque binary implementation now has bits and pieces of the internals leaking out in the form of inline function definitions in the headers.

Well, one could save a function call for the getter, retain class opacity and pay with a slight increase in size. Could be surprising at first, but if done consistently I guess class users would get used to it.

Code:

class myClass {

public:

    myClass(): member_(0), member(member_) {}
    myClass(double val): member_(val), member(member_) {}
    
    void member(double val) { member_ = val; }

    const double &member;

private:

    double member_;

};

I don't see how that is any advantage over exposing the variable directly.

Not much, no. It's just me exercising.

Guess the only difference over going all the way and exposing the member is that you still retain some functional abstraction. The member is still private and any attempts at changing it have to go through the setter function.

Of course, it's much better to just define the class as everyone expects it and during its use, if there is a need for faster read access to the data member, the class user just copies it to the stack.