Re: Future of C++
On Aug 11, 4:58 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Aug 11, 11:16 am, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
[...]
Besides, even functions with telling names can (and often
do) return value in different ways. I will take your
example:
compare:
int increment(int i) { return i + 1; } // #1
and
int increment(int &i) { return ++i; } // #2
Increment is a verb. Thus, the first function is very purely
named, since it doesn't increment anything.
purely?
? What was I thinking of? (Clearly, maybe?)
"poorly", <url:http://www.thefreedictionary.com/poorly>.
As I recall, in Pascal those Peano arithmetic functions were
called Succ and Pred.
I probably meant "clearly", but "poorly" is better. In C++,
it's name is ++.
Oh, then you're not thinking of the first increment function,
which isn't ++. But you wrote "the first function". So now
I'm confused.
The first function was "increment"---I understood the word
compare to mean that there were two versions of only one
function (the first version, obviously, erroneous, since no one
would name a function increment if it didn't increment---except
maybe the authors of the STL, see std::remove).
[...]
If enum's were enumeration types, the language could
doubtlessly define ++ and -- for them, as well. They
aren't, so it can't.
The programmer can define these operations for each enum type.
And get it wrong:-). (I often define operator| and operator& on
enum types. And even today, typically end up with infinite
recursion first go at it.)
I might add that the ++ and -- operators are trickier than they
look. Since I had code to parse enum declarations already (in
order to generate name to value mappings), I added the
possibility of generating the logical operators (but only if all
of the enum constants had assigned values) and incrementation
and decrementation (but only if none of the enum constants had
assigned values). Getting the incrementation and decrementation
right was a lot more difficult than I would have thought (but
probably because I was looking for something generic, which
could also be used to iterate over all of the values of the
enum).
I haven't checked C++0x draft, but perhaps, if it isn't there already,
namespace std
{
template< typename T >
T succ( T x ) { ++x; return x; }
template< typename T >
T pred( T x ) { --x; return x; }
}
wouldn't be so bad an idea (for clarity I didn't sketch in use
of e.g. traits type to use for choice between implementations,
e.g. for an immutable arithmetic type T one would instead have
"return x + 1;" and "return x - 1;").
Sometimes when using iterators this functionality is needed.
They'd be useful for enum types as well, with the restriction
that they're really only meaningful for enum types without
explicit initializers for the enum values.
succ and pred really only useful for enum types with defined
++ and -- operations.
As written above, yes. I think I was reading more into it than
you meant.
Explicit initializers or not is irrelevant, as far as I can
see. Well, mostly :-), anyway, but there is the in-practice
that one is less likely to define ++ and/or -- operators for
an enum type with where explicit initializers are used to
provide non-successive values in general.
Of course, for that, you'd need a traits which caused the
functions to add the necessary casts, and which
automatically chose the correct underlying type.
No, when I mentioned a traits class I was thinking of
different implementations of succ and pred depending on
whether the type T is immutable (pure value type) or not.
The above implementation should work well for an enum type T
with defined ++ and --.
At least, that was my intention. ;-)
Yes. I was thinking of it as a replacement for ++, for some
reasons. I think I understand what you're getting at now.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34