Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-03 15:58:29

Sorry, but I think I have yet a problem with less and greater symbols <>, and some important parts are missing. I will use (* and *) instead if needed. 
I will resent the preceding post in an attached file :(

> Message du 03/05/11 20:27
> De : "Stewart, Robert" 
> A : "'boost_at_[hidden]'" 
> Copie à : 
> Objet : Re: [boost] [review] string convert
> 
> Vicente BOTET wrote:
> 
> Vicente, you really need to try a different mail client or else use it differently. The angle brackets for your template parameter and argument lists are being dropped.
> 
> > In order to take care of types without default constructor I
> > see several options:
> >
> > template
> > Target convert_to(Source const& s, Target const& t);
> >
> > template
> > Target& assign_to(Target& t, Source const& s);
> >
> > template
> > struct default_value
> > {
> > T apply() { return T(); }
> > };
> >
> > The user will need to specialize this function for types that
> > are not default constructible.
> >
> > This meta-function will be used instead of declaring a
> > defaulted variable in the string conversion function.
> >
> > T v(default_value::apply());
> 
> None of those options work for types without a default constructor *and* without a sentinel value.

Why? For me the 3 options work.

> > As a user I would prefer the second one
> 
> The name "assign_to" just seems odd to me. The problem is that assigning "123" to an int is the wrong idea. It isn't assignment but conversion. I understand you wanted a different name to account for the different behavior, but that's not it.

assign_to is the functional for of operator= (assign). This operator can accept any type on its lhs, making a conversion. I think the name assign_to respect this schema. 

> > In order to take care of no throwing semantics, I will choose
> > to add a convert_to overloading with a error code parameter,
> > not throwing without not knowing why fails seems too specific
> > to me.
> >
> > template
> > Target convert_to(Source const& s, err_code& ec);
> 
> That's fine if there are specific errors to report other than "bad input." The err_code type should also support a safe-bool conversion.

I was thinking on the error code of the C++ standard.

> > But I could understand there are some cases where the single
> > reason is a bad format. We could also use the no_throw_t as
> > additional parameter, but in this case the return type should
> > allow to know if the operation has succeed or not. If we follow
> > the C++ standard interface the use of pair seems to be the more
> > appropriated.
> >
> > template
> > pair convert_to(Source const& s, no_thow_t const&);
> 
> This was already rejected by several folks. Allow me to add my dislike for it.

Maybe be some rejected it, but not all.

> > Note also that there could be some conversions that could
> > transport whether the conversion succeeds or not
> 
> I can't quite parse that.

Sorry for my bad English. I meant the optional can store the converted value and if the conversion failed.

> > optional t = convert_to >(s);
> 
> Something important was lost in your message.

Yes. See my initial comment.

> > or a Robert suggested overload the pointer to a source
> >
> > template
> > optional convert_to(Source const* s);
> 
> Unfortunately, I realized that wouldn't work well for string literals, for example.

I like the try_convert_to also.

Best,
Vicente