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

Subject: Re: [boost] construe_cast, call for interest and feedback
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2010-10-08 07:37:29

> 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.

I'd like to see some measurements first as I'm not sure if cluttering the
API for the sake of premature optimization is a good idea. RVO/NRVO and move
semantics should do a very good job at making the proposed API efficient
enough for all intents and purposes.

Regards Hartmut
---------------
http://boost-spirit.com

> 
> 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
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost