The slide packs of the conference C++Now! 2012 are available:
https://github.com/boostcon/cppnow_presentations_2012

Some of those slides packs seems too much large for the GitHub blob serving interface. To solve this problem download them all from as zip here (large amount of stuff):
https://github.com/boostcon/cppnow_presentations_2012/downloads

Among those many (sometimes large) slides packs there is some good stuff. I think some of that stuff is interesting for D programmers too. I have chosen four of them.

----------------------------

"50 Boost C++ Libraries in 180 minutes", by Boris Schaling:

Among the Libraries shown, in Phobos I'd like the 12 libraries:

- Boost.Pool Memory management with an allocator based on a singleton.
- Boost.Multiindex Create new containers which provide multiple interfaces to lookup items.
- Boost.Bimap A ready-to-use container based on Boost.Multiindex with exactly two interfaces.
- Boost.CircularBuffer A fixed-size container which overwrites items if you keep on inserting more (I'd like a dynamic version too of this).
- Boost.DynamicBitset Works exactly like std::bitset except that the size can be set (and modified) at run-time (in Phobos I'd like a in-place-allocated fixed-size one too).
- Boost.Flyweight Flyweight pattern: Sharing common data between objects to minimize memory usage.
- Boost.Accumulators Containers which calculate new results whenever a new value is pushed into them.
- Boost.Rational Use exact representations of rational numbers like 1/3 in C++.
- Boost.Graph A library to solve problems like finding the shortest route between two subway stations.
- Boost.Conversion Three cast operators for numbers and polymorphic types.
- Boost.MinMax Find the minimum and maximum of two or multiple values with one function call.
- Boost.Hash Classes and functions to return hash values and to build your own for user-defined types.

----------------------------

"Metaprogramming Applied to Numerical Problems - A Generic Implementation of Runge-Kutta Algorithms", by Mario Mulansky and Karsten Ahnert: this should be not hard to do in D, with less and simpler code.

----------------------------

"More Useful Computations in the Same Duration: Optimizing Embedded Hard Real-Time Code in C++", by Scott Schurr:

Page 46: #pragma no_alias Are we going to need something like that (or "restrict") in D too?


Page 55, Managing Code Bloat:

Maybe D should offer a built-in solution for this common C++ coding pattern:

Class TCB_impl {
    template<int chan> friend class TCB;
    inline void status(int chan) { ... }
    void source(int chan, int st) { ... }
};

template <int chan>
class TCB {
public:
    inline void status() { impl_.status(chan); }
    inline void source(int st) { impl_.start(chan, st); }
private:
    TCB_impl impl_;
};


Some time ago I suggested the attribute @templated(). If inside its () there are no variable names then that function/attribute is not templated, so it's like the functions/attributes of TCB_impl:


class TCB(int chan) {
public:
    void status() { status_impl(chan); }
    @templated() void status_impl(int chan) { ... }

    void source(int st) { source_impl(chan, st); }
    @templated() void source_impl(int chan, int st) { ... }
}


But maybe something better is possible:

class TCB(int chan) {
    @templated() immutable mchan = chan;
public:
    this() { this.mchan = chan; }
    @templated() void status() { /*uses mchan*/... }
    @templated() void source(int st) { /*uses mchan*/... }
}

----------------------------

"Now What?" by Sean Parent (Adobe).

Slide 29 (page 18), "Desktop Compute Power" shows that nowdays for some tasks GPU and vectorized code are much faster than regular sequential C++ code.


Slides 36 and 38:
That typical object oriented paradigms of using shared references to objects breaks down in a massively parallel environment
* Sharing implies either single threaded
* Or synchronization
To utilize the hardware we need to move towards functional, declarative, reactive, and value semantic programming No raw loops


Slide 40 (page 25) adds to slide 29: "Without addressing vectorization, GPGPU, and scalable parallelismW standard C++ is just a scripting system to get to the other 99% of the machine through other languages and libraries. Do we need such a complex scripting system?"

The same question is valid for D. It seems important.

Bye,
bearophile

On 06/07/12 18:04, bearophile wrote:
> Page 46: #pragma no_alias Are we going to need something like that (or "restrict") in D too?

"restrict" functionality - yes, but it's probably better done the other way around - restrict as default and "alias" when necessary. Reusing the keyword could work too, if template parameters is the only thing that can clash.

artur

On Thursday, 7 June 2012 at 17:17:07 UTC, Artur Skawina wrote:
> On 06/07/12 18:04, bearophile wrote:
>> Page 46: #pragma no_alias Are we going to need something like that (or "restrict") in D too?
>
> "restrict" functionality - yes, but it's probably better done the other way around -
> restrict as default and "alias" when necessary. Reusing the keyword could work too,
> if template parameters is the only thing that can clash.
>
> artur

For this to work, the compiler would need to accurately imply aliasing with a 100% accuracy, to spit out errors. And if that was possible we would not need programmers hints at all. With restrict as a keyword, at least the programmer is aware of how "dangerous" that code is.

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

"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. 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.

Don't get me started on std.algorithm.find...


> 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.

On 06/07/12 20:19, Francois chabot wrote:
> On Thursday, 7 June 2012 at 17:17:07 UTC, Artur Skawina wrote:
>> On 06/07/12 18:04, bearophile wrote:
>>> Page 46: #pragma no_alias Are we going to need something like that (or "restrict") in D too?
>>
>> "restrict" functionality - yes, but it's probably better done the other way around - restrict as default and "alias" when necessary. Reusing the keyword could work too, if template parameters is the only thing that can clash.
> 
> For this to work, the compiler would need to accurately imply aliasing with a 100% accuracy, to spit out errors. And if that was possible we would not need programmers hints at all. With restrict as a keyword, at least the programmer is aware of how "dangerous" that code is.

Yes, it can't (always) be statically checked. But the alternative is restrict
proliferation; it applies not only to pointers, but also to slices. Hence defining
the language in a way that reduces the need for extra annotations would be best.
I'm not sure if that can be done safely for at least some subset of cases (function
arguments, mostly), that's why I said "probably" above. But it is something that
should be explored before blindly transplanting "restricted" to D.
While static compile-time checks aren't always possible, the rest could in theory
be handled by run-time checks in non-release mode. I'm not sure it would be enough.
A way to explicitly tag things as not aliasing anything else would also be handy;
'restricted' would work for that, maybe even 'uniq' could be overloaded and help.
This is eg for pointers extracted from some data structures, which are known to
not alias any others of the same kind present the current scope.

artur

On 06/07/2012 08:34 PM, Peter Alexander wrote:
>
> I find this very ugly. 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.

The mostNegative and common type stuff is there to enable correct semantics for taking the minimum of signed and unsigned values. Minimum of short and int would work fine without that.

> I'd much rather have a simpler standard library than a complicated one for the
> sake of a little convenience.
>

'min' is not complicated.

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

On 07.06.2012 20:04, bearophile wrote:
> The slide packs of the conference C++Now! 2012 are available:
> https://github.com/boostcon/cppnow_presentations_2012
>

Thanks, nice stuff for my brain to chew on.

For one thing the ustring caught my eye. It goes in the right direction ... for C++.

My first observations on the matter:

1) We all know COW strings are not good... because in C++ you have damned shared by default, folks!
That implies using atomic refcounting to be on the safe side, yet in D we have thread local by default, and ref-counting/COW is perfectly fine.
(for non-shared types).

2) Immutable strings have performance cost ... like tracking ownership and reference counting - unless you have GC by your side, in which case it's cheap and legal :)

3) Embeddable strings are not so hard to get in D, since there are char[...] arrays (that are even correctly value types!).

4) Small string optimization is kind of cool... for mutable strings mostly or as long as your GC sucks. (Small strings kind of prevent pooling, you know)

All that being said I could envision FlexString type in D, that does the following:
- easily integrates with string
- small string optimization (yay!)
- (maybe) allow any known encoding including legacy (and the list is extendable), convert on demand
- has plugable allocator (Andrei where was that nice design ? ;) )
- thus it could live on stack

Unlike c++ folks, we don't need:
- find and etc. to be members of string
- I personally against legacy encoding, let's stick with utf-8/utf-16
- customizable grow rates? (strange problem as I think preallocation is your beast friend where it may matter)

As far as small string goes I'd say a lot of containers would benefit of such packing, could be nice to generalize the concept.

The end of wish list:

Rope class would be cool, like... real cool. I guess std.container has to be package though :)


-- 
Dmitry Olshansky

 For some reason I found these docs really dull, to much rehashing of C++ 11 which is old hat now.

 The template stuff might be interesting if not for the knowledge that it will take absolutely forever to compile--

On Thursday, 7 June 2012 at 20:04:56 UTC, Timon Gehr wrote:
> On 06/07/2012 08:34 PM, Peter Alexander wrote:
>>
>> I find this very ugly. 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.
>
> The mostNegative and common type stuff is there to enable correct semantics for taking the minimum of signed and unsigned values. Minimum of short and int would work fine without that.

I know what it's there for, I don't think it is necessary. I don't think people should be taking the min of signed and unsigned values. I don't think it's worth cluttering the implementation for this minor convenience.


>> I'd much rather have a simpler standard library than a complicated one for the
>> sake of a little convenience.
>>
>
> 'min' is not complicated.

It's more complicated than it could/should be:

T min(T)(T x, T y) { return x < y ? x : y; }

To be honest, I don't think the variadic argument versions are necessary either as it is just duplicating the functionality of reduce.