C++Now! 2012 slides

[Dmitry Olshansky]

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