From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21305 invoked by alias); 20 Apr 2014 08:33:55 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 21272 invoked by uid 48); 20 Apr 2014 08:33:51 -0000 From: "antoshkka at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/59439] std::locale uses atomic instructions on construction Date: Sun, 20 Apr 2014 08:33:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.8.3 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: antoshkka at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-04/txt/msg01379.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439 Antony Polukhin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |antoshkka at gmail dot com --- Comment #7 from Antony Polukhin --- (In reply to Jonathan Wakely from comment #5) > There's a good reason boost::lexical_cast is special-cased for the common > int-to-string conversions that don't need fancy formatting. I'm the current maintainer of boost::lexical_cast and I'd like to add my 2 cetns. Construction of std::locale is a common case all around the Boost libraries. Here are some of the cases when std::locale is constructed: * in almost any conversion with boost::lexical_cast * in all the string related algorithms in Boost.Algorithm (like compare(), erase(), find() and others) * in methods of Boost.Locale like to_upper, to_lower, normalize and others... * in parsers of Boost.PropertyTree In most cases I've seen only the global 'C' locale is used in user code, so optimizing it's construction/descruction/copying will have a good impact on code performance.