Re: [boost] [review] Convert library

Subject: Re: [boost] [review] Convert library
From: Jeroen Habraken (vexocide_at_[hidden])
Date: 2014-05-25 10:24:33

On 25 May 2014 14:03, Vladimir Batov <vb.mail.247_at_[hidden]> wrote:

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

You're more than welcome, you may have snipped a little too much but I'll
get to that below.

> 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? :-)

Unfortunately I believe we should, whilst we might be writing serious
software there are enough who aren't -- you'd be surprised how often people
are using boost::lexical_cast without the try - catch at the place I
currently work. Again, unfortunately.

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

Agreed.

> > 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!?

Wonderful, I'd love to see that make it into 1.56.0.

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

Close, I'd like an overload without the Converter const & as well,
defaulting to a converter chosen via a customisation point. This is what I
believe you've unintentionally snipped, and I'm curious as to your opinion
on it as I believe it to be a crucial part of the 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? :-)
>

We're getting there.

Jeroen