currently I am using pointers and functions to access private class date
in
ptrClassA->Setval;
void setval(double val) {itsval = val;}
ptrClassA->Getval
double Getval() {return itsval;}
is there a faster way to do
ptrClassA->itsval ?
many thanks
This is a discussion on accessing private class data low overhead within the C++ Programming forums, part of the General Programming Boards category; currently I am using pointers and functions to access private class date in ptrClassA->Setval; void setval(double val) {itsval = val;} ...
currently I am using pointers and functions to access private class date
in
ptrClassA->Setval;
void setval(double val) {itsval = val;}
ptrClassA->Getval
double Getval() {return itsval;}
is there a faster way to do
ptrClassA->itsval ?
many thanks
Make it public?is there a faster way to do
ptrClassA->itsval ?
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.
Last edited by Mario F.; 07-23-2009 at 09:18 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.
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.
C + C++ Compiler: MinGW port of GCC
Version Control System: Bazaar
Look up a C++ Reference and learn How To Ask Questions The Smart Way
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
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
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 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.
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
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
No. It's alright. It was the OP answer to my post that scared me![]()
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.
For information on how to enable C++11 on your compiler, look here.
よく聞くがいい!私は天才だからね! ^_^
4.x can't do it. 4.5 will be able to, but you'll have to explicitly request it.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Ah, 4.5+ then. But that's alright. You have to explicitly ask MSVC too.
For information on how to enable C++11 on your compiler, look here.
よく聞くがいい!私は天才だからね! ^_^
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.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
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_; };
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.
I don't see how that is any advantage over exposing the variable directly.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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.
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.