Re: [boost] [GSoC] coerce (previously construe_cast)

Subject: Re: [boost] [GSoC] coerce (previously construe_cast)
From: Matthew Chambers (matt.chambers42_at_[hidden])
Date: 2011-04-04 14:46:13

On 4/4/2011 6:11 AM, Jeroen Habraken wrote:
> Hi,
>
> Some time ago I've announced construe_cast as a library which builds
> upon boost.spirit to create a cast-like operator aiming to provide an
> alternative to lexical_cast providing greater speed and flexibility.
> It has since been renamed to boost.coerce (it's the last rename, I
> promise) and it has found its way to the boost sandbox where
> development will continue. For the original email I'd like to point
> you to http://boost.2283326.n4.nabble.com/construe-cast-call-for-interest-and-feedback-td2967275.html.

On 09/10/2010 13:50, Mathias Gaunard wrote:
>> On 09/10/2010 13:42, PB wrote:
>>
>>> Rather than introducing another casting method, could lexical_cast be
>>> reworked internally to build upon Spirit? That way previous
>>> investments in lexical_cast will just work faster with no changes,
>>> Also, I won't need to stop and think which one I should be using.
>>
>> The problem is that lexical_cast is a bit different since it takes into
>> account C++ locales.
>
> I think the important question is the following:
>
> Do we care about C++ locales support in lexical_cast?
> Are people fine scrapping lexical_cast and have construe_cast take its name?

I like the idea of being able to use Spirit for lexical_cast despite the compile-time hit. Ideally, 
I'd like to be able to enable it with a preprocessor option rather than replacing lexical_cast 
outright or refactoring to use a different API.

The preprocessor option could choose between the pure streams lexical_cast, lexical_cast with C 
runtime optimizations (good runtime performance, no compile-time hit), and lexical_cast with Spirit 
optimization (best runtime performance, but surely this would be a nasty compile-time hit when using 
lexical_cast across tens/hundreds of TUs!?)

I for one don't much care about the locale support in lexical_cast. But since others probably do, 
would it be possible to use the optimized calls only when the locale is set to the default (with 
trivial runtime overhead)? The same check would apply to lexical_cast optimizations using the C 
runtime strtol/strtod as well.

Thanks,
-Matt