Re: const parameter
On May 6, 6:15 pm, KenM <ken.mck...@gmail.com> wrote:
On May 5, 1:26 pm, "Bo Persson" <b...@gmb.dk> wrote:
KenM wrote:
On Apr 28, 1:27 am, James Kanze <james.ka...@gmail.com> wrote:
On Apr 26, 8:52 pm, W Marsh <wayne.ma...@gmail.com> wrote:
Could anybody tell me wh theparameter"T val" is not marked
constin this Stroustrup code, considering that val is not
modified and not non-constmethods called?
template<class C, class T> int count(constC&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? 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.)
Wouldn't marking a pass-by-value parameter asconstallow the
compiler to optimize its use, as it does with localconst
variables? E.G.:
void foo(constint input) {
constint var = bar();
...
}
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.
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.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34