'academic' problem ( speed/memory efficiency vs. human readability and easy design )

[burningsunorama]

Hi guys!

This is maybe a too 'academic problem', but I would like to hear your
opinions, something like pros and cons for each approach....
... Recently we've had at work a little talk about the way of providing
const modifier for function parameters. From my point of view are, of
course, design requirements always more important and thus one should
always use const keyword with parameters whose values shouldn't get
changed inside a function ( lets call these ,In' parameters ). The
compiler in this case checks of any assignment or possible change of
the parameter/variable and gives an potential error message, thus
ensuring robustness of the code and also, imho, by following this
convention the readability and understanding of the code for future
re/viewers is better.
The opposite opinion was based on fact, that when you need to
use/declare a local variable inside the function, the code is less
efficient (because you lose speed and memory usage is higher), since
you could you use a stack variable provided as a parameter ( and since
is it YOU who writes the body of a function YOU take care of proper
content of the variable ).
The debate was mainly about the parameters given by value, with
reference parameters we basically agreed that const is useful, but in
essence this is imho the same...
The fact is that we develop time and memory critical system, but
overall such subtle memory and speed differences do not have critical
impact on the whole system since it runs on hardware which is powerful
and dimensed enough to host the sw; therefore, this is, IMHO, a
completely nonsense, and the questions are:
- are the benefits gained in more efficient code worth of losing quick
comprehension of the code ?
- are those benefits really so high that you can ignore possible future
bugs ?
- does it even make sense to reason in this context in terms like speed
and memory efficiency ?

Thanks for comments..

 

[Victor Bazarov]

[...]

This whle thing belongs to 'comp.software-eng', really. I don't see
a *C++ language* problem here.

The fact is that we develop time and memory critical system, but
overall such subtle memory and speed differences do not have critical
impact on the whole system since it runs on hardware which is powerful
and dimensed enough to host the sw; therefore, this is, IMHO, a
completely nonsense, and the questions are:
- are the benefits gained in more efficient code worth of losing quick
comprehension of the code ?

Why are you asking us? If *you* can't decide, who can? Every case is
different. Sometimes you need to squeeze every CPU tick, sometimes it
isn't that important.

Besides, this sounds (looks) like a rhetoric question. If you need some
kind of affirmation from us, you won't really get it. It's a toss-up.
And it's case-specific.

- are those benefits really so high that you can ignore possible
future bugs ?

Again, this sounds (looks) like a rhetoric question. Are you losing the
argument to your colleagues who don't think so? Here is my question:
*what* future bugs? Performance is sometimes paramount. When you get
any "future" bugs, deal with them. If (and it sounds like it) you have
the performance problem *now*, you have to deal with it in any way you
can. But you won't know whether you have the performance problem *until*
you measure for it.

- does it even make sense to reason in this context in terms like
speed and memory efficiency ?

Possibly not. Performance is not an abstract concept. It cannot be
argued about. It can only be measured.

V

 

[Daniel T.]

This is maybe a too 'academic problem', but I would like to hear your
opinions, something like pros and cons for each approach....
.. Recently we've had at work a little talk about the way of providing
const modifier for function parameters. From my point of view are, of
course, design requirements always more important and thus one should
always use const keyword with parameters whose values shouldn't get
changed inside a function ( lets call these ,In' parameters ).

IE: void fn( const int foo );

Your talking about an issue that is local to one function. If the
functions are small enough that a programmer can easily tell if and
where the parameter is modified, I don't see where the const nets you
anything useful.

If your functions are so long that only Sherlock Holmes could tell what
is happening to a parameter, then the "const" keyword won't help much.

- are the benefits gained in more efficient code worth of losing quick
comprehension of the code ?

I don't see where the const keyword in this case gives you quick
comprehension...

- are those benefits really so high that you can ignore possible future
bugs ?

Again, you are assuming that the 'const' keyword in this case reduces
the possibility of bugs. I don't see it.

 

[burningsunorama]

[...]

This whle thing belongs to 'comp.software-eng', really. I don't see
a *C++ language* problem here.

I posted it in c++ groups because the sw is written in c++ which I
forgot to mention, but I will repost it there.

Why are you asking us? If *you* can't decide, who can? Every case is
different. Sometimes you need to squeeze every CPU tick, sometimes it
isn't that important.

Besides, this sounds (looks) like a rhetoric question. If you need some
kind of affirmation from us, you won't really get it. It's a toss-up.
And it's case-specific.


Again, this sounds (looks) like a rhetoric question. Are you losing the
argument to your colleagues who don't think so? Here is my question:
*what* future bugs? Performance is sometimes paramount. When you get
any "future" bugs, deal with them. If (and it sounds like it) you have
the performance problem *now*, you have to deal with it in any way you
can. But you won't know whether you have the performance problem *until*
you measure for it.

Yes, I think you got the point. Further debate would be propabaly
pointless without proper measurement of resource usage.

Possibly not. Performance is not an abstract concept. It cannot be
argued about. It can only be measured.

V

Thank you very much!

 

[Jerry Coffin]

[ ... ]

.. Recently we've had at work a little talk about the way of providing
const modifier for function parameters. From my point of view are, of
course, design requirements always more important and thus one should
always use const keyword with parameters whose values shouldn't get
changed inside a function ( lets call these ,In' parameters ). The
compiler in this case checks of any assignment or possible change of
the parameter/variable and gives an potential error message, thus
ensuring robustness of the code and also, imho, by following this
convention the readability and understanding of the code for future
re/viewers is better.

[ ... ]

The debate was mainly about the parameters given by value, with
reference parameters we basically agreed that const is useful, but in
essence this is imho the same...

You're wrong and they're right, but not for the reasons they've
given.

Your position shows a fundamental misunderstanding of one of the most
basic ideas in all of software engineering: separation of interface
from implementation.

Specifically, the interface consists of the _externally visible_
behavior of the function. Anything and everything that's not
externally visible is implementation -- and external code has no
business knowing or caring about it at all.

In this case, the mistake is a subtle one -- for the most part, the
type of parameter taken by a function IS externally visible. Top-
level cv-qualifiers, however, do NOT specify an externally visible
behavior -- they specify only implementation.

As such, such top-level cv-qualifiers should be used only to the
extent that they make sense in terms of the implementation. Looking
at it in more concrete terms, the function receives a copy of the
value that was passed to it. While the TYPE of data matters to the
outside world, the copy itself is "owned" by the function, and it's
nobody else's business what the function does with its own data.

Your opinion that this will make the code easier to read and/or
understand is also wrong. In reality, it makes the code easier to
MISunderstand. In particular, you're attempting to act as if a cv-
qualified parameter creates a different type -- but you're wrong, and
the compiler knows you're wrong. If they were really different types,
you should be able to (for one example) overload based on that type
difference, such as in code like this:

void f(int) {}
void f(const int) {}

Assuming you use a compiler that works anywhere close to correctly,
it'll attempt to correct your misconception if you give it code like
this. For one example, Comeau C++ says: "error: function "f" has
already been defined". MS VC++ says: "function 'void f(int)' already
has a body".

Though it's a rarity, in this case, I'd say Microsoft's error message
is more informative than Comeau's -- it's much more clear about the
fact that your 'f(const int)' has a signature of 'f(int)', because
that's the real interface to the function.

 

[Bernd Strieder]

Hello,

Hi guys!

This is maybe a too 'academic problem', but I would like to hear your
opinions, something like pros and cons for each approach....
.. Recently we've had at work a little talk about the way of providing
const modifier for function parameters. From my point of view are, of
course, design requirements always more important and thus one should
always use const keyword with parameters whose values shouldn't get
changed inside a function ( lets call these ,In' parameters ). The
compiler in this case checks of any assignment or possible change of
the parameter/variable and gives an potential error message, thus
ensuring robustness of the code and also, imho, by following this
convention the readability and understanding of the code for future
re/viewers is better.

It is a wise decision to use const references for parameters as default.
Then the compiler can check that the const is respected in the called
function, and it has the freedom to create a copy instead of passing
the reference in those cases, where the copy is faster, e.g. for the
builtin types. This becomes important for templates, when different
kinds of types are used as parameters, then const references allow the
compiler to chose the best. That way the compiler might be able to use
CPU registers more efficiently in both the calling and the called
function.

E.g. an integer in a register in the calling function will be
transferred in registers to the called function, since it is const
reference the value will not be changed in the called function, so
nobody could miss a change to a copy. A large object, which is in
memory, will be passed by its address. Although it could be changed in
the called function, it won't because it is a const reference. Well,
there is mutable, but not critical here.

If you have an integer in a register and pass it via non-const
reference, the compiler will have to move the integer to the stack, and
pass its address there.

If you have a large object and pass it by value, then the copy
constructor will be called, which is not cheap.

Const reference is the only possibility to let the compiler do its best
in all cases.

The opposite opinion was based on fact, that when you need to
use/declare a local variable inside the function, the code is less
efficient (because you lose speed and memory usage is higher), since
you could you use a stack variable provided as a parameter ( and since
is it YOU who writes the body of a function YOU take care of proper
content of the variable ).
The debate was mainly about the parameters given by value, with
reference parameters we basically agreed that const is useful, but in
essence this is imho the same...

No it is not the same. Const for non-reference parameters does not
enable more efficient parameter handling. A copy will be created,
anyway, and the problem to be prevented, changing a copy, are only
delayed to the next copy created.

It is a good question, if someone does not realize that parameter by
value does not get its changes retransferred, then another copy won't
be recognized as a problem, as well.

The fact is that we develop time and memory critical system, but
overall such subtle memory and speed differences do not have critical
impact on the whole system since it runs on hardware which is powerful
and dimensed enough to host the sw; therefore, this is, IMHO, a
completely nonsense, and the questions are:
- are the benefits gained in more efficient code worth of losing quick
comprehension of the code ?
- are those benefits really so high that you can ignore possible
future bugs ?
- does it even make sense to reason in this context in terms like
speed and memory efficiency ?

Const without reference has low chances to improve efficiency.



Bernd Strieder

 

[Noah Roberts]

The opposite opinion was based on fact, that when you need to
use/declare a local variable inside the function, the code is less
efficient (because you lose speed and memory usage is higher), since
you could you use a stack variable provided as a parameter ( and since
is it YOU who writes the body of a function YOU take care of proper
content of the variable ).

Are you sure? Compilers are very smart nowdays. If you don't actually
change the parameter in question does it really make any difference, in
the executable code, whether you use it directly or first "copy" it
into a variable and use that variable? Could the compiler be smart
enough that it ignores the copy command entirely? Most are capable of
this at least with return values...

The debate was mainly about the parameters given by value, with
reference parameters we basically agreed that const is useful, but in
essence this is imho the same...

There is no reason to use const on value parameters, as others have
stated. The const keyword is for when you want to show that your
object will not be changed by passing it into this function and it
otherwise could have been. So there is no benefit to using const in
this context.

- are the benefits gained in more efficient code worth of losing quick
comprehension of the code ?

Depends on the requirements. In general absolutely not as you will
need to modify most of your code later. Less understandable code leads
to changes that are inefficient.

- are those benefits really so high that you can ignore possible future
bugs ?
No.

- does it even make sense to reason in this context in terms like speed
and memory efficiency ?

Not really. You can keep it in mind as you code that certain practices
could be inefficient but you should never try to produce optimized code
before profiling.

 

[red floyd]

Your position shows a fundamental misunderstanding of one of the most
basic ideas in all of software engineering: separation of interface
from implementation.

Specifically, the interface consists of the _externally visible_
behavior of the function. Anything and everything that's not
externally visible is implementation -- and external code has no
business knowing or caring about it at all.

In this case, the mistake is a subtle one -- for the most part, the
type of parameter taken by a function IS externally visible. Top-
level cv-qualifiers, however, do NOT specify an externally visible
behavior -- they specify only implementation.

As such, such top-level cv-qualifiers should be used only to the
extent that they make sense in terms of the implementation. Looking
at it in more concrete terms, the function receives a copy of the
value that was passed to it. While the TYPE of data matters to the
outside world, the copy itself is "owned" by the function, and it's
nobody else's business what the function does with its own data.

I had this argument at work as well (I'm not the OP). I argued that
using cv qualifiers on parameters exposed implementation details
unnecessarily. Of course, I lost the argument.

 

[Kaz Kylheku]

Hi guys!

This is maybe a too 'academic problem', but I would like to hear your
opinions, something like pros and cons for each approach....
.. Recently we've had at work a little talk about the way of providing
const modifier for function parameters. From my point of view are, of

[ snip ]

The debate was mainly about the parameters given by value, with

[ Attention to the "by value" part ]

reference parameters we basically agreed that const is useful, but in
essence this is imho the same...

You and your coworkers appear to be confused.

The const qualifier means almost nothing when it is the parameter
itself that is qualified. This comes from ANSI C. For instance, these
two type declarations are compatible:

int foo(const int x);
int foo(int x);

And in fact the declaration that you put into the header file can be:

int foo(const int);

and your function definition can still be:

int foo(int x)
{
}

or vice versa.

In other words, the qualifier does not affect the function interface.

So why are qualifiers on parameters allowed? It's because in a function
definition, they are, after all, just local variables. What makes
parameters special is that they receive their initial values from the
function arguments, but in other respects they are just locals. It's
useful to declare a parameter const for the same reasons that it's
useful to declare any other local variable const: to indicate that its
value is should not change, and obtain the related diagnostics.

 

[Jerry Coffin]

[ ... ]

I had this argument at work as well (I'm not the OP). I argued that
using cv qualifiers on parameters exposed implementation details
unnecessarily. Of course, I lost the argument.

You may have lost the argument, but you were mostly right.

One possibility to consider would be to put the qualifier there in
the function implementation (to the extent that it makes sense for it
to be there from the viewpoint of the implementation). Then, in the
header that exposes the function to the world, you leave the cv-
qualifier out of the declaration.

This avoids exposing the implementation detail to the world, while
maintaining the qualifier on those (admittedly rare) parameters for
which they really DO make sense. To the compiler (assuming it works
correctly) this is perfectly fine -- a function implemented as f
(const int) will match/link up with a declaration of f(int) just
fine.