[cfe-dev] [PATCH] Libc++ Windows fixes

[Howard Hinnant]

On Sep 23, 2011, at 10:04 AM, David Chisnall wrote:

> On 23 Sep 2011, at 14:22, Ruben Van Boxem wrote:
> 
>>   - Redo newlocale to accept a third parameter. Functionality should be ok, as the third parameter is always 0 in libc++.
> 
> Don't expect this to remain the same in the future.  My brief profiling of libc++ showed that it's calling newlocale() far more than it should - 8 times to construct a single std::locale object.  I'd expect that it should be calling newlocale() once here, and maybe duplocale() a few times.  Calling newlocale() with a NULL third parameter is the most expensive of all of the locale-related functions that libc++ makes, so reducing this is something I plan on investigating.

Optimizations are certainly welcome.  Just a heads up though.  There's currently an optimization in there I'd like to keep.  The C locale, constructed implicitly as the original global locale, or obtained via locale::classic(), allocates no memory and doesn't call newlocale().

#include <locale>
#include <iostream>

std::size_t memory = 0;
std::size_t alloc = 0;

void* malloc(std::size_t) {return NULL;}
void free(void*) {}

void* operator new(std::size_t s) throw(std::bad_alloc)
{
    memory += s;
    ++alloc;
    return malloc(s);
}

void  operator delete(void* p) throw()
{
    --alloc;
    free(p);
}

void memuse()
{
    std::cout << "memory = " << memory << '\n';
    std::cout << "alloc = " << alloc << '\n';
}

int main()
{
    std::locale loc;
    loc = std::locale::classic();
    memuse();
}

memory = 0
alloc = 0

But I agree that the *named* locale facility could use optimization, even when the name is "C".  But this is a very tricky area.  Please post non-trivial code for review prior to committing.

Howard