Re: [boost] [review] string convert

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

> Message du 03/05/11 22:21
> De : "Stewart, Robert" 
> A : "'boost_at_[hidden]'" 
> Copie à : 
> Objet : Re: [boost] [review] string convert
> 
> Vicente BOTET wrote:
> > De : "Stewart, Robert"
> > > Vicente BOTET wrote:
> > >
> > > > 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(); }
> > > > };
> > > >
> > > > 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.
> 
> Consider conversion to int, where all values are allowed:
> 
> int const fallback(/* what to use here? */);
> int const t(convert_to("some string", fallback));
> if (t == fallback)
> {
> // is this because the conversion failed or because
> // of the second parameter?
> }

Note that in this case, if conversion fails an exception is thrown.
> --------------
> int value;
> assign_to(value, "some string");
> if (value == ???) // how test for failure?

The same here.
> --------------
> Cannot specialize default_value because there is no suitable default value. Zero is not appropriate because it is within range.
> 
> In each case, because there is no special, sentinel value that is out of range, there is no way to detect conversion failure.

default_value is not used to detect conversion failure, but to initialize a non default constructor type.

> > > > 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.
> 
> I'm not arguing why you have the function, I'm just telling you that I don't find the name to be good.

Would you have a better name?

> I also don't thing assignment for conversions is appropriate.

Well, this is part of the language, I'm quite sure the C++ standard and Boost uses this kind of assignations. As a generic function emulating extrinsic assignation you should I must follows the standard mechanism conventions. It is up to the user to overload or not this function which by default relies on the operator=.

> > > > 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.
> 
> Hmmm. Those codes aren't extensible. Do they really describe the sorts of errors likely to occur during such conversions? If the codes don't cover everything, then they won't work. You'd need a different list, though a similar design would work.

error_code is extensible because error_category is. You just need to define a specific category and use it to instantiate your error codes, isn't it?

Best,
Vicente