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

Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-02-18 15:34:32

On Wednesday, February 18, 2009 2:18 PM
Emil Dotchevski wrote:
> 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."

The presumption there is that A and B are, reasonably, separate classes and that the functionality does not make more sense combined.  They may be better separated or not, but there is insufficient information from which to judge.

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

I'm not convinced that convert() is the right interface, but neither am I convinced that the operations must be separated into distinct functions with distinct headers.  My point was that using one of two operations frequently in a given context in no way implies the operations should be considered disjoint.

C doesn't support overloading so sprintf() and sscanf() can hardly be valid justification for separate conversion function names in C++.

As yet, I've seen no coherent set of requirements or use cases to bound the problem.  I've seen no agreement on what this component must do.  It is pointless to spend more time on the interface until we have that.  From what I've observed, each person has some idea in mind and assumes most others agree with that idea.  Until the goal is made concrete and considered as a clear and unambiguous whole, there's little point in debating these other aspects.

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

The operations are symmetrical, given a unique string encoding for a type.  That's the basis of many forms of serialization after all.  It doesn't matter how often one of the operations is used relative to the other when determining symmetry.  Their *use* may not be symmetrical, but that's different from the symmetry of the operations themselves.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.