On Tue, Mar 3, 2009 at 1:58 AM, Vladimir Batov <batov@people.net.au> wrote:
From: "Emil Dotchevski" <emildotchevski@gmail.com> The point is, you're generalizing the interface without anybody having posted even a single use case that requires that generalization.
Yes, I've been playing along that generalization effort as I did not see it compromising the interface or muddling the intent. For me the clarity was the goal, the generalization was a bonus. I do not feel
int i = convert<int>::from(string)
has been generalized at the expense of clarity. Quite the opposite. To me above does exactly what it says... in the best possible (IMHO) way. I do not believe that something clearer like "from_string" will better reflect its purpose as the "string" is open for interpretation and the above converts from various string-like *containers* (like vector<char>, list<wchar_t>).
Generic algorithms shouldn't target containers as such, instead containers should be accessed in terms of iterators. By the way, have you ever needed to convert a vector<char> to int?
Same goes for 'to_string' as I need to convert to char and wchar_t-based strings and most likely need to convert to u8char strings. Therefore, I do not feel
to_string<wstring>(-1)
looks/reads better than
convert<wstring>::from(-1)
If you think about the standard library stream operators, they nail down one of the arguments as a stream. In string conversions, ideally we should nail down the source or the return as a "string" because otherwise the interface is too generic. The problem is that there is no single string type in C++. If we have a function that converts to string, should it return std::string, std::wstring, char const *, wchar_t const *? Should it support user-defined string types? One possible line of thought is to say oh well, we need to accommodate all of the above. That leads to lexical_cast-style interface (I suspect that the proposed convert<> interface can in fact be implemented as an extension of lexical_cast.) I'd rather limit the interface to std::string/std::wstring and types that can be implicitly converted to string/wstring. So the question is how to provide this limitation? A template like convert<std::string> or to_string<std::string> can't provide this limitation. If I must pick between convert template and to_string template, I'd prefer to_string specifically to discourage users from thinking about supporting non-string types, but as you pointed out, semantically convert<> and to_string<> are the same. For me, they both have two issues: 1) convert<std::string>(x) disables ADL (I think it's important for users to be able to inject overloads.) 2) convert<std::string> necessarily returns std::string (I think it's important user-defined conversions to have the freedom to return char const *. Many interfaces that take strings are commonly overloaded for std::string and char const * for efficiency reasons.)
Such generalization is not needed by anyone, or if it is needed we have no idea if that use case will fit this interface. So why is it supported? Just in case? We have lexical_cast for that. :)
Yes, I indeed have that feeling that the generalization option will never be exercised. However, to me the generalization has been accidental, a bonus.
"Bonus" implies that the generalization is desirable. :)
The main goal of the exercise (for me) has been clearing up the interface to say what it does.
convert<Target>(source) says "convert any source I pass in to an object of static type Target." For what it's worth, I want the to-string interface to say "convert any source I pass in to string" where string could be std::string/char const * (or std::wstring/wchar_t const *) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode