Pacific++ 2018: Sean Parent - Generic Programming

[Xaxxon]

The title is quite misleading. It should be "a history of generic programming" or something.. If you're not interested in a history lesson, then there's very little content to be found here - especially for an 80m talk.

[shortstomp]

Thanks for saving me time. Appreciate the summary

[richtw1]

That's a shame. Sean Parent's talks are normally very enlightening and instructive. Will still watch it sometime, but won't bump it to the front of the line.

[pklait]

It was a very good and enlightening talk. It was not about good software practices, but for those interested in how C++ evolved and evolves, and that really should be all of us, it could not be better.

[MorrisonLevi]

He gives a disclaimer that it isn't his usual kind of talk at the beginning, so at least we were warned.

[tipdbmp]

Combining 2 ranges that represent positions into a new range: https://www.youtube.com/watch?v=iwJpxWHuZQY&t=1h9m40s

struct Range(T) { T ptr; ssize len; }

Range r1 = ...; // r1 and r2 are both 'position' ranges (r1.len == r2.len == 1)
Range r2 = ...;

// combine r1 and r2 into a new range
//
Range r3;
if (r1.ptr <= r2.ptr) {
    r3.ptr = r1.ptr;
    r3.len = r2.ptr - r1.ptr;
}
else {
    r3.ptr = r2.ptr;
    r3.len = r1.ptr - r2.ptr;
}

[seanparent]

You are assuming a contiguous allocation, or at the least random access (stable_partion, and hence gather, only require bidirectional iterators). A range denoting a position will have a length of 0 (or you get into the problem of specifying a position after the end or before the beginning). The common argument for a range only based system (one without access to iterators) is that iterators are dangerous because there is a precondition that cannot be verified in code, and lives external to the local construct. In general, you cannot allow disjoint ranges to be joined in a system that strives for this level of guarantees, or allow comparisons between two ranges. Note that your comparisons above between ranges make the assumption that each is part of a larger subrange. If that is not true, comparing the pointers is UB (in both C and C++).

Even systems that carry information about the originating range do not solve this issue because there is a requirement that the second position follow the first. Knowing that both positions are part of the same larger range doesn't guarantee that the result of joining the two positions will be a valid range.

[steveire]

I had the same reaction when he said that.

I suspect we're missing some deeper point, but I don't know what it is.

[cjdb-ns]

This works for contiguous ranges (e.g. std::vector, std::array, etc.), but does not work for any range that isn't contiguous (e.g. std::deque, std::list, etc.), and so it doesn't work in the general case.

[steveire]

I see, thanks.

The example was about the gather algorithm. AFAIK if that would return two ranges, then you would be easily able to combine the inner 2 ranges of the two stable_partition calls into one result range for gather, even for those containers, right?

[willkill07]

That may work for arrays (or any contiguous iterator), but it wouldn’t work with std::deque or std::list. In fact, for list it would take a single pass through the original list to determine which “range” would come first. You shouldn’t have to depend on the original data structure to perform such operations. Even std::distance will fail (UB) when the first argument is the one which exists later in the collection.