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

Subject: Re: [boost] Boost.Convert+Boost.Parameter
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-03-03 14:15:00

On Tue, Mar 3, 2009 at 1:58 AM, Vladimir Batov <batov_at_[hidden]> wrote:
>> From: "Emil Dotchevski" <emildotchevski_at_[hidden]>
>> 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