[dchichkov]

Precisely. And there is even a little bit more to it.

1. it reads "assign one of these values to sides[i]". 2. it would not allow some other peoples spurious code into the assignment. which is a good thing. 3. space is used to convey meaning; note how sides[i] stands next to dists[i]; ternary operation is formatted as a table, etc.

[neumann_alfred]

If you have people adding "spurious" stuff to your code, you have a bigger problem than coding style. Why would you need locks on your door if you live on a planet with only friends on it? If you don't; why don't you?

[jblow]

Not allowing other code in is a bad thing. See my putty reply above.

[dchichkov]

It depends.

But in this particular case, some trivial extra code inserted inside that if statement may break things. Like breaking vectorization of that 'for' (note, that we are going over vertices).

When you are writing the code, some times you may want to put additional constraints on the allowed operations, modifications, etc. A trivial example in C++ would be using 'const &' instead of '&'.

[jblow]

This is true (especially: breaking vectorization). But premature optimization is not a good idea, and if you are doing real optimization, you are going to rewrite that piece of code 10 times anyway, so it is in a different class of problem and the putty stuff I was saying before does not apply (i.e. this code is in the 1% or so of the codebase that is highly performance-sensitive).

Optimized code is just a different thing from general code (if one is a productive programmer).

[dchichkov]

And again it depends. I would return to a simple example of passing a parameter by a const reference.

When you are writing this const in the "const std::string &name" you are 1) constraining developers from breaking things 2) making the code more efficient 3) providing clues to other developers 4) providing clues to optimizer.

All of these points are important to some degree. And it is just the same, when you are writing this assignment.

And writing efficient code that provides all these clues in every way possible (including consistently and meaningfully arranging the white spaces) is certainly a good idea. Funny thing, that with experience it doesn't take extra time to do that. You just write it, and it comes out in the right way: readable, efficient and optimal down to CPU microcode and aligned memory accesses.

[jblow]

I think we have different ideas about what constitutes optimization.

Sure, putting const in parameter declarations is easy to do. It may even buy you a little bit of speed because the compiler is a little bit clearer about pointer aliasing and whatever. But it's not going to make a difference in the equivalence classes of slow code / fast code / Really Fast Code.

Serious hardcore optimization usually involves changing the way the problem is solved to something different than the way the old code thought about it: either constraining the problem space further, or attacking it from a different direction. This usually involves rewriting everything since there are so many cross-cutting concerns. Sometimes one has to do this several times to figure out which way is really fastest. Microoptimization things, like whether you used const somewhere or not, are much smaller details that have correspondingly small effects.

For code that one isn't specifically optimizing, speed probably doesn't matter. There was an exception to this, where we hit a little bit of a bump in the late-2000s on platforms with in-order CPUs like the PlayStation 3 and Xbox 360, because they have such a high penalty on cache misses; this tended to make general-purpose code slower and result in much flatter profiles. But now we are pretty much out of that era.

In general, const is more of a protection than an optimization. This is especially true heading into the massively parallel future, where const just sort of tells you whether some code is known for sure to run safely in parallel or not... and running safely in parallel matters tremendously more to overall speed than the number of instructions in that bit of code, or whatever. (Anyway, C++ is not at all a viable language in the massively parallel future... so that is going to be interesting.)

[dchichkov]

Thanks. I've really enjoyed that discussion with you. And by the way, your comment mentioning several decades of experience was certainly appropriate.

[gsg]

Constness of parameters has zero effect on optimisation. Const declarations may provide a small benefit.

Go ahead and apply const as you see fit, but don't expect better code out of it.

[dchichkov]

Would you guarantee that for every implementation of every C++ compiler ever? Especially considering that constexpr is already there?

So, I'd rather leave these clues to the compiler/optimizer.

[lttlrck]

Who's to say that code isn't the tenth iteration? Especially given the context of the discussion...

[Cushman]

Then why are you using a statically-typed language?