Subject: Re: [boost] construe_cast, call for interest and feedback
From: Matthew Herrmann (matthew.herrmann_at_[hidden])
Date: 2010-10-07 16:59:43
It would be nice to have
so that there is no temporary copy for things like std::string on the lhs and type inferencing can be used to avoid writing the type name.
Also are you adding array of char as an input specialization? I like the way it avoids the strlen for const char literals on the rhs.
On 08/10/2010, at 4:38, Jeroen Habraken <vexocide_at_[hidden]> wrote:
> I'm proud to say I've tagged a version 0.2 of construe_cast some
> minutes ago. For those unfamiliar with the library (it's the first
> time I'm posting this to the boost mailinglist), it's 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
> The current code can be found at
> http://github.com/VeXocide/construe_cast and should be compatible with
> boost version 1.42.0 and up.
> What can it do, in short, boost::construe_cast<int>("23") and
> boost::construe_cast<std::string>(23); (and a lot of other types,
> basically the ones boost.spirit supports). 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.
> What I'm hoping to add the coming weeks:
> - Documentation, I'm somewhat ashamed to say this hasn't been written
> yet, however, this will be tackled shortly.
> - Support for different encodings, it currently uses standard (ASCII)
> and standard_wide for wchar_t, with more to follow.
> - A nothow version, like lexical_cast it currently throws when it
> encounters a run-time, an interface returning false or a default value
> will be included (the exact interface hasn't been decided upon yet).
> Performance, now this is where it gets hard. I've done some basic
> benchmarking and it's somewhere between one and five times as fast as
> lexical_cast, depending on what you're casting. Good compilers (I've
> notices this with gcc 4.4 and up for example) are actually capable of
> optimizing boost::construe_cast<int>("23") to the integer 23 at
> compile-time which makes it tricky to benchmark. If anyone with more
> benchmarking experience is willing to look into this, please do.
> Again, thanks to everyone who helped me get this far, and Hartmut in
> particular. There seems to be little to add at the moment, I'm looking
> forward to your opinions and insights.
> Jeroen Habraken
> P.S. I've had a few responses about the name, construe is an english
> word (http://www.thefreedictionary.com/construe) and I'm using
> construe_cast as a working name. If people are ever going to consider
> this for inclusion with boost, changing the name will surely be the
> least of my worries.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk