Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-04 11:22:50

> Message du 04/05/11 15:30
> De : "Stewart, Robert"
> A : "'boost_at_[hidden]'"
> Copie à :
> Objet : Re: [boost] [review] string convert
>
> Vicente BOTET wrote:
> > De : "Stewart, Robert"
> > > Vicente BOTET wrote:
> > > > De : "Stewart, Robert"
> >
> > > What your three options don't address, then, is indicating
> > > conversion failure, without an exception, for a type with
> > > neither a default constructor nor a usable sentinel value.
> > > That was the purpose of Vladimir's result type: it could be
> > > queried for success and for the value.
> >
> > Please, check the post around May 03, 2011; 10:09pm that
> > includes a file with the complete post without angle brackets
> > issues. There you will find all the cases.
>
> I thought you were proposing those three options as the solution. I now understand that you still meant for an error_code overload or a no_throw overload to be the means to determine whether conversion fails without relying on fallback values.
>
> The latter involves returning a pair which I dislike. boost::optional would be better as it supports safe-bool and a more meaningful get() for extracting the value (versus .second and .first for your pair).
>
> If there's truly value in using an error_code, that interface is good because it affords the ability to provide more specific diagnostics. Otherwise, I'd prefer the optional interface with nothrow or even a "try" variant to avoid the argument.

Yes, the try variant is the most appealing to me to mean no_throw.

> > > I haven't looked at the design of your library, but
> > > presumably these assignment operators are on a conversion
> > > type. Your conversion type's state is being set from
> > > another type in the various assignment operators, which is
> > > the normal sense of assignment, but your purpose of doing so
> > > is simply to provide the source value in order to extract it
> > > subsequently as the target type. That seems an abuse of
> > > assignment.
> >
> > If you have a class C1 you can define the following operator
> >
> > C1& operator=(C2 const& rhs);
> >
> > As I understand this, we are converting a C2 to a C1 via an
> > assignment.
>
> A constructor with such an argument is, certainly, a converting constructor. While I don't think of assignment in the same terms, it is not much of a stretch to consider it similar. Nevertheless, the assignments in your case are to a converter, not to the target type, which I still contend is abusing assignment.

The type traits extension operator doesn't make a name difference when the type is the same or different, it uses just has_assign can_call_assign, can_assign or whatever name.

> > The assign_to function is a way do it extrinsically, i.e.
> > outside any of the classes C1, C2.
> >
> > C1& assign_to(C1 & lhs, C2 const& rhs);
> >
>
> Your assignment operators are not on the target type, but on a converting proxy. Using assign_to() implies that the operation is lhs = rhs, but that's incorrect. The operation is, instead, lhs = f(rhs), where f() applies some transformation to rhs to produce lhs. Hence, "assign_to" is the wrong name.

Note that the default behavior of assign_to is lhs = rhs. Only the assign_to user overloading will make something different because in C++ we can not extrinsically the operator=. Think of the assign_to overloading as if the user were able to make the following free overloading

C1& operator=(C1&, C2 const&);

as is not correct in C++. But if it was possible, how would you call this operator.

Following your reasoning convert_to will not be a good name as in my library the default behavior it implies returning Target(rhs), that is calling the conversion operator/conversion constructor. But this is not the case when the user overload the convert_to function as the returned type should be assimilated to some transformation f of the rhs to get a Target. something like Target(f(rhs)).

Best,
Vicente