Message du 04/05/11 15:30 De : "Stewart, Robert" A : "'boost@lists.boost.org'" 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