const

Walter Bright newshound1 at digitalmars.com
Thu Mar 27 16:23:14 PDT 2008


Bill Baxter wrote:
> Walter Bright wrote:
>> 4) The C++ const is ubiquitous and a lot of people are comfortable 
>> with it, but it turns out that few understand what it guarantees and 
>> what it doesn't. C++'s const is so weak that it is more of a 
>> convention than a guarantee. This weakness enables things to be done 
>> with it that are just fundamentally unsound, and contribute to C++ 
>> being a very difficult language to write and verify sound code in.
> 
> Or maybe, despite the weaknesses it manages to cover 95% of cases that 
> arise, and thus it represents a good trade-off between guarantees and 
> ease-of-use.

That is true looking backwards. But C++ const is no good for the future, 
and this will become more and more apparent. C++'s troubles with 
multiprogramming are just beginning.


>> 1. It makes function interfaces more self-documenting. Without 
>> transitive const, for all pointer/reference parameters one must rely 
>> on the documentation (which is always missing, out of date, or wrong). 
>> Note that without transitivity, C++ const is nearly useless for such 
>> self-documentation, which is why C++ programmers tend to rely on 
>> convention instead.
> 
> That sounds almost completely wrong to me.  C++ programmers tend to use 
> 'const' in their function signatures to document the things that 
> shouldn't change.  That sounds like self-documentation to me.  What do 
> you mean by "rely on convention instead"? Please explain.

First, it's legal to cast away const and then change the underlying 
data. This is frowned on by convention, but it's *legal*.

Second, and much worse, consider:

	void foo(const T& t) { ... }

what does that tell you? That t's value won't be changed by foo(). Ok. 
But what if T is a tree data structure? const tells you NOTHING AT ALL 
about the mutability of that structure. foo() can rewrite everything in 
that tree but the root node. EVERYTHING, and it's all perfectly legal 
without even having to resort to casting. This is, of course, frowned 
upon by convention, but it's nothing more than convention. It's about as 
effective as annotating t with a comment:

	/*doesn't change any part of T*/

Now, you could go through the components of T and mark them all const, 
too, but that doesn't work if T is an opaque type (opaque types are 
becoming more and more important as an encapsulation device).

The beauty of transitive const is that everything reachable through t 
cannot be modified by going through t, and this will be true regardless 
of whether T is opaque or transparent.

>> 2. It makes for interfaces that can be relied upon, which becomes 
>> increasingly important the more people that are involved with the 
>> code. In other words, it scales very well. People who are involved 
>> with projects with large teams of programmers tell me that lack of 
>> const makes their lives difficult because they cannot rely on the 
>> compiler to enforce convention. The larger the team, the worse it 
>> gets. Managing APIs is critical to a large project - it's why BASIC 
>> doesn't scale (for an extreme example).
> 
> I dunno about this one.  Java seems to scale pretty well.  The 
> long-standing enhancement request asking for const in Java was closed by 
> Sun as "will not fix"[1].  They don't seem to think it's a show-stopper.
> 
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070

Java can't fix it and be backwards compatible. They're stuck. If they 
had a chance of a do-over, I have little doubt they'd go for transitive 
const.

The pressure to add const to Java comes up again and again. It's not 
going to go away, and it's just going to get worse. Java missed the boat 
on multiprogramming, too (it's not in as bad a shape there as C++, but 
Java's design is still based on an obsolete view of how to do 
multiprogramming). C++0x is trying to catch up with Java, but Java is 
way behind functional languages. It's like the man with no legs trying 
to catch the man hopping on one leg, while the man with two runs away 
from both of them.


>> 3. Const transitivity makes for some interesting optimization 
>> opportunities. The value of this has not been explored or exploited.
> 
> Opportunities are great.  But asking everyone to eat their brussel 
> sprouts for an indefinite amount of time because of some *potential* but 
> not guaranteed future benefit is not going to get many people excited.

A lot of people are excited about C++0x, which is still many years away. 
In fact, a lot people say C++0x is why they won't use D which has those 
features today.


> If improved optimization is the goal then there are lots of 
> opportunities for improvement in D's generation of FP code, for 
> instance, or so I've heard.  And those don't require any language 
> changes.  Even with fancy language features, can D really hope to 
> compete against the likes of Intel and Microsoft or even GCC in the 
> category of "best optimizer"?

I agree the optimization capability isn't a compelling reason by itself.


>> 4. Here's the biggie. Points 1..3 are insignificant in comparison. The 
>> future of programming will be multicore, multithreaded. Languages that 
>> make it easy to program them will supplant languages that don't. 
>> Transitive const is key to bringing D into this paradigm. The surge in 
>> use of Haskell and Erlang is evidence of this coming trend (the killer 
>> feature of those languages is they make it easy to do 
>> multiprogramming). C++ cannot be retrofitted to supporting 
>> multiprogramming in a manner that makes it accessible. D isn't there 
>> yet, but it will be, and transitive const will be absolutely 
>> fundamental to making it work.
> 
> Again talk about potential is great, but until I've seen something more 
> concrete I'm very skeptical that adding a dash of invariant into the mix 
> is magically going to make D a multi-core champion.  I suspect it will 
> require very careful use of invariant in the parts of code you want to 
> make parallel, and so it won't be just a magical switch that suddenly 
> makes all your code run 10x faster.  It'll be something that requires 
> careful planning to take advantage of.

I fully agree that invariant by itself doesn't magically turn D into a 
multiprogrammer's dream. But invariant is a crucial brick in building 
multiprogramming support. The lack of it is why C++ will never be easy 
to use for multiprogramming.

We're just on the cusp of a huge push towards multiprogramming. We have 
to be ready for it, or we'll be left in the dustbin of history.


> I'm also doubly skeptical because if easy parallelism was the goal, an 
> implementation of something akin to OpenMP should be possible even in 
> D1.0.  It doesn't require const/invariant.  OpenMP works fine with C. It 
> may not do everything that's possible in the grand vision, and may 
> require more user intervention to employ, but it doesn't get much 
> simpler than slapping a "#pragma pfor" in front of a for loop and having 
> it automatically parallelized.  And probably a lot of the thread 
> management infrastructure would be similar to what is required by any 
> grand vision anyway.  So it wouldn't be wasted effort, I don't think.

OpenMP is a massive kludge. I don't believe that is where the future lies.

>> Of course, if you're writing single-threaded one man programs of 
>> fairly modest size, const is not particularly useful. I quite agree 
>> with that. And in D you can effectively ignore const by just not using 
>> it, or by using D 1.0. The only place const is imposed is with the 
>> immutable string type.
> 
> "Just use 1.0" is only a temporary solution.  You have to phase out D1.0 
> at some point.

It'll get phased out when it no longer has a user base.

> D is niche enough already without the dilution of having 
> two major, incompatible versions.
> 
> And arguments to just ignore const don't really work due to the viral 
> nature of const.  If you want to use a const-correct library, you will 
> notice it when the library returns a const something to you, and you 
> find you can't do anything with it unless you cast away const.  But then 
> you've entered into undefined territory and your program can no longer 
> be considered correct.  If you're a library writer then there will be 
> pressure on you to make your libraries const-correct.  Therefore most 
> libraries will eventually end up being const-correct, and people who 
> want to ignore const will have very few alternatives.  I've seen very 
> few C++ libraries that don't at least try to be const-correct.
> 
> For "just ignore const" to be a realistic recommendation there would 
> need to be a "just ignore const" switch in the compiler.

As far as library writing goes, you're right that you cannot ignore 
const. But application writers pretty much can, as I pretty much ignore 
const in C++.



More information about the Digitalmars-d mailing list