Re: [boost] Formal Review Request: Boost.String.Convert

Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-18 17:27:03

Emil Dotchevski wrote:
> On Wed, Feb 18, 2009 at 1:44 PM, Andrey Semashev
> <andrey.semashev_at_[hidden]> wrote:
>> Emil Dotchevski wrote:
>> I assume there can be connection with other Boost libraries, like
>> Boost.NumericConversion or Boost.Units. This library has potential to become
>> a common framework for conversion facilities that are reimplemented here and
>> there quite often. And I feel that a common and well recognizable interface
>> is very important for such a framework. That is, I think it would be better
>> to use a common name for conversions in either direction (well, the
>> direction doesn't matter anyway, from perspective of such a framework).
> 
> Agreed.
> 
> The disagreement seems to be about the relationship between such
> conversion library and to- and from- string conversions.
> 
> IMO, from the viewpoint of convert(), to- and from- string conversions
> should be treated as independent interface, much like
> Boost.NumericConversion or Boost.Units, etc.

Why? Why not using, e.g., streaming operators for string-related 
conversions underneath the "convert" interface? This already is an 
established way of providing conversions to/from string, I don't see why 
it should be dropped.

> I'm strongly opposed to the approach of "convert() is great for
> strings, maybe we'll extend it later for other things." Maybe you
> will, maybe you'll find out that it can't be extended because nobody
> thought about convert()ing anything but strings. In fact, merely
> thinking about the other types isn't enough, we need practical
> experience with "the mother of all conversions" library before it is
> added to Boost. :)

I agree that the "convert" function, or whatever name it will end up 
with, from the start should be targeted for generic conversions of 
arbitrary types between each other. Having that kind of function and an 
efficient library extension mechanism, I don't need any other conversion 
facilities whatsoever.

> (Though as it is evident, you'll still have hard time convincing me
> that when all I need is to convert a foo to std::string, I have to use
> "the mother of all conversions" library instead of the straight
> forward to_string.)

Perhaps. I still don't understand why would you want to use specific 
functions, like to_string/to_wstring/to_whatever_string(foo) instead of 
a unified interface function convert< whatever >(foo).