Jump to content
  • Advertisement
Sign in to follow this  
Thrump

Efficiency: Pointers vs. References

This topic is 4323 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was surprised to find out today that a very large company disallows the use of references for efficiency reasons. void DoSomething( Stuff& stuff ); vs. void DoSomething( Stuff* stuff ); The person I was talking to agreed with the policy, yet couldn't convince me. Something about constructors being called more than you intended, but the person couldn't give me any concrete examples. I personally use references when I can, pointers when I must. Pointers are more complicated and more error prone. They can be null, which you should check against before use. References don't have this problem (unless somebody was bad and did something like dereferenced a null pointer and placed the result in the reference). They can also be uninitialized, which you can't really guard against other than by remember to initialize them. So enough ranting about references. How are they inefficient and is it enough of a reason to flat out prohibit them? My first guess is the policy was made by somebody in the industry for 15 years who is afraid of new developments. (the old virtual pointers being slow arguments, etc...)

Share this post


Link to post
Share on other sites
Advertisement
in the example you give, passing in a parameter, they have 100% identical performance characteristics.

It would be a violation of every rule to call a constructor extra times .. so how exactly could these be different efficiencies:


void DoSomethingRef(Stuff &stuff);
void DoSomethingPtr(Stuff *stuff);

MyClass obj1;

DoSomethingRef(&obj1);
DoSomethingPtr(obj1);



disassemble the compiler output and you will find they are 100% identical in every way ... (compare the release versions, not the debug versions).

Share this post


Link to post
Share on other sites
Quote:
Original post by Thrump
The person I was talking to agreed with the policy, yet couldn't convince me. Something about constructors being called more than you intended, but the person couldn't give me any concrete examples.


The person you talked to was misinformed. Passing parameters by value can cause extra copying. That is one of the reasons why passing (const) references is preferable. Using pointers is definitely not a good idea.

Quote:
I personally use references when I can, pointers when I must. [...]


Correct on all points

Quote:
My first guess is the policy was made by somebody in the industry for 15 years who is afraid of new developments. (the old virtual pointers being slow arguments, etc...)


I think you nailed it. Someone coming from a C background would only know about passing by value and by pointer and would promote the latter. It then becomes enshrined policy and references get ruled out because passing pointers is the norm.

Share this post


Link to post
Share on other sites
Perhaps they are refering to situations such as passing a string literal to a function that expects a const std::string reference. That will call a std::string constructor which, with a naive implementation, will allocate memory and do an array copy. Yes, this is a lot less efficient than passing a const char*, but really, I doubt it matters in just about all cases. I'd call this a form of premature optimization, and would potentially consider actually writing a semi-formal paper arguing for a reversal of the policy. If that didn't convince anyone, then I'd probably drop it and just go with what they insist, 'cause sometimes you just gotta accept what higher-ups assert, but I'd definitely try at least once to provide a substantial argument to change their minds.

Share this post


Link to post
Share on other sites
Agony, do you have any more information on that? That is not how I would have expected a const std::string reference to be passed. Why would it behave differently than passing any other class by reference?

Share this post


Link to post
Share on other sites
Quote:
Original post by Agony
Perhaps they are refering to situations such as passing a string literal to a function that expects a const std::string reference. That will call a std::string constructor which, with a naive implementation, will allocate memory and do an array copy. Yes, this is a lot less efficient than passing a const char*...

No. Certainly not a "lot" less efficient. Consider that passing a string literal to a function that takes const char * requires all sorts of housekeeping/setup within the function to be performed in order to safely make use of that string. So even while the memory may not be copied, the overhead is similar.

And any non-naïve implementation of std::string won't bother to allocate memory in that instance. It'll simply point at the memory that contains the string literal (since the std::string instance is immutable).

In other words, in all circumstances, the performance characteristics of pointers vs references are a wash. References, however, have the upside of syntactic simplicity and more assistance in statically determining correctness from the compiler.

Share this post


Link to post
Share on other sites
Quote:
Original post by Oluseyi
And any non-naïve implementation of std::string won't bother to allocate memory in that instance. It'll simply point at the memory that contains the string literal (since the std::string instance is immutable).


Allow me to have some doubts about that. Unless the compiler is made aware of the situation, I can't see how a difference can be made between constructing a const and non-const object. Move constructors may change that, but they're not there yet... and even if they were, I wouldn't expect companies with such policies in place to adopt their usage.



At any rate, Agony, I don't think char* vs. std::string really is at issue here, rather std::string vs. std::string* vs. std::string&. It is a problem of education and, in all likelihood, of a policy written when the choice was only between values and pointers, with the argument that pointers had better performance. Implicit here would be "than values". Since references aren't on the list of allowed things, they are therefore forbidden.

Share this post


Link to post
Share on other sites
Quote:
Original post by Fruny
Allow me to have some doubts about that. Unless the compiler is made aware of the situation, I can't see how a difference can be made between constructing a const and non-const object.

Point. I suppose copy-on-write semantics would have to be implemented to see the sort of behaviors I suggested - and those are rarely, if ever, used in common std::string implementations.

Share this post


Link to post
Share on other sites
Passing by reference makes it hard to tell when a function might modify the value, just by glancing at the caller. That's about the only benefit I can see for passing pointers.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!