[Boost-users] Re: [OT a bit] Condition variable and const-correctness

From: Weston Markham (wmarkham_at_[hidden])
Date: 2003-10-22 20:35:45

This might actually be slightly less off topic than the previous post,
because it parallels the way that I think about that condition::wait
method...  Anyway, I'm curious what people think about:

void perverse_strcpy(
    const char *src,
    char *dest,
    const char *done  // note const
) {
    while (!done) {  // note we expect change
        *dest++ = *src++;
    }
}

The caller can do something like:
src = "hello world";
dest[strlen(src)] = 1;  // store a nonzero value
perverse_strcpy(src, dest, dest+strlen(src));

Yes, its a kinda stupid and, well, dubious function.  However, the point is
that "const char *" simply means that the pointer points to a char that can
only be accessed as a "const char" through that pointer.  It does not imply
that the referenced thing is physically const.  Nor does it imply that the
referenced thing is logically const.  (meaning that non-const methods can
still be called on an object that has a "const Foo *" pointing to it; they
simply can't be called through that pointer.)

Does this run counter to what people believe the semantics of "const char *"
to be?  Are compilers permitted to optimize out the check of "!done" based
on const-ness?  (IIRC, they actually may in some related examples, if "src"
and "dest" are types that should not alias to "done"; but this is not the
case here)  Is there any undefined or implementation-defined behavior of the
above code?

As separate aside, I believe that "physically const" refers specifically to
a property of an object, say, the string constant "x".  It is the reason
why:

const_cast<char*>("x")[0] = 'y'

... results in undefined behavior.  The const keyword _could_ be used on an
interface to indicate that a method will not produce undefined behavior when
invoked on an instance that is actually physically const.  This is different
from using the const keyword to identify methods which maintain "logical
constness".  The latter meaning (whatever that may be) is what I believe is
used in practice.  (and the language is, I believe, designed to support this
other meaning)  Of course, I'm not, in some cases, sure what that meaning
is!

I suspect, by the way, that different people may have different ideas of how
the const keyword should be applied to interfaces in practice.  Each person
might have an internally consistent viewpoint, but there may still be
several mutually incompatible views.  (I'm pretty sure that there are at
least a few.  I hope they are not as "notoriously arbitrary" :) as naming
conventions!)

Lastly, just because it amuses me:

C++ Shrink:  How does that const Foo * make you feel?

Programmer:  I feel frustrated, doc!  I want to change things, but I can't.
I know that the other coders do things that I can't; I can see all the
changes that they make!  Why not me?

C++ Shrink:  Hmm.  Interesting.

Weston Markham