Re: Const Considerations
AJ wrote:
James Kanze wrote:
Al wrote:
2) I didn't know const was ignored in declarations (just tried it). That
is weird. Is there a rationale for it? Seems kind of arbitrary to me.
Top level const is ignored, because it really is an
implementation detail. If I write "f( int x )", there's no way
the user can possibly tell whether I modified x or not. And how
would you do overload resolution between "f( int x )" and
"f( int const x )"?
Top level const is not ignored in the function definition. If
you define the function "f( int const x )", any attempt to
modify x in the function is an error. But that doesn't concern
the user.
3) When you say "is generally avoided," do you mean putting
the const in the declaration, or using the const in the
top-level function at all?
Putting the const in the declaration. Since
"f( int const x )" and "f( int x )" declare the same
function, most people tend to feel that the const has no place
there. (Note that you can declare the function
"f( int const x )" and still define it without the const.)
[...]
Ah, I see. That makes sense. But if you'll indulge me, what about asking
the same question in the context of a brand-new, legacy-free C++?
I suspect that const would be the default, and we'd have a
qualifier mutable.
Right. So what about this question: how often do you think functions
modify their arguments vs. _not_ doing so?
I don't have any real statistics, but my feeling is that
functions only very rarely modify their arguments. Although it
depends---I's say that the standard idiom in an algorithm using
STL iterators would be:
while ( begin != end ) { ... ; ++ begin ; }
where begin is an argument.
Using out arguments is even rarer, I think. (In fact, C++
doesn't support true out arguments, where the object is first
constructed in the function.)
Just a quick tangent, once again in the world of hypotheticals, I posit
that if C++ supported multiple return values natively (without the need
for structs or boost tuples), then the need for mutable parameters would
be even further diminished. Does that seem reasonable?
It would reduce even more the use of out parameters (non const
references). In practice, I find that with very few exceptions,
the only times I want multiple return values is when one is a
status or a return code, indicating success or failure (but
possibly with multiple states for each). That's easily handled
with a templated Fallible class.
Mulitple return values would change a lot if we also had
multiple assigns, like some languages. But we don't, and I
can't quite see how to make them fit into the C++ grammar.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]