Re: [boost] [review] Convert library

Subject: Re: [boost] [review] Convert library
From: Vladimir Batov (vb.mail.247_at_[hidden])
Date: 2014-05-25 08:03:19

Jeroen, Thank you for your input. My apologies for snipping (a lot) -- I want
to focus on the immediate. If we clear this one up, we'll get to the rest
next. If we do not clear this one up, we won't get to the rest. :-)

Jeroen Habraken wrote
> ...
> 
> as other have argued boost::lexical_cast is used
> without the try-catch in a lot of places. Simply expecting it not to throw
> and dropping everything on the ground when it does isn't the nicest way to
> go about things but it does get things done. 

Jeroen, seriously, we are serious people writing serious s/w. Should we be
discussing children playing with matches here? :-)

> I guess the question is whether we should make it harder to use the
> library
> in such a way, and I think we shouldn't. 

It is the wrong angle IMO. First, we should make it work properly. Then we
make it as simple to use as possible within the constraints imposed by the
first point.

> Note that for this to be efficient I'd like to see the optional to be
> movable, which isn't yet the case with boost::optional if I'm not
> mistaken.

You might have noticed that I mention std::tr2::optional... which has what
you are after. Andrzej is working on incorporating/backporting those
features to boost::optional. "Life happened" to him also :-) but I am
hoping, if we are extra nice, he might just might to get the interface we
are after into 1.56. Andrzej, ple-e-e-ease, pretty pretty please!? 

> I'm slowly warming up to the optional-based interface as it eliminates the
> throwing / non-throwing interface discussion, which is a good thing. Once
> again two comments, first of which is what's going to happen until the
> std::optional (whether in TR2 or elsewhere) is widely accepted. The
> optional provided by boost has a slightly different interface and isn't
> movable.

It is

std::tr2::optional<TypeOut> convert(TypeIn const&, Converter const&);

you are warming up to, right? If it is so, I am really glad to hear that. I
am not married to it but all things considered it seems the most generic and
flexible, functionally-complete, not too verbose... and sufficiently close
to lexical_cast :-) for people not to feel alienated. 

Given the immense variability of conversion-related deployments I see this
interface as the only one that everyone can deploy -- exceptions? no
problem; delayed exceptions? easy; no exceptions but failure-condition
returned instead? piece of cake; can't be bothered processing the
failure-condition and wanna proceed with the default? coming right up; want
to process failure but still go with the default? anything to keep the user
happy!

So far, no one (to my knowledge) has come up with another interface which
simpler without sacrificing those mentioned important qualities (given we
are talking about a library-grade interface).

> The second is performance, with boost::coerce a lot of time was invested
> to
> prevent the interface from slowing down the conversion itself. I simply
> don't know how this interface will behave in that regard, when I have more
> time I'll try some benchmarking.

Ah, that should not be a problem. I don't think. I actually expect the
convert() interface to be wiped out altogether when optimized. That is, all
power to you, the converter writer. So, what do you say? Are we in
business?.. So to speak? :-)

--
View this message in context: http://boost.2283326.n4.nabble.com/review-Convert-library-tp4662821p4662835.html
Sent from the Boost - Dev mailing list archive at Nabble.com.