Subject: Re: [boost] Boost.Convert+Boost.Parameter
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-03-04 02:50:41
> From: "Emil Dotchevski" <emildotchevski_at_[hidden]>
> 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
> 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
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
> "Bonus" implies that the generalization is desirable. :)
No, bonus means you get something for nothing (say, see
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 *)
says. If you want conversion to "char const*", you'll implement that
conversion yourself and then will use it as
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk