On 07.06.2012 22:34, Peter Alexander wrote:
On Thursday, 7 June 2012 at 16:05:00 UTC, bearophile wrote:
"Now What?" by Sean Parent (Adobe).
I very much liked that presentation. It's nice to see someone looking at
C++ in the big picture.
I also liked his comment on the "beauty" of std::pair
C++ has far worse size to power coefficient. The result is that generic
programming is 2-10x longer ( + some pathological cases with up to
~100). Not to mention readability.
I mean Boost doesn't do anything VERY advanced, it's just hard to keep
focus on your goal while bending C++ compiler to your needs.
"Complete std::pair 372 Lines"
D suffers from this too. Here is std.algorithm.min (ignoring the
definitions of CommonType, mostNegative, and isIntegral).
template MinType(T...)
{
static assert(T.length >= 2);
static if (T.length == 2)
{
static if (!is(typeof(T[0].min)))
alias CommonType!(T[0 .. 2]) MinType;
else static if (mostNegative!(T[1]) < mostNegative!(T[0]))
alias T[1] MinType;
else static if (mostNegative!(T[1]) > mostNegative!(T[0]))
alias T[0] MinType;
else static if (T[1].max < T[0].max)
alias T[1] MinType;
else
alias T[0] MinType;
}
else
{
alias MinType!(MinType!(T[0 .. 2]), T[2 .. $]) MinType;
}
}
MinType!(T1, T2, T) min(T1, T2, T...)(T1 a, T2 b, T xs)
{
static if (T.length == 0)
{
static if (isIntegral!(T1) && isIntegral!(T2)
&& (mostNegative!(T1) < 0) != (mostNegative!(T2) < 0))
static if (mostNegative!(T1) < 0)
immutable chooseB = b < a && a > 0;
else
immutable chooseB = b < a || b < 0;
else
immutable chooseB = b < a;
return cast(typeof(return)) (chooseB ? b : a);
}
else
{
return min(min(a, b), xs);
}
}
I find this very ugly.
Very straightforward, very convenient and (importantly) optimal result.
Like in "I would have written it by hand exactly the same" barring
generic grease like CommonType & mostNegative that resolves to nothing
most of the time.
To be honest, I would be much happier without all
that mostNegative and common type stuff. If I want to get the min
between a short and an int I'll just cast them appropriately. I'd much
rather have a simpler standard library than a complicated one for the
sake of a little convenience.
STL & (to be frank )CRT is damn contrived. Ever tried reading printf
source from GLIBC ? A polite recommendation: you'd better keep you
favorite sedative nearby while you are at it.
Yet memset is fast as lightning and handles ton of cases with ease, and
I don't have to think about it. The whole point of libraries FWIW.
Don't get me started on std.algorithm.find...
Why not ? It's perfect example of goodness of generic programing,
flexibility (for free) + speciality (when you need) for the win.
If you language lacks such construct you end up inveting ways around it:
- make findInt, findString, quickFindString, findPerson etc. * number of
containters
- shoehorn everything into a simpler design: qsort, boxing-unboxing etc.
The same question is valid for D. It seems important.
It is. D addresses vectorization a little with its array ops (although
ISPC (http://ispc.github.com/) destroys both D and C++ in this arena)
and we're yet to see if D provides scalable parallelism.
std.parallelism? It handles SMP without breaking a sweat.
GPGPU would be real nice though. And things like restrict(...) from C++
AMP could help, or better support for CTFE + DSLs.
--
Dmitry Olshansky
