Recommended Posts

quote:Original post by Filami Using OOP may be slower because the overhead needed (methods are not stardard calls, they are _thiscall). But there is a small secret: private (and probrably protected) are faster.

Secret indeed! I have certainly never heard of access modifiers having any impact on speed, and I don''t believe it now. Care to explain what exactly you''re talking about?

On a side note, it''s not necessary to make member variables public for speed reasons if reading is all you need; accessor functions can be made inline to preserve data encapsulation without sacrificing speed.

Share this post

Link to post

Share on other sites

Sure, use OO often and as much as possible Seriously, it''s great and forces you to design before coding which is what all of us should be doing anyways. It does mean that coders became designers but that''s evolution. Anyways, I found two helpful sites you might want to check out.

and the traduction is of the last statment is:"One of advantages to declare class''s atributes as privates (encapsulated), is to optimizing his "desempenho"(speed, ificency) without resulting in modifing in access to the members of the class."Hope you understand the traduction. In this statment, I''ve understanded that private parts may be optimized his access. I don''t know what is going under this (must see the disassembler) but I thinck that is has something to do with the this.

0

Share this post

Link to post

Share on other sites

Hey filami, i understand that as i can read portuguese.But beware, early optimizations are the root of all evil.I don''t know which way is better but you can start your design with speed in mind or you can forget about speed, do a clean design and then adjust the parts that needs to be adjusted, both are classical advices on design but since my designs are usually not very good i''m not suitable for an advice on that :D

0

Share this post

Link to post

Share on other sites

One of the advantages of encapsulating the member data (and it is the data that should be encapsulated (not that no functions should ever be private or protected, but making a function that operates on a variable private while leaving the variable itself public generally looks quite pointless) is that if the internal representation changes, the interface (in the form of member functions) may stay the same; for example, you might change some object''s internal numeric representation from integers to floating point numbers for better precision while still providing an integer-based interface; furthermore this allows the object to validate data, if necessary.

I''m not saying I couldn''t possibly be wrong, but stating that access modifiers inherently have any sort of impact on performance makes very little sense to me (and this is certainly not what they are for); I can only wonder at the book you use.

0

Share this post

Link to post

Share on other sites

Ok, just to obliterate the argument that accessor functions are slower:

I made a small test program, whereby I made two classes, each with one variable. One I access directly by making the variable public, the other uses an accessor function. The test was compiled in Release mode in VC7.

Assembly output comparing the # of instructions to carry out an assignment between the dummy variable in each of the classes, to a local variable:

Share this post

Link to post

Share on other sites

Ok, that seems....equal? It seems that getDummy is inline, isn''t it?well, how you did see the asembly output? When I try to do in msvc6, i can only see it in debug mode, not in release (it says that it hasn.t the debug information).But ok! Don''t forget that this is completly compiler dependent! In that function example, it hasn''t created the this pointer. May be that what compiler tryed to optimize.But, in that case, what you thinck about this desing guys?:

class test{ BigType data;public:

__inline void _fastcall set(const BigType& d){ data = d; }

__inline BigType get(){ return data; }

__inline BigType& ref(){ return data; }};

Ok, it''s more an implementation than a design, but it looks great and fast, don''t it?

0

Share this post

Link to post

Share on other sites

And IMHO it is currently the best way to think if you don''t want to remain as a code writer forever. Imagine the things that you need to do in your job as methods of classes. Now if you move up your career ladder by one step, you can mostly forget about how the methods work and only remember the class and it''s interface (public methods). If you don''t have object oriented thinking, doing this might be much harder.

Of course, the above might be bullshit, but I don''t think so.

0

Share this post

Link to post

Share on other sites

Guest Anonymous Poster

With todays compilers there isn''t a reason not to use accessor methods, as long as they are not virtual, there will be no speed difference.

In addition it will give you a level of abstration which you can take advantage of later if you choose. This choice will allow you to do things which might not seem meaningful now, but imagine a year down the road and you want to optmize that primitive data class. Imagine having to find all instnace of it and changing the useage if you had left the data public vs redefining the impemention of the accessor?

The argument of inconvience is made mute with the introduction of smart IDE and their autocomplete. You can type usually a method in 2-3 keystrokes and it autocompletes. And you dont have to remeber the methods names for all the classes as it enumarates them for you, if you forgot.

The only reason not to use it would be some estoric ascthetic arguement, but you can name your method anything you want, and short method names are just as adequate for primtive data objects.