[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
- [lmi] Request for review, Greg Chicares, 2017/01/11
- Re: [lmi] Request for review, Vadim Zeitlin, 2017/01/11
- Re: [lmi] Request for review, Greg Chicares, 2017/01/11
- Re: [lmi] Request for review, Vadim Zeitlin, 2017/01/11
- Re: [lmi] Request for review, Greg Chicares, 2017/01/12
- Re: [lmi] Request for review, Greg Chicares, 2017/01/12
- Re: [lmi] Request for review, Greg Chicares, 2017/01/12
- Re: [lmi] Request for review, Vadim Zeitlin, 2017/01/12
- Re: [lmi] Request for review, Greg Chicares, 2017/01/12
- Re: [lmi] Request for review,
Vadim Zeitlin <=
- Re: [lmi] Request for review, Greg Chicares, 2017/01/12
- Re: [lmi] Request for review, Vadim Zeitlin, 2017/01/13