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

Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-02-18 14:18:04

On Wed, Feb 18, 2009 at 10:21 AM, Stewart, Robert
<Robert.Stewart_at_[hidden]> wrote:
> On Wednesday, February 18, 2009 1:15 PM
> Steven Watanabe wrote:
>> Stewart, Robert wrote:
>> > On Wednesday, February 18, 2009 12:46 PM
>> > Emil Dotchevski wrote:
>> >>
>> >> Many times I've needed to_string without needing from_string. In my
>> >> book, this is a strong indication that they shouldn't be coupled.
>> >
>> > Your argument isn't compelling.  Consider an arbitrary
>> precision integer type.  If many times one need only add such
>> values, without also needing subtraction, should those
>> operations be separated one from the other?
>>
>> It isn't necessary to separate them, but it is not
>> unreasonable to do so
>> either.
>
> I won't argue that point, but it only applies if there are two such sets of functions.  If there isn't "from_string" and "to_string," but only, for example, "convert," then there's no point in separate headers.  It's a question of whether "string" should be at the center of the conversions as it is with "from_string" and "to_string."

"If you have two separate classes A and B, if instead you cram them
both into a single class C, then there's no point in separating them."

You're presuming that it makes sense to put converting to- and from-
string into a single interface. For what it's worth, consider that
sprintf/sscanf are separate interfaces too, despite the many
similarities and analogies between them.

Unlike addition and subtraction which are symmetrical, converting to-
and from- string isn't. For example I searched our source code for
to_string and from_string. We have 314 occurrences of to_string (in
112 source files), and only 33 calls to from_string (in 11 source
files.) Only 2 files use both to_string and from_string.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode