From: "Emil Dotchevski" <emildotchevski@gmail.com> ... Generic algorithms shouldn't target containers as such, instead containers should be accessed in terms of iterators.
I believe generic containers do target containers. The standard algorithms are iterator-based. However, RangeEx and string_algo algorithms works with ranges which IMHO a considerable step foward compared to the standard iterator-based algorithms.
By the way, have you ever needed to convert a vector<char> to int?
The point is that "convert" works with boost::range-compatible containers that include vector<char>.
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.
I am of an pinion that we do that: int i = convert<int>::from(string); string s = convert<string>::from(i); As you can see "the source or the return are nailed down as a "string".
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?
If the user wants "char const*" suported, he will implement such a conversion as: char const* s = convert<char const*>::from(i);
One possible line of thought is to say oh well, we need to accommodate all of the above.
User-specific need will be accommodated on when-needed basis.
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.)
That's been my original request. You can see the relevant lexical_cast discussion and the decision to proceed with something like "convert".
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?
I honestly do not see such a need or any value in doing so.
A template like convert<std::string> or to_string<std::string> can't provide this limitation.
Yes, that was exactly the goal.
I'd prefer to_string specifically to discourage users from thinking about supporting non-string types,
The provided code does not provide any non-string conversions. If the user needs such he can do that himself. IMHO it should be their choice rather than yours.
... "Bonus" implies that the generalization is desirable. :)
No, bonus means you get something for nothing (say, see http://dictionary.reference.com/browse/bonus) 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 *)
That's what convert<string>::from(source) says. If you want conversion to "char const*", you'll implement that conversion yourself and then will use it as convert<char const*>::from(source) V.