StephanTLavavej

What do you think of my slides? ("STL Features And Implementation Techniques") I try to make them readable by themselves.

The log graph is scarier: https://upload.wikimedia.org/wikipedia/commons/2/2d/Evolutio...

(It's easier to recognize a straight line on a log scale, than to distinguish an exponential line on a linear scale from a line that's "merely" quadratic, say.)

Die shrinks reduce power consumption. 45nm consumes more power than 28nm.

Both auto& and auto&& produce const T& for a const vector<T>, and T& for a modifiable vector<T>. The difference between them is subtle: auto&& handles Humanity's Eternal Nemesis, vector<bool>.

Traditionally, "ticks" are small, and "tocks" are big. See https://en.wikipedia.org/wiki/Intel_Tick-Tock .

> did it offer a `mutable` opt-in, though?

Nope.

> would intuitively expect it to be the POLS behavior.

If you give me (the implementation) a modifiable range, and I invisibly add constness before giving you back an element, that's surprising. C++ doesn't add constness by default anywhere (with the novel exception of lambda function call operators). If you give me a modifiable range, the least surprising thing to do is to give you a modifiable element, because that's what all of ptr[idx], * ptr, and * iter would do.

> how realistic (from the impl. POV) would be to have value-semantic range-based `for` with _mandated_ copy elision whenever possible?

If you say "for (auto elem : range) { elem = stuff; }" the write to the elem-copy will be dropped on the floor. Copy elision can't solve that.

> it doesn't say that `it` _itself_ has to be immutable (right?)

Correct.

> How do you think about InputIterators?

The concept is single-pass, read-only, but a given iterator may be stronger. for_each() is kind of special (it's the only algorithm that takes InputIterators, yet allows stronger iterators to be used with modifying functors), but other algorithms are vaguely similar. For example, transform(InIt first, InIt last, OutIt result, UnOp op) permits transform(first, last, first, op) for an in-place transformation - here, first/last's type clearly has to be InIt and OutIt simultaneously, i.e. a mutable FwdIt iterator or stronger.

I love const, but I am strongly opposed to adding constness here - as I mentioned, the non-Standard "for each" extension did that, and it caused endless confusion. Note that the lambda precedent is not actually applicable, because it affects only value captures. Reference captures can always be written through. The purpose of next-gen range-for is to operate in-place, i.e. with reference semantics.

for_each() does not add constness, and can modify elements in-place. The fact that it is grouped with the "non-modifying algorithms" is a confusing historical artifact (and was actually the subject of the first Library Issue I had a part in filing) - the algorithm itself does not modify things (unlike sort(), say) but the given functor can.

I talked about this some more in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n399... Q17. Many people have asked for such syntax, but I am wary of adding more complexity to the Core Language. Ultimately, I believe that this should be handled on the range side instead of the element side. What Evolution/Core needs to do is to fix the problem with nested temporaries in range-for loops - the problem (affecting both C++11's range-for and mine) is that range-for will keep temporary ranges alive if they're the topmost thing returned, but not if you have "const T& noop(const T&)" and you try to loop over noop(return_temporary_range()). They're aware of the problem, which is a start. If and when that's fixed, then what you want can be handled through library tech: "for (elem : as_const(range))".

It took me some time to recognize the problem with range-for (after testing its implementation in VC 2012), and more time to work up the courage to write a Core Language proposal. I also wish next-gen range-for had gotten into C++14, but that's mostly a formality - compilers can (and often do) ship features as soon as they're voted into the Working Paper.

Note that nothing's wrong with "const auto& elem", except that it prohibits modification. On the other hand, "const auto&& elem" will typically not compile (it'll insist on binding to rvalues, which only proxy iterators return).