   C++ Inline get/set methods
  Well, maybe someone asked this before, but I couldn't find it on the forums.I've been programming for a good amount of time, but I always had this doubt in my mind. If I declare a class data member as private and use inline get/set methods to access it, will I have performance gains? I mean, in terms of speed, will it be the same as if I declared the data member as public?I always think about that because I have some templated classes for point, vector and matrix and I use inline operators and methods to access the data members. As in my applications speed is required, I always wondered if I should abandon the good programming practices of declaring things private in order to obtain better performance.Thanks all!   
  Well, making the data public is the most straightforward way, and manipulations does not require a function call, so they CAN be faster (not the other way around that you wrote but probably didn't mean).But, when compilers inline the get/set methods for private data members, there is neither the overhead of calling a function. Making get/set functions does allow you to do some checking, caching or other side stuff that must happen when a variable changes.I am unsure though when the compiler makes a function inline...even if you say inline it may even not inline it! I wish it wasn't a hint, but an order. So, when do functions get inlined? When the compiler thinks it's better to inline?   ;  It is unlikely to make a significant difference.   ;Quote:Original post by antimouse...the good programming practices of declaring things private...This is not a general rule that produces good programming practice. Point, vector and matrix have no invalid values for their members, so therefore no checking of values is required. Good programming practice here IMHO is to make the members public.If you need to constantly validate a member, consider instead of having get/set methods rather move the processing that requires access to these into class methods that describe actions rather than values.Bad:class Person{private:    int health;public:    int GetHealth() const { return health; }    void SetHealth(int v){ health=v; }}void f(Person &p){    int h=p.GetHealth();    h=h-2;    if(h<0) h=0;    p.SetHealth(h);}Better:class Person{private:    int health;public:    void Damage(int v){ health-=v; if(health<0) health=0; }};void f(Person &p){    p.Damage(2);};Quote:Original post by antimouseI always think about that because I have some templated classes for point, vector and matrix and I use inline operators and methods to access the data members. As in my applications speed is required, I always wondered if I should abandon the good programming practices of declaring things private in order to obtain better performance.Wrong thing to worry about.Look at it this way. If you need to set individual values one by one (x here, y and z there, x and y over there...) you are already using slowest possible way, one which will be marred by cache misses, branch mispredictions and other problems.If however you need to blast thousands of coordinates each frame - a memcpy or simd will do wonders for performance. Or better yet, off-load that to GPU altogether.The difference between two approaches we are talking here is 1000x.Function call overhead and cost of stack allocation and speed fo for loops and such are things from days long gone. All the speed today comes from how well you can utilize the cache, and streaming data linearly is clear winner here.;Quote:Original post by AardvajkQuote:Original post by antimouse...the good programming practices of declaring things private...This is not a general rule that produces good programming practice. Point, vector and matrix have no invalid values for their members, so therefore no checking of values is required. Good programming practice here IMHO is to make the members public.I would still keep them private for few reasons:- Easier to use IDE to find all accesses.- Easier to set breakpoint.- Ability to enable checking in debug build, for out of bounds, NaN's etc.Point, vector and matrix are used so widely, any changes to the accesses would cause major headache.For performace, I'd not inline them until the final touches before product ships, shown by profiler. I have seen simple getters jump in profiler to take like 1% of CPU. Usually this is fixed by not repeatedly dereferencing stuff or using getter in inner loops, and ultimately making them inline.Making them inline prematurely prevents them showing in profiler.   ;  I can't think of any situations in which you'd want to put a breakpoint on "all accesses of any Vector3's y member". More likely you'd put a data breakpoint on the specific one you're interested in, and that doesn't require getters/setters. As for catching out-of-range and NaN, the former doesn't exist in the math classes the OP was talking about, and the latter is better caught by enabling FP exceptions.   ;  I was being a bit unclear. I was thinking more in line of get set functions generally, not specially for math classes.But even for math classes, there isn't any disadvantage for making data private. I've experienced cases where 3rd party API return NaNs, but you're right the check for that doesnt belong in math classes. Changing matrix from row-major to column-major was suprisingly easy.   ;Quote:Original post by FtnBut even for math classes, there isn't any disadvantage for making data private.You're right that the stakes on the other side are pretty low, so this is basically just me indulging in some bikeshedding, but IMHO per-element getters and setters make vector stuff awfully wordy. v.y = -1; is cleaner and nicer than v.SetY(-1);. It looks more like what it is, namely, changing an element of a utility struct, rather than issuing a message to an encapsulated, self-sufficient capital-O Object.   ;  First of all, thanks for all your replies so far.I liked the answer by Aardvajk, it made a lot of sense to me. But then I keep thinking why some well-known libraries, like CGAL (used for Computational Geometry) use private data members for vectors and matrices.And about what Sneftel said, I personally didn't use things like "v.SetY(-1)", I overloaded the [] operator for getting and setting, so it becomes a lot more clean "v[0] = -1" or "v[X] = -1" if I define some constants for the coordinates.   