Re: [boost] construe_cast, call for interest and feedback

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

construe_cast(lhs, rhs);

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. 

Regards,

Matt
------

On 08/10/2010, at 4:38, Jeroen Habraken <vexocide_at_[hidden]> wrote:

> Hi,
> 
> 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
> flexibility.
> 
> 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.
> 
> Regards,
> 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