[Development] RFC: more liberal 'auto' rules?

[Thiago Macieira]

On Monday 07 December 2015 17:42:50 Marc Mutz wrote:
> > >  std::map<std::string, std::string> stdMap = ...;
> > >  
> > >  for (const std::pair<std::string, std::string> &e : stdMap)
> > >  
> > >      doSomething(e.first, e.second);
> > >  
> > >  for (const auto &e : stdMap)
> > >  
> > >      doSomething(e.first, e.second);
> > >
> > >The second loop is at least two orders of magnitude faster (doSomething()
> > >is an out-of-line no-op).
> > 
> > I think the summary here is that auto gives you one guarantee: It won’t do
> > an implicit conversion for the initial assignment.
> 
> Correct. The first line is missing the const in the pair's first type, thus
> forces an implicit conversion to the declared type (the const-& conveniently
> extending the lifetime of the temporary so everything appears to work,
> execept you're deep-copying two std::strings now).

What const is missing? Are you saying it should have been

	for (const std::pair<const std::string, std::string> &e: stdMap)

If so, I consider that an API defect in std::map or an implementation defect 
in std::string in the first place. It wouldn't cause a magnitude of performance 
difference if they were implicitly shared, like QString.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center