[Python-Dev] Re: [Python-checkins] python/dist/src/Include compile.h,2.38,2.39 parsetok.h,2.19,2.20 pyerrors.h,2.63,2.64 pythonrun.h,2.55,2.56 symtable.h,2.10,2.11 (original) (raw)

David Abrahams dave@boost-consulting.com
Wed, 11 Dec 2002 12:44:03 -0500

"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 .

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