Re: [boost] Boost.Convert+Boost.Parameter

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 
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.