Message du 07/05/11 07:49 De : "Vladimir Batov" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [review] string convert
From: "Stewart, Robert" ...
int i = boost::convert::to(str);
That's good.
How about we simplify the API down to just:
T convert::to(S, boost::parameter-list);
As Robert said, the name of a free function must be readable when introducing a using namespace. Or is convert a class?
Then we specialize it for convert::result type so that
convert::result convert::to>(S, boost::parameter-list);
I don't see any inconvenient in introducing a special overload. I guess a user needs to call it as follows convert::result r = convert::to>(S, boost::parameter-list);
In fact, if there is a lot of resistance to incorporate that into the lib., I can simply implement that locally. The "bool convert::try_to<>(S, T&)" API is for those who prefer that style. Then, a most-functionality-covering example might look like
// The predictable. Throws on failure int i = convert::to("FF", (format_ = std::hex))
Would this overload exist only when the source parameter is string? Sorry, but I don't see how it could be used for type-to-type conversions int i = convert::to(aValue, (format_ = std::hex)) Would the std::hex be applied to the output or the input stream? ios << aValue; ios >> std::hex >> i; or ios << std::hex << aValue; ios >> i; Are these equivalent? I think the interface must state clearly when these manipulators are applied.
There is no converter exposure. The expected Target type is returned. No implicit conversions whatsoever. When I need convert::result, I'll ask for it explicitly. Seems like that might turn nay-sayers (or no-voters) to happy customers. 'convert' would be fairly easy to re-shape like that. Or Vicente might beef-up his library and get all the fame (oooh, jealous).
Vladimir, as I said you my library doesn't pretend to take care of string conversions or conversions via a stream. My library will specialize the convert_to function when one of the parameters is a string and call the best library providing it. The current code is calling your library. Other candidates are possible depending on which libraries will be there, lexical_cast, yours, construe (using Spirit parser). I'm just suggesting some alternative design to your interface, that would cover the same functionality in a less bloated way. Up to you to take whatever is better for you. While the fallback feature can be associated to a conversion constructor with a fallback parameter, it can not be associated to a conversion operator, as it doesn't allows additional parameters. The same applies to the no throw feature. While the language allows to state at compile time that a constructor or a conversion operator will not throw, there is no constructor or conversion operator that can signal at run-time (without a throw exception) if the conversion succeeded or not. I don't know yet if I will introduce the fallback and the no throw features in my library as the default behavior intends to use the throw conversions and protect it with a try-catch clause. If I or someone else find a default behavior for these features that doesn't use a try-catch block then I will surely introduce them. Anyway, if Boost.Conversion introduce other functions, they should also be customizable as convert_to and assign_to are now. The string specific conversion library (as the yours was at the beginning) could have a more different design and define the throwing functions using the no throwing ones. Resuming. My Boost.Conversion needs a string conversion that more efficient than lexical_cast, but I could use lexical_cast if there is no better choice. If your library reach to manage type-to-type conversion in general, then Boost.Conversion will be a no sense and I will withdraw it with no problem. Good luck with your library, I need it (at least for the string part :) Best, Vicente