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 <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
