"Tim Peters" <tim@zope.com> writes:
> A non-broken compiler always allowd passing a
>> T
>> actual argument to a
>> const T
>> formal argument, so I never object to those, and indeed I sneak const into
> prototype arglists whenever it's convenient.
I don't know if C differs from C++ in this respect, but in C++, const
in a prototype argument list has no effect whatsoever (unless
modifying the referent of a pointer or reference). So:
void f(const int x);
is identical to
void f(int x);
In fact, a very useful idiom is:
void f(int x); // prototype. No const; it communicates nothing
// useful to the caller
...
void f(const int x) // implementation. I know I can always use x
{ // and get the original argument value
...
}
> That's a different issue than making all of Python "const correct", which
> has been a near boundlessly low bang-for-the-buck effort in every project
> I've seen undertake it. Try passing a
>> const T*
>> actual argument to a
>> T*
>> formal argument and a non-broken compiler will complain, and then
> either casts have to proliferate, or consts have to proliferate, to
> stop the errors. Sometimes this is called "const poisoning", at
> least by objective observers <wink>.
There's a long discussion even now on comp.lang.c++.moderated about
whether const-correctness is a dogma.
--
David Abrahams
dave@boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
