On Sat, Nov 12, 2011 at 2:56 AM, Theodore Papadopoulo <theodore.papadopo...@inria.fr> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/11/2011 08:59 AM, Joe Buck wrote: >> On Thu, Nov 10, 2011 at 10:04:34PM -0800, Gabriel Dos Reis wrote: >>> On Thu, Nov 10, 2011 at 10:12 AM, Jonathan Wakely >>> <jwakely....@gmail.com> wrote: >>> >>>> Adding this to GCC seems like a total waste of time, write a >>>> dwarf processor that dumps the info you want. >>>> >>> >>> Agreed. >>> >>> I suspect there is a misunderstanding of what 'auto' means in >>> C++. Furthermore, I think the step is completely backward. >> >> Yes, the reason I'm delighted with auto is that there are cases >> where I do not want to know the type (or I want to write generic >> code that will work with different kinds of containers). For >> >> std::multimap<Foo,Bar> amap; >> >> when I write >> >> auto ipair = amap.equal_range(key); for (auto iter = ipair.first; >> iter != ipair.second; ++iter) do_something_with(iter->first, >> iter->second); >> >> I explicitly do not want to know the details of the ridiculously >> hairy type of ipair. If you want to know, it is >> >> std::pair<std::multimap<Foo,Bar>::iterator,std::multimap<Foo,Bar>::iterator> >> >> and that's with the defaulted template parameters omitted. > > Sorry to jump in.... > But it is when you write > auto ipair = amap.equal_range(key); > that you may want to know that this type is a pair and that you can > write ipair.first and ipair.second. > > Of course equal_range is not the best example, but I can very well > imagine that with the generalization of auto use and with third party > libraries it might become very difficult/boring to track the actual > return type of a function (imagine a serie of functions all using auto > as return type)....
but then why did you use auto in the first place?
