C++ Logo

SG20

Advanced search

Subject: Updated draft paper to fix the range-based for loop to make it teachable
From: Nicolai Josuttis (nico_at_[hidden])
Date: 2020-11-13 06:07:33


Hi guys,

attached is a new draft version with several updated due to your
feedback. For example:
- add a tony table
- remove "Heal C++:" in the title
- add Arthur is author
- discuss not to extend lifetime of the optional initializers
- fix the std::ranges example
- add a std::tuple example
- add std::as_const() example
- propose as first option that the new definition does
  not use references and "as-if" code at all
- fix he/she
- ...

Thanks you so much for all of your feedback.
We welcome further feedback, of course.

Best
  Nico

Am 13.11.2020 um 08:48 schrieb Nicolai Josuttis:
>
>
> Am 12.11.2020 um 02:17 schrieb Giuseppe D'Angelo:
>> Hi,
>>
>> On 10/11/2020 16:58, Nicolai Josuttis wrote:
>>> Feel free, to propose this attribute as an orthogonal paper.
>>
>> Thanks for the encouragement, this sounds like a major uptake and an
>> uphill battle though, and I'm kind of new at the game. :)
>>
> your're still welcome
>
>>
>>>> The other is minor and purely educational, and has to do with the (if
>>>> you want) "straightforward" definition of a range-based for loop in
>>>> terms of a "traditional" for loop. An argument that I sometimes use
>>>> towards using the new shiny toys from C++11 and beyond (range-based,
>>>> lambdas) is that they are truly zero cost abstractions; they are
>>>> *defined*  to be exactly like the good ol' C++98 for loops using
>>>> iterators, or function objects, just with convenient syntax.
>>>>
>>>> If we give special semantics to the range-based for loop (and only to
>>>> that) then this is no longer true, and one risks objections "this thing
>>>> has embedded hidden magic => the costs are not clear w.r.t. a non-ranged
>>>> loop => I am not going to use it".
>>>>
>>> In the area of compiler optimizations, a traditional for loop
>>> also no longer expands to what we think.
>>> It might for example suddenly introduce vectorization behind the scenes.
>>
>> I wasn't talking about what wonders compiler optimizations can do, I was
>> talking about the "mental model" of what a for loop is for someone
>> coming from C or from C++98. One of the arguments to buy in the "fancy
>> new toys" (ranged-for, lambdas) is that they're almost literally
>> expressed in terms of pre-existing, similar, well established
>> constructs. This generally resonates quite well.
>>
>> (I know and you know that for an optimizing compiler how things are
>> "specified" doesn't really matter that much. For people, it does matter.)
>>
>> On the other hand I have absolutely no idea (yet) how to "sell" the
>> mental model of "OK, this is a for, but it's actually specified as a
>> *function call* with a for inside!".
>>
>> Maybe it's just easier to discuss it in terms of an "algorithmic
>> function" like for_each, kind of a black box as you said before,
>> although the fact that it's a _language_ feature could make it hard to
>> approach it like this.
>>
> I agree,
> it is more like for_each(coll).
> The only question is how to deal with the other "argument" "auto elem" then.
> We pass the collection to iterate over and the declaration for each
> element inside the loop.
> Yes, that's OK to teach.
>
> Although, people might wonder why the element is a copy, then.
> Nevertheless, this is ONLY a performance issue, not undefined behavior.
>
>> Do you have some experience to share?
>>
>> --
>>
>> One more technical note. Do you think that with your change proposed,
>> one could also think of dropping the deleted rvalue reference overload
>> of std::as_const? (And possibly similar other functions.) As far as I
>> understand, with your proposed changes, something like
>>
>>> for (auto & elem : std::as_const(getVector())) { ~~~ }
>>
>> would now work. Is it worth including it?
>>
> THAT is an interesting example, thanks.
> In principle, you are right, but exactly to avoid problems like the one
> above as_const() is deleted for temporary objects:
>
>> template <class T> void as_const(const T&&) = delete;
>
> So, while this could work now, it still would not compile.
>
> Thanks a lot.
>
> Best
> Nico
>

-- 
Nicolai M. Josuttis
www.josuttis.de
+49 (0)531 / 129 88 86
+49 (0)700 / JOSUTTIS
Books:
 C++: http://cppstdlib.com, http://cppstd17.com,
      http://tmplbook.com, http://cppmove.com
 SOA: http://soa-in-practice.com



SG20 list run by sg20-owner@lists.isocpp.org

Older Archives on Google Groups