Subject: Re: [boost] construe_cast, call for interest and feedback
From: Jeroen Habraken (vexocide_at_[hidden])
Date: 2010-10-08 08:56:20
On 8 October 2010 14:18, Krzysztof Czainski <1czajnik_at_[hidden]> wrote:
>> Secondly, since this
>> release, boost::construe_cast<std::string, tag::bin>(23) resulting in
>> a std::string("10111") and visa versa. The user has the ability to add
>> functionality here by implementing extra tags, by default tag::bin,
>> tag::oct and tag::hex are implemented, with more to follow.
> I use boost::lexical_cast for conversions from string. For conversions to
> string I rarely use boost::lexical_cast. Most of the time I need formated
> conversions, and I use boost::format:
> lexical_cast<int>( "12" )
> lexical_cast<string>( 12 )
> str( format("0x%04x") % 12 )
> When I need control over output format, I usually need more then just
> tag::hex, etc., and I like the printf/boost::format syntax for it. The
> alternative I dislike:
> ( ostringstream() << "0x" << hex << setw(4) << setfill('0') << 12 ).str()
> Once I experienced having to fall back from boost::format to sprintf for
> efficiency reasons.
> 1. For conversions from string I consider lexical_cast<T>( string )
> sufficient, but I can imagine efficiency can be improved - if mesurements
> say so.
> 2. For unformated conversions to string: same as point 1.
I agree, that's the scope of this library. The tags are there as an
extensibility point, and over time some common and convenient tags
will be added, imagine a tag::no_case when you want to accept "True"
or "TRUE" besides "true" for example.
> 3. For formated conversions to string: a more efficient boost::format would
> be something I would like to see (just a user's point of view, I have no
> idea how this could be implemented).
There already is a library in boost capable of this, boost.spirit's
Karma, which construe_cast is partly build upon. It's not as trivial
to use as boost.format but considerable faster, and I can highly
recommend it. Please see
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk