http://llvm.org/bugs/show_bug.cgi?id=8992#c17
Can someone comment on the patch here? It would be nice if at least
Hello World worked on Linux.
Regards,
Petteri
http://llvm.org/bugs/show_bug.cgi?id=8992#c17
Can someone comment on the patch here? It would be nice if at least
Hello World worked on Linux.
Bugzilla does not appear to be fully functional at the moment. Putting my comment here:
Howard
(In reply to comment #17)
Created an attachment (id=6685) [details]
Updated patch tested to fix std::cout << "Hello World" << std::endl;(In reply to comment #16)
>
> I haven't done any further testing besides the fact that it compiles. Any
> comments before I proceed further?
>It seems supporting _DefaultRuneLocale is not needed to fix this bug now that I
tested my patch with a hello world example. testit of course still has a lot of
failures until everything is supported on Linux.
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__.
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.
I realize that this suggestion results in less elegant code. But our customers care much more about performance than code elegance.
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?
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__?
Regards,
Petteri
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