Re: future of the C++
Mathias Gaunard wrote:
On Jul 5, 6:07 pm, Walter Bright <newshou...@digitalmars.com> wrote:
Now another fellow on your team adds a global state dependency somewhere
deep in
that call hierarchy. How are you to know? Suppose someone else derives and
overrides my_pure_function with an impure one? How are you to stop that?
What if, between calls, someone modifies something s is transitively
pointing to?
If you can't enforce the project team to follow the coding standards
for that given project, and to read the comments that say "this
function is pure", then I think you already have some big problems.
The problem with reliance on coding standards is:
1. People are human. Experts are human. They take shortcuts. They make mistakes.
If they didn't, we could dispense with all compiler error checking. I don't
think anyone is ready to get rid of type checking in C++ and rely on coding
standards instead?
2. It's nearly impossible to manually verify if a particular function is pure or
not by having manual code reviews. A coding standard that cannot be verified is
programming based on hope and prayer. When you've got millions of lines of code,
how practical is it to trust in hope and prayer?
3. If coding standards were reliable, nobody would need tools like Coverity,
which are thriving.
4. I'm one of those guys who likes to work on his own car. But when it's night,
cold, raining, I'm dressed in good clothes, and far from home, I want the
freakin' car to work when I put the key in. And I want the compiler to check
purity for me. It's a job well suited to automation. Would you rather push a
button and get an instant *guaranteed* 100% check, or direct your (very
expensive) staff to spend many boring, tedious hours doing a code review with
only an 80% confidence they got it right?
Saying a function is pure is actually quite similar to what we do in
contract programming. People seem to do fine with contracts that are
simply documented, without any checking done by the compiler, even if
help would certainly help debugging.
I see absolutely no advantage to relying on hope and prayer rather than
guaranteed checking by the compiler.
Because of this, I suspect that trying to use purity and immutability
purely by
convention is doomed to failure.
(And also, since the compiler cannot know about its purity and
immutability, it
also cannot take any advantage of that information to produce better
code. The
compiler cannot even cache pointer to const values.)
Some compilers (I don't know about Digital Mars, but I hope it does!)
allow to tag a function as pure using attributes. If they can deduce
with static analysis that the function isn't really pure, they could
also emit a warning.
Non-standard extensions are not C++, and this thread is about C++0x for FP.
My experience with adding non-standard extensions is, quite simply, nobody uses
them. And I mean nobody, not even the person who tells me "it would be nice if
you added an extension to do X" and convinced me to do it. Adding non-standard
extensions to a C++ compiler is a complete waste of time.
People won't use them because C++ is standardized and they want their code to be
portable. It's a sensible sentiment.
I did add contract programming to C++. Nobody uses it. In D, it's used often,
because people expect it to be available in any D compiler.
I did not add a function purity attribute to the Digital Mars C++ compiler. It
wouldn't work anyway, as for a function to be usefully pure, the arguments to it
all have to be transitively immutable, and there's no way to specify that in C++
without rebuilding and redesigning most of the type system.
---
Walter Bright
free C, C++, and D programming language compilers (Javascript too!)
http://www.digitalmars.com
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]