Re: future of the C++
nmm1@cam.ac.uk wrote:
The first point is to decide what purity means - and that's not
obvious, even at the hardware level! For example, floating-point
is not strictly pure once you allow IEEE 754 exception flags or
even (God help us!) fixup by interrupt. Not a C++ problem today,
but becomes one in C++0X.
Most of the C++ library could be defined as pure or impure, but
there would be screams from implementors who did things differently.
And there are a lot of borderline cases in the inherited C library.
POSIX massively increases the confusion, of course :-(
And then there is the dreaded exception question. Does the licence
to raise an exception destroy purity? If so, the previous questions
more-or-less state that nothing non-trivial can be pure. But, if
not, some extremely careful design is needed to avoid making the
concept meaningless.
Excellent observations. We faced those problems in D, and here's what we
decided:
1. Exceptions were divided into two categories, recoverable and
non-recoverable. Pure functions can throw both categories, but since
non-recoverable ones are not recoverable (!) it is ok in such a case to
violate purity. If recoverable exceptions are thrown, they must be
thrown every time the same arguments are supplied. (Non-recoverable
exceptions would be things like seg faults and assertion failures.)
2. Pure functions can allocate memory, for the practical reason that if
they couldn't, their usefulness is severely compromised. This has the
consequence of requiring that memory allocation failure inside a pure
function be regarded as a non-recoverable exception.
3. There was a looong thread about what to do about the floating point
exception flags & global modes. None of the ideas about how to fit them
in with purity seemed very practical. The end result was that we just
decided to leave that up to the end user. We felt this was justifiable
because it's very rare to have a program that fiddles with the rounding
modes or reads the FP exception flags.
4. We've gone through the C standard library headers, and tagged the
pure functions (like memcmp) as pure. It's true that the C standard
doesn't guarantee any of them are pure, but all the ones we know about
are pure, and reasoned that only a perverse implementation of them
wouldn't be.
So far, these decisions are holding up well in real life. There are
still have some issues, like should operator== be required to be pure?
---
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! ]