Re: const

From: Walter (walter_at_digitalmars.nospamm.com)
Date: 07/26/04 

Date: Mon, 26 Jul 2004 20:51:18 GMT

"Paul Hsieh" <qed@pobox.com> wrote in message
news:796f488f.0407261112.1a91e63@posting.google.com...
> "Walter" <walter@digitalmars.nospamm.com> wrote:
> > "Michael Jørgensen" <ingen@ukendt.dk> wrote:
> > 1) const is not a storage class, it's a type modifier. This means it has
> > ripple effects throughout the typing system, requiring subtle and
careful
> > integration with function overloading, template partial specialization,
cast
> > overloading, etc. This can get pretty complicated.
> Its exactly as complicated as required. If you don't comply with
> const modifiers, your code is simply wrong.

I meant in the language specification and compiler itself, not the user
code. And you're right, I did solve the complexity problem in my own code by
not using 'const' :-)

> > 2) Once you've decided to make a program const-correct, the code winds
up
> > being littered with 'const', to the point where it seems (to me) to make
the
> > code look ugly and obscure.
> The you are using it wrong. const mostly percolates downward, not
> upwards. I.e., non-const things naturally convert to const, just not
> the other way around. So how much "const" is in your code is usually
> managable and has the side effect of describing a minimal behavior for
> functions without knowing their implmenetation.

A lot of other people must be using it wrong, too, as a grep for "const"
usually shows a very large number of hits, and most of those are function
declarations with const everywhere, scrolling the text off the right edge
<g>. It percolates through the code, since once declaring a function's
parameters as "const" means the functions it calls wind up needing to be
adjusted to be "const" as well, and recursively onwards. (Unless you're
willing to remove the const'ness with a cast, which kinda defeats the
purpose.)

> > [...] I keep thinking when looking at it "here a const, there a const,
> > everywhere a const const". <g>
> You can't put a const on objects that are modified (unless you cheat
> with aliasing or bad casting). What kind of code are you writing
> where you don't modify very many of your objects?

Most of my code is like that (I write compilers).

> > 3) const as a hint to the compiler for better code generation is
useless.
> In the case of good cross-file compilers, you are right, it should be
> able to derive const modifiers where you have omitted them
> automatically (actually that would be a useful warning IMHO:
> "parameter type should be modified with const").

I don't know how good a cross-file compiler could be - it would have to be
able to *prove* that no other non-const pointer could possibly point to the
same data. That's a tall order.

> But where it cannot be derived (because you have to compile file by
> file, or you are linking precompiled libraries) the degree to which
> "object cloning" is possible will be assisted by knowing that function
> is unable to modify it.

No, because that function could internally cast away the const'ness. You
could argue that maybe the user shouldn't do that, and you might be right.
But I'll tell you from experience that the compiler will get blamed for
generating code when it doesn't work with your compiler but does work with
Brand X, Y and Z compilers.

> In any event, the compiler's ability to use const to assist it where
> leaving it off would force it to be too conservative is probably
> marginal compared to its real purpose of making your code more
> correct.

C++ just has too many loopholes in the type system to have the optimizer
rely on const'ness.

> > That's because it's perfectly legal in C++ to have things that are const
> > have non-const aliases that can change the values.
> "restrict" dude. Its here now, even for C/C++ compilers that have
> decided to abandon C99 compilance.

"restrict" is part of C99, but not C++. But let's assume restrict comes into
widespread support and use. Now, instead of labelling types as being
"const", they'll be "const restrict". If I think that sprinkling "const"
throughout the code is not aesthetically appealing, I'll think even less of
"const restrict" <g>. Furthermore, "restrict" is not a property that the
compiler enforces, it's a guarantee by the programmer. Programmers make
mistakes, and aliasing issues have proven in the past to be something that
programmers have a very hard time understanding and applying correctly.

> And of course there is the
> no-alias property that compiler is able to automatically deduce
> without this programmer assistance.

I'm not convinced this is technically feasible in the general case. And if
it is feasible, then the compiler would not need "const" at all to generate
better code. So, the incremental benefit of "const" to the optimizer is
still zero.

> > 4) In all my years of programming, const has never saved me from a bug.
Not
> > once.
> Odd -- const has probably saved me from one of the deepest bugs in my
> code I've ever encountered. A function I wrote modified one of its
> input parameters temporarily while operating on it, then put it back
> to the way it was before returning -- so it seemed "operationally"
> const without truly being so. I called this function twice on the
> same parameter in a multithreaded environment -- oops.

I won't argue that it will never find a bug, it obviously did find one in
your case. But it has never found one for me, and it has a high cost in both
language complexity, compiler complexity, and poor aesthetics in production
code. That adds up to a poor cost/benefit ratio, a ratio by which all
language features should be judged.

> How would I
> find such a bug, if in my mind I didn't see the semantic difference
> between "operationally const" and actually const?

Writing correct multithreaded code is very hard to do and very hard to
debug. You'd be finding it the same way other threading bugs are found <g>.

Relevant Pages

  • OK to disguise a macro function as a function?
    ... functions to warn the programmer to be picky about what arguments they ... Currently I'm using an embedded systems compiler for programming ... because there's no stack (another strategy to save memory). ... the compiler is very particular about what it considers const. ...
    (comp.lang.c)
  • Re: Writing single bits to a file
    ... The 'const' keyword provides the same kind of benefit that prototypes ... enabling the compiler to warn you if it detects the fact that you ... I had not gone and more correctly fixed up the precedence heirarchy (unary ... I like to implement scripting languages for breakfast ...
    (comp.lang.c)
  • Re: Anders Hejlsberg comment on immutable objects
    ... > all references are implicitly const is in fact immutable. ... >>against the contract provided by classes, ... >>real contract should be enforced by both the compiler and the runtime, ... cast it away, and as I've said many times, everyone, me and you included, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Index a #define string
    ... In this case, i wouldn't use an array myself but a const char * const, but ... should one make it of static storage? ... If they were on the stack, where do you think their values ... You mean that the compiler optimises it out. ...
    (comp.lang.cpp)
  • Re: Making C better (by borrowing from C++)
    ... is actually needed often allows you to declare it const (if it is ... increased opportunities for compiler optimization. ... without programmer assistance. ... lapse and mixing up the order of the arguments to memcpy(). ...
    (comp.lang.c)