[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

[David Abrahams]

"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