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
Printable View
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? :)Quote:
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.
how much time will this impact my code if i may be doing multi millions of loops?Quote:
Originally Posted by Mario F.
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.
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.Quote:
Originally Posted by Mario F.
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 ;)
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.Quote:
Originally Posted by brewbuck
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.
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.Quote:
Originally Posted by Elysia
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.
Also, I'm not sure how many compilers are able to deduce that the reference always points to the member, so this could actually earn you a greater speed penalty (an indirection) than an accessor function (nothing, if inlined).
Should do it if there's only one constructor.
You would have to make the constructor body visible to all clients of the class, then. Defeats the point, doesn't it?
Making the variable available publicly is a bad idea but not a terrible one if you are the only one who is ever going to see the code such as for a home project. Keep in mind you would never do this in a professional project which I would argue means you probably should not do it in a home project.
However it is also possible that the compiler will auto-inline your accessors and mutators if it can. By stating a function is inline you are telling the compiler you would like for it to be such but the compiler does not have to make it inline.
Because of this and because you must expose code for inline I have moved away from using it. I will say though that there are some private variables that only the class needs to know about and these do not need to be exposed. I've seen classes where the designer felt the need to expose every single private and protected variable via setters and getters. It was just as hard to maintain that class as it would have been had they been made public. The only thing the class really did was force the user of the class to go through a function to get/set a variable and force the compiler, if it could not inline, to setup a stack frame for the call.
I too detest a lot of the function calls to get/set variables. For instance in my 3D projects I use Direct3D. Nearly every single class needs some access to the doggone device pointer. All the code ends up looking like:
I have found that if a function needs this pointer a lot then I save it off locally with one GetDevice() and then use it in all the calls after it that need it. Does it make any difference performance wise? Probably not since the compiler probably inlines the getter anyways. But it sure makes the line of code shorter.Code:SomeApp::GetInstance()->GetDevice()->blah blah blah
I could expose the device via extern but then that means anyone can Release() it. However my getter has the same problem. It does not protect the pointer at all so someone could call Release() on it as well. Protecting the pointer, however, could cause other issues since it is a pointer to a COM interface and cannot be deleted as a normal pointer - aka no boost. I could write a templated COM ref counted pointer class for sure or I could only allow access to the device by the graphics system. If anyone writing a class for the graphics system attempts to release the device after getting it they probably should not be working on a class for graphics in the first place. In this instance I would say the templated approach is overkill since it is just as easy to make a hard fast rule that if you get the device you should never ever call Release() on it. This is easy enough to enforce but then the template isn't all that hard to write either and doesn't obfuscate the code all that much. If the user of the class doesn't understand template syntax then they, too, should probably not be writing classes for the system.
EDIT:
After some thought I could use boost on the device pointer but that would require wrapping the device in a class and in the destructor I would release the device.
Busted!Quote:
Originally Posted by CornedBee
Yup. I could say the implementation for the setter is still opaque, but the data member and the getter definitely are not.
Anyways, I don't intend to follow that code anywhere. Simply because of the following...
It's funny, isn't it? I mean, I agree entirely with you. I feel exactly the same. But if we look at it from a functional point of view, we should be glad, not annoyed. That's a perfectly healthy, objective and intuitive method for member access. However there's something in this that irks most of us, for some reason.Quote:
Originally Posted by Bubba
My classes rarely feature get/set prefixes. I find these to be my main source of unjustified annoyance. Naturally, everything that should stay private, stays private. No question about that. But those that do need to be exposed through member access operations are simply named after the data member itself. And for that I follow a simple naming convention for all my private members (functions included). I postfix a underscore.
So, while I still promote the use of setters/getters I stay away from prefixing these operations. Meanwhile, every time anyone sees a symbol on any of my libraries with a postfixed underscore they know it's a private member, regadless. I do use the is and exists prefix when necessary, but that's about it .Code:class CUser {
public:
/*... */
std::string Name() { return name_; }
char Age() { return age_; }
void Name(std::string str) { name_ = str; }
void Age(char val) { age_ = val; }
private:
std::string name_;
char age_;
};
As for function inlining, I do not bother with it for the same reasons brewbuck exposed and you address too. But, going back to the OP initial post I honestly don't worry much about member access performance. If there was a really good reason for that, I'd probably just copy the member to the stack before whatever performance critical event took its place and that would beat anything we could come up in terms of class optimization.
Your lack of get and set in the function name is similar to the property concept in C# and, I think, Java. I'm not a Java fella so I don't know much about it.
Properties feel 'ok' in C# but under the hood it's the same get/set idea. Maybe I feel better about them in C# b/c they are part of the language as opposed to being a construct I created with the language.
I guess no one ever said that C++ was going to show you the correct way to do things and would not stop you from doing it the wrong way. If it did none of us would love it as much as we do.
But the fact that I have to go through a hideous function call to get a variable I just got access to a couple of milliseconds ago just irritates me. Another thing that irritates me is I have no idea if said compiler inlined my call to eliminate the function call overhead. I don't think I will ever get 'over' those two annoyances while programming in C++. So every time I make a getter that just returns a value via a function call and a setter that sets a value via a function call I throw up a bit in the back of my throat.
If you need super-fast access to a bunch of state, then what you're talking about isn't really an object anymore but an algorithm which operates on a given data structure. One of the traps that OOP users can fall into is thinking of everything in terms of objects which encapsulate state. In some cases the state itself is what is of interest, and the method by which this data is manipulated is only ancillary.
You can still have objects, but these objects are now operators on the state instead of containers for it. The state container becomes something extremely simple, like a vector.
Wasn't there a properties proposal sometime during C++0x life? I could swear I saw that once.
My first contact with properties was with Visual Basic, introduced in 4.0 if I'm not mistaken. I did appreciate the syntactic simplicity of class usage in VB exactly because of that. It's funny because one of the first things I tried when I started learning C++ was exactly to match that simplicity.
I agree it can be an annoyance in C++ over the extra typing. But I don't share the disgust :)
The function notation makes today a lot more sense to me than properties.
brewbuck can you expand further? this is closer to what I am looking to do and your comments seem insightfulQuote:
Originally Posted by brewbuck