Re: What's wrong with this picture?
lontimo@gmail.com wrote:
min and max have a long history of being difficult to implement without
gotchas lurking. This is often a surprise to programmers who think that
all they need is something like: ...
In case you didn't notice my post was not about min/max. Recently
there is more and more code like that (and much worse) in standard
library and other "advanced" C++ projects. I have written such code
myself and I enjoyed the process just like the next guy. But unlike
the next guy, I also understand how little practical value lies in
such very time consuming, hugely overcomplicated and barely readable
piles of garbage which we so lovingly call "clever template magic".
In a platform for testing new language and libraries design ideas we
could very well sacrifice clarity and briefness for other
requirements, but for a practical programming language clarity and
briefness have to remain high on the list of priorities. So next time
when you see code like "Improved min/max" above, just take a step
back, look at it again, then repeat after great John McEnroe: "You
cannot be serious!"
I agree; this is perhaps a good example of the law of diminishing
returns at work. The min/max solution in the (rejected) proposal
painstakingly handles by hand all of the exceedingly uninteresting
corner cases and also all semantics-dependent static typing (e.g. having
min invoked against an unsigned short and a signed char yields a signed
char, unless I misunderstood the code). It's a sort of assembler of
metaprogramming that achieves the right result by appropriately handling
on a case-by-case basis all of the possible situations.
A second-order, and very interesting, point that lurks beneath this
discussion is: what do we compare the solution against? As far as I
know, no language except the nascent D 2.0 does a better job without
paying in some way, usually in terms of efficiency, expressiveness, or
both. And I think we agree that costly abstractions are easy to come
across.
So probably the right question to ask is not "what's wrong with C++?"
but instead "what's wrong with static typing technology at large?" It's
a criticism directed more at language design in the large, rather than a
criticism of C++ in particular. If the programming languages community
has not gotten to the point where the min and max functions can easily
and painlessly expressed and typechecked, probably it's in fact a tour
de force that C++ managed to do it, even if it huffed, puffed, and blew
a gasket in the process.
The third-order and the even more interesting point lurking is the
forensics perspective: where did C++ make the wrong turn, and what
better type system could it have devised? And I have a little opinion on
that. It's a combination of factors in which mishandling integral types
is a part of, but the killer is IMHO the binding of an rvalue to a
reference to const. While such binding does help certain situations and
avoids code duplication, it turns out it's lethal for others because it
allows rvalues to cross back the Styx and show themselves as valid
lvalues, claiming to have an address, when in fact they are zombies.
Most of the machinery in any improved min/max implementation is
dedicated to this one issue.
If I could turn the time back, I'd try to suggest looking into other
means for handling rvalues and disallow rvalue binding to const
reference. It just did too much harm.
Just for the record, one possible way to handle rvalues and lvalues
without code duplication is staged type inference, which is what D 2.0
does. A complete implementation of the min function in D that achieves
all of the objective of the mentioned C++ proposal (save for always
computing the tightest type for the result) is:
typeof(b < a ? b : a)
min(A : ref T || T, B : ref U || U, T, U)(A a, B b)
{
return b < a ? b : a;
}
The key is the "A : ref T || T" type matching. It means that during type
deduction, type A is matched against the pattern ref T (T& in C++), and
should that fail, try the second match, which always succeeds. This
staged type matching, combined with D's refusal to bind an rvalue to a
reference, is what makes it possible to implement min in a manner that's
at the same time sound, efficient, and compact. I'm sure there should be
ways to do things even better than that, but they're not that easy to
find (and then again the law of diminishing returns would apply, as it's
hard to get much more compact than that).
Backporting that to C++ would look like this:
template <class A = T& || T, class B = U& || U, class T, class U>
common_type<A, B> min(A a, B b)
{
return b < a ? b : a;
}
which would again specify what patterns the types A and B should try and
in what sequence.
Andrei
---
[ 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 ]