lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Request for review


From: Vadim Zeitlin
Subject: Re: [lmi] Request for review
Date: Thu, 12 Jan 2017 23:50:43 +0100

On Thu, 12 Jan 2017 18:36:01 +0000 Greg Chicares <address@hidden> wrote:

GC> Let me ask one last question before I start working on this patch. STL's
GC> proposal above has two distinct components:
GC> 
GC>  - always use the same for-range-declaration (regardless of constness);
GC> 
GC>  - always write that One True for-range declaration with two ampersands.
GC> 
GC> Are you saying "one ampersand good, two ampersands bad" for our general
GC> rule--that it's the '&&' specifically that makes it harder to resolve?

 My main problem with "auto&&" is that it loses "const" and so doesn't
indicate the intention of the code to not modify *or* modify the container.
Both are important and without one we can't have the other.

 Additionally, seeing "auto&&" in non-template code makes me stop and
wonder: why is it used here? As the only case in which it needs to be used
is when the iterator dereferences to a proxy object instead of directly to
the object itself (the representative example being iterating over the
notorious std::vector<bool>), I think it will be puzzling to see it used
when iterating over std::vector<double> or std::string and even more so
when iterating over fs::directory_iterator where things are less obvious
(but "auto&&" is still not needed).

GC> (I can't claim to understand it well yet, but I had the impression that it
GC> would give us more efficient "move" semantics, at least in some cases;

 No, not at all, there is no moving involved here anyhow (nor copying). In
the case of "normal" iterators both "auto&" and "auto&&" are equally
efficient and both are just references (so no copying/moving) and in the
case of iterators returning proxies (std::vector<bool> case), "auto&"
simply won't compile.

GC> If so, then it's agreed: we'll simply use Rule 2:

 I'm not sure to follow the exact logic leading to it, but I definitely
agree with the conclusion.

 Please let me know if I'm missing something here (I have the impression I
do, but really no idea what...),
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]