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<int> and a function that takes (int) it does the correct thing - it passes the int values directly to the function.
On Mon, Oct 29, 2018 at 11:57 AM Walt Karas <wka...@oath.com.invalid> 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 optimized out). > On Fri, Oct 26, 2018 at 5:32 PM Pushkar Pradhan <pprad...@oath.com> wrote: > > > > 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 <wka...@oath.com.invalid> > wrote: > >> > >> This line of code: > >> > https://github.com/apache/trafficserver/blob/master/iocore/net/SSLSNIConfig.cc#L59 > >> > >> should be: > >> for (const auto &item : Y_sni.items) { > >> > >> This causes item to be of type const Item & instead of Item. Thus > >> avoiding making a copy of each element in the vector. Look at this > >> example code: > >> > >> https://godbolt.org/z/7j0LFT > >> > >> Note in the assembler code how foo() calls the copy constructor for > >> Item in the for loop, and foo2() does not. > > > > > > > > -- > > pushkar > -- *Beware the fisherman who's casting out his line in to a dried up riverbed.* *Oh don't try to tell him 'cause he won't believe. Throw some bread to the ducks instead.* *It's easier that way. *- Genesis : Duke : VI 25-28
