Yes and no. I think Alan is correct in the sense that if you use for
(auto &&r : , and it compiles OK, the object code is going to be
correct and optimal. I just have my aesthetic opinion that it can
make the code slightly harder to maintain.
On Mon, Oct 29, 2018 at 6:47 PM Pushkar Pradhan
wrote
It seems like auto isn't that "auto". You still need to be familiar with
all the gotchas.
On Mon, Oct 29, 2018 at 11:48 AM Alan Carroll
wrote:
> I tend to use `for ( auto && x : container)`. That seems to work well and
> gives the compiler more flexibility. I recommend it unless there's a
> spe
I'm not convinced: https://godbolt.org/z/M8pZl0
On Mon, Oct 29, 2018 at 1:48 PM Alan Carroll
wrote:
>
> I tend to use `for ( auto && x : container)`. That seems to work well and
> gives the compiler more flexibility. I recommend it unless there's a
> specific reason to not do so. Testing with a
I tend to use `for ( auto && x : container)`. That seems to work well and
gives the compiler more flexibility. I recommend it unless there's a
specific reason to not do so. Testing with a std::vector and a
function that takes (int) it does the correct thing - it passes the int
values directly to th
Good catch. In Modern Effective C++ Scott Myers talks about a few scenarios
when auto doesn't do what the programmer intended.
Earlier I was inclined to suggest that we should avoid auto in ATS but I
think it's better to make mistakes and learn.
On Fri, Oct 26, 2018 at 3:21 PM Walt Karas wrote:
https://github.com/apache/trafficserver/blob/master/proxy/logging/LogObject.cc#L1008
We also have cases of the opposite problem, using a reference for a
container of pointers / iterators / string_views or other small
objects. But this is less serious and probably just an aesthetic
issue (gets opt
