Sign in to follow this  

[C++] Call once and store vs. call multiple times

This topic is 3727 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

Greetings, I have a class that has a 'get' method which returns a std::string. If I have a function that needs to use the string from the class, is it better to call 'myclass.get()' every time I want to use the string, or should I call 'myclass.get()' once, store it in a temp string variable, and use the temp variable for everything in the function? Throughout the function, the string stored in the 'myclass' will not be modified, so there's no danger of using an old version of the string in the temp variable. Seeing 'myclass.get()' throughout the function makes sense and makes it clear as to what is going on. However, it seems inefficient to be calling the same function over and over when I could just be working with a temporary local variable. Plus, it doesn't really make it unclear what is going on, just perhaps not /as/ clear. Any thoughts/suggestions? Or will the compiler be smart enough to cache the results of the first 'myclass.get()' call and store it locally? Can it even be smart enough to know that the call will always return the same value without the function being const?

Share this post


Link to post
Share on other sites
Questions about optimizations are ultimately dependent on the compiler being used. Those questions also get governed by the rule about pre-mature optimizations. If it turns out it matters when a profiler tells you it matters, then worry about it. If the profiler doesn't tell you it matters, then don't worry about it.

However, to answer the question, if you inline the relevant class functions or your compiler/linker features include link time code generation and optimizations then the compiler will probably cache the results. Otherwise probably not.

Share this post


Link to post
Share on other sites
Quote:
Or will the compiler be smart enough to cache the results of the first 'myclass.get()' call and store it locally? Can it even be smart enough to know that the call will always return the same value without the function being const?


No.

Caching is a highly unpredictable and very wasteful mechanism.

What can happen, is that during compile-time, compiler will inline the call, and access the string directly (maybe even if returned by value).

Generally, I dislike accessors in C++. While they have become widespread with Java toolkits and auto-generated code or even have their own constructs such as properties, they aren't strictly necessary.

My reasoning is somewhat puristic OO. I don't care what an object contains, I don't want to know, nor how I get it. I will tell the object to do something. And that implementation in turn may use some internal string.

If you use object for storage, then you might want to consider a struct without accessors.

Otherwise, you could try to return const reference.

The reason there is no one best solution is mostly due to life-cycle management. Unlike managed objects, where you return wherever and whatever you want, in C++ you need to make sure owners don't get mixed up - or copy by value.


While the optimizations you mentioned would be possible, and in some way may already be present, there are really a lot of side-effects that may prevent such optimizations to be done reliably.

For your problem, I'd suggest using more functional approach, or using const references, possibly with inline directive.

But the only thing that can be said about performance is that you shouldn't be returning string by value. That's the only obvious performance hit.

Share this post


Link to post
Share on other sites
temporary local variable is the keyword, think about down the road when you need to mod this variable why not have a pointer do the work for ya. This way you don't have to go back and change all the instance of this variable.

Share this post


Link to post
Share on other sites

This topic is 3727 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this