[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