[Mesa-dev] [PATCH 02/21] glsl: protect locale_t with a mutex

[Petri Latvala]

On 05/06/2014 01:04 AM, Kenneth Graunke wrote:
> On 05/05/2014 10:01 AM, Ian Romanick wrote:
>>
>> The problem I see with that is we don't know what order constructors on
>> global objects will occur.  Are we sure the contructor will be invoked
>> before we need the locale now and in the future?
> These functions are used during lexing to read floating point
> literals...without breaking on locales where the decimal point is a comma.
>
> All constructors have definitely been run by that point, and I can't
> imagine we'll ever need to call locale-independent strtof/strtod from
> other constructors.
>


The order of constructors in a single TU is well defined. The usual 
pattern for this kind of initialization is to have the initializer 
object in the header as static:


In strtod.h:

struct loc_initializer
{
   _Initializer()
   {
     if (!loc) {
       loc = initialize_it();
     }
    }
};

static loc_initializer loc_init;


Any global object constructor that might use loc will have to #include 
strtod.h, therefore loc_init will appear first in that TU, and will 
initialize first.

A real-world example would be std::_Init that initializes std::cout and 
its pals.


-- 
Petri Latvala