[Development] RFC: more liberal 'auto' rules?
Marc Mutz
marc.mutz at kdab.com
Mon Dec 7 19:00:23 CET 2015
On Monday 07 December 2015 17:28:53 Thiago Macieira wrote:
> 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)
Yes.
> If so, I consider that an API defect in std::map or an implementation
> defect in std::string in the first place.
It is not an API defect, it is necessary to preserve class invariants
(maintain sort order).
> It wouldn't cause a magnitude of
> performance difference if they were implicitly shared, like QString.
No comment...
Thanks,
Marc
--
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
More information about the Development
mailing list