Re: C++0x - a quick and dirty introduction (as of November 2007)
James Dennett wrote:
Walter Bright wrote:
Jerry Coffin wrote:
Now foo canNOT be evaluated at compile time, and all the code
that depends on that is broken. I need a way to specify the
requirements my function meets -- and the compiler should never
assume it meets any more requirements than it specifies, even if
its current implementation might be able to do so.
I understand what you're asking for, but I don't regard it as a big
problem because it's not like your code will compile but fail at
runtime. It just won't compile, and the reason it won't compile
will be obvious.
And can _still_ be a big problem. The vendor whose library you used
changed it in a new release (which you need because of fixes or new
features), and now your code doesn't work with it. The changes
needed may be extensive.
There's an awful lot more to contract programming than constexpr
provides, very little of which is supported by C++ (I think the contract
programming proposal was rejected). Even that is no guarantee that
library semantic changes won't break existing code. For example, C++
doesn't support the 'out' parameter storage class, where the function is
obligated to initialize the argument. C++ does support
pass-by-reference, but there is no semantic clue if it is in-out or out.
Even worse, constexpr actively prevents the library implementor from
adding any argument checking code to it. Constexpr functions will suffer
from atoi's well-known deficiency:
"When atoi encounters a string with no numerical sequence, it returns a
0 (zero). Also, if the string holds a valid sequence of digits that
represents the number 0, it would also return a 0, making it impossible
to tell from the return value alone whether the string held a valid
number or not. The newer function strtol does not have this deficiency."
-- http://en.wikipedia.org/wiki/Atoi
And it could have been avoided if you'd used C++0x instead of D,
because the compile-time constant nature of the function would have
been a compiler-enforced part of its explicit *interface*, not just a
mutable artifact of its implementation.
The requirement that the compiler statically prove that constexpr
functions are executable at compile time for all possible parameter
values is very restrictive on the forms the function can take,
otherwise one has the famous halting problem.
Right. A compile-time language ought not to be Turing complete, even
if only because of resource limitations.
What that means is that constexpr functions cannot throw exceptions,
cannot have reference parameters, cannot do recursion, and cannot do
iteration. People who need to do non-trivial computations at compile
time will be forced back to using template metaprogramming, which
(horrific as it is) is Turing complete. Or they'll stick to using the
macro preprocessor, which is also Turing complete.
----
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]