const parameter

[W Marsh]

Hi,

Could anybody tell me wh the parameter "T val" is not marked const in
this Stroustrup code, considering that val is not modified and not non-
const methods called?

template<class C, class T> int count(const C&v, T val)
{
typename C::const_iterator i = find(v.begin(), v.end(), val);
int n = 0;
while (i != v.end()) {
++n;
++i; // skip past the element we just found
i = find(i, v.end(), val);
}
return n;
}

 

[alasham.said]

Hi,

Could anybody tell me wh the parameter "T val" is not marked const in
this Stroustrup code, considering that val is not modified and not non-
const methods called?

template<class C, class T> int count(const C&v, T val)
{
typename C::const_iterator i = find(v.begin(), v.end(), val);
int n = 0;
while (i != v.end()) {
++n;
++i; // skip past the element we just found
i = find(i, v.end(), val);
}
return n;

}

Hello,

You would expect the value parameter to be of type 'const T&',
especially since this is the type used in the standard version of
'count'. You could query Stroustrup about it (address in FAQ
http://www.research.att.com/~bs/bs_faq.html).

Regards.

 

[James Kanze]

Could anybody tell me wh the parameter "T val" is not marked
const in this Stroustrup code, considering that val is not
modified and not non- const methods called?

template<class C, class T> int count(const C&v, T val)
{
typename C::const_iterator i = find(v.begin(), v.end(), val);
int n = 0;
while (i != v.end()) {
++n;
++i; // skip past the element we just found
i = find(i, v.end(), val);
}
return n;
}

Because there's no real point in it? The const would be ignored
at the interface level (in the function declaration). One can
argue both ways in the function definition, but in practice,
very few if any programmers use const here.

The argument for the const is that you'll get an error if you
accidentally modify the variable. The argument against is: who
cares? It's your variable, and you should be able to do what
you want with it. There's also the argument that you don't want
the meaningless const in the declaration, and you want the
declaration and the definition to be coherent. (This argument
probably applies less to templates, since you often won't have a
separate declaration.)

 

[peter koch]

Hi,

Could anybody tell me wh  the parameter "T val" is not marked const in
this Stroustrup code, considering that val is not modified and not non-
const methods called?

template<class C, class T> int count(const C&v, T val)
{
 typename C::const_iterator i = find(v.begin(), v.end(), val);
 int n = 0;
 while (i != v.end()) {
   ++n;
   ++i; // skip past the element we just found
   i = find(i, v.end(), val);
 }
 return n;



}

Your question only makes sense if you meant that val should be passed
as a const reference (As explained by James Kanze, top level const
does not make to much sense). If I understood you correctly, I believe
this is a "bug". The code would function perfectly with the signature
(const C&v, const T& val).

/Peter

 

[KenM]

Because there's no real point in it? Theconstwould be ignored
at the interface level (in the function declaration). One can
argue both ways in the function definition, but in practice,
very few if any programmers useconsthere.

The argument for theconstis that you'll get an error if you
accidentally modify the variable. The argument against is: who
cares? It's your variable, and you should be able to do what
you want with it. There's also the argument that you don't want
the meaninglessconstin the declaration, and you want the
declaration and the definition to be coherent. (This argument
probably applies less to templates, since you often won't have a
separate declaration.)

--
James Kanze (GABI Software) email:[email protected]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Wouldn't marking a pass-by-value parameter as const allow the compiler
to optimize its use, as it does with local const variables? E.G.:

void foo(const int input) {
const int var = bar();
...
}

 

[Bo Persson]

Wouldn't marking a pass-by-value parameter as const allow the
compiler to optimize its use, as it does with local const
variables? E.G.:

void foo(const int input) {
const int var = bar();
...
}

The compiler knows that anyway.

If you make the parameter const and try to modify it, the compiler
will tell you that you cannot. If you don't modify it, the compiler
can use that knowledge as well, whether you mark the value const or
not.


Bo Persson

 

[KenM]

The compiler knows that anyway.

If you make the parameterconstand try to modify it, the compiler
will tell you that you cannot. If you don't modify it, the compiler
can use that knowledge as well, whether you mark the valueconstor
not.

Bo Persson

I don't quite get what you said. Are you saying the compiler can see
that the non-const parameter is never changed and so optimize as
though it were const? If so, why can't it do so with a local variable
like 'var' in the example?

Myself, I've never used const on a pass-by-value parameter- it seems
weird to me, but a colleague has started doing so and I'm trying to
figure out if it makes as much sense as any other use of const.

Thanks,
Ken

 

[James Kanze]

I don't quite get what you said. Are you saying the compiler
can see that the non-const parameter is never changed and so
optimize as though it were const? If so, why can't it do so
with a local variable like 'var' in the example?

It can. As long as the scope of a variable is local, and you
never take its address or a reference to it, it's fairly easy
for the compiler to identify all places where it is modified,
and treat it as if it were const everywhere else.

Myself, I've never used const on a pass-by-value parameter- it
seems weird to me, but a colleague has started doing so and
I'm trying to figure out if it makes as much sense as any
other use of const.

I find very few programmers using const on variables with auto
lifetimes. There isn't that much payback from it. (An
exception might be integral variables initialized with an
integral constant expression, which if const can also be used in
integral constant expressions. In practice, I almost always
make these static as well, however, and so they don't fall under
the above rule.)

In the case of function parameters, there is at least one very
good argument against it: the const is an internal detail, of no
relevance to the client, so you don't want it in the exported
declaration (in the header file). And for consistency, you want
the exported declaration and the definition to have exactly the
same form, right down to the spelling. Thus, something like:

MyFile.hh:
extern void funct( int param ) ;

MyFile.cc
#include "MyFile.hh"

void
funct( int const arg )
{
}

might be perfectly legal, but it violates most style rules.
Both because of the added const, and because of the change in
names.