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