[cfe-dev] [libc++][patch] Improving Linux support

Howard Hinnant hhinnant at apple.com
Mon Jun 13 11:02:40 PDT 2011


On Jun 13, 2011, at 1:56 PM, Petteri Räty wrote:

> On 13.6.2011 18.12, Howard Hinnant wrote:
>> 
>> Sorry for the delay in reviewing this.
>> 
>> Comments:
>> 
>> I'm not comfortable with moving the __APPLE__ code away from the *_l
>> functions.  I appreciate that the functionality has been replicated
>> within the with_locale function.  But I am nervous about the
>> performance implications of reinventing the *_l for __APPLE__.
>> 
> 
> Do you have numbers on how much the difference is or what the
> implications could be?

No.  But even if I did, and the numbers showed absolutely no difference, I would still be nervous.  The OS has the potential to optimize the *_l functions better than you can do with with_locale, even if the current OS has not done so.

> 
>> 
>> On the positive side, you've achieved good code reuse with
>> with_locale.  Perhaps it would be good to reinvent the *_l functions
>> using with_locale *only* for those platforms which don't already have
>> *_l and do have the per-thread uselocale.
>> 
> 
> As the documented build script is just a simple shell script what
> approach do you suggest for the detection? Just assume only POSIX and
> only activate *_l if explicitly requested with for example __APPLE__?

A first cut would just be to say that __APPLE__ has it and no one else does.  Perhaps a better approach would be to create some _LIBCPP_ macros that indicate presence of the *_l and of uselocale and set/unset those in <__config> based on things like __APPLE__ and whatever you have available on linux.

Howard





More information about the cfe-dev mailing list