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@lists.boost.org'" 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