tags:

views:

94

answers:

5

Hi,

I a writing a Simulation program and wondering if the use of const double is of any use when storing intermediate results. Consider this snippet:

double DoSomeCalculation(const AcModel &model) {
   (...)
   const double V = model.GetVelocity();
   const double m = model.GetMass();
   const double cos_gamma = cos(model.GetFlightPathAngleRad());
   (...)
   return m*V*cos_gamma*Chi_dot;
}

Note that the sample is there only to illustrate -- it might not make to much sense from the engineering side of things. The motivation of storing for example cos_gamma in a variable is that this cosine is used many time in other expressions covered by (...) and I feel that the code gets more readable when using

cos_gamma 

rather than

cos(model.GetFlightPathAngleRad())

in various expressions. Now the actual is question is this: since I expect the cosine to be the same througout the code section and I actually created the thing only as a placeholder and for convenience I tend to declare it const. Is there a etablished opinion on wether this is good or bad practive or whether it might bite me in the end? Does a compiler make any use of this additional information or am I actually hindering the compiler from performing useful optimizations?

Arne

+4  A: 

You can certainly help things by only computing the cosine once and using it everywhere. Making that result const is a great way to ensure you (or someone else) don't try to change it somewhere down the road.

A good rule of thumb here is to make it correct and readable first. Don't worry about any optimizations the compiler might or might not make. Only after profiling and discovering that a piece of code is indeed too slow should you worry about helping the compiler optimize things.

Kristo
+5  A: 

I am not sure about the optimization part, but I think it is good to declare it as const. This is because if code is large, then if somebody incorrectly does a cos_gamma = 1 in between you will get a compiler error instead of run time surprises.

Naveen
+2  A: 

I wish I worked with more code written like this!

Anything you can do to make your code more readable can only be a good thing. Optimize only when you need to optimize.

My biggest beef with C++ is that values are not const by default. Use const liberally and keep your feet bullet-hole free!

Johnsyweb
+2  A: 

Given your code:

const double V = model.GetVelocity();
const double m = model.GetMass();
const double cos_gamma = cos(model.GetFlightPathAngleRad());

I would probably leave cos_gamma as it is. I'd consider changing V and m to references though:

const double &V = model.GetVelocity();
const double &m = model.GetMass();

This way you're making it clear that these are strictly placeholders. It does, however, raise the possibility of lifetime issues -- if you use a reference, you clearly have to ensure that what it refers to has sufficient lifetime. At least from the looks of things, this probably won't be a problem though. First of all, GetVelocity() and GetMass() probably return values, not references (in which case you're initializing the references with temporaries, and the lifetime of the temporary is extended to the lifetime of the reference it initializes). Second, even if you return an actual reference, it's apparently to a member of the model, which (at a guess) will exist throughout the entire calculation in question anyway.

Jerry Coffin
thanks for the hint. The getter methods indeed return a const reference to a member inside model. Lifetime should not be a problem since the code is executed in the simulation loop which in turn does ensure the model is in scope.
Arne
A: 

Whether the compiler makes use of this is an interesting question - once you're at the stage of optimizing a fully working program. Until then, you write the program mostly for the humans coming later and having to look at the code. The compiler will happily swallow (objectively) very unreadable code, lacking spaces, newlines, and sporting hilarious indentation. Humans won't.
The most important question is, how readable is the code, and how easy it is to make a mistake changing it. Here, const helps tremendously, because it makes the compiler bark at everyone who mistakenly changes anything that shouldn't change. I always make everything const unless I really, really want it to be changeable.

sbi