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 13:02:07

On Wednesday, February 18, 2009 12:46 PM
Emil Dotchevski wrote:
> On Wed, Feb 18, 2009 at 5:52 AM, Stewart, Robert
> <Robert.Stewart_at_[hidden]> 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?

> > The directionality you see is due to focusing on string
> with the other things converting to and from strings.  If,
> instead, you view it as converting from one thing to another,
> where string can be the source or destination type, then all
> conversions are, effectively, one way.
>
> Yes, I agree that we can lead the discussion from this point of view.
> In this case we must forget about strings and talk about converting
> between all kinds of different types. You can't just say "it's not

That's what I've been doing almost from the start.

> specifically about strings" and be done with it; we have to consider
> several different use cases in particular, as well as the issue in
> general; how the conversion works, how you configure it, etc. Instead,
> the whole thing even resides in a string namespace. :)

Gee, all of that sounds awfully familiar....

> Because nobody seems to be doing this, I don't see any evidence that

Try again.

> the convert() function we could presumably end up with is any good for
> anything but converting to- and from- strings. And for that use case
> it's inferior to two independent to-string/from-string interfaces.

lexical_cast is used for many type-to-type conversions, not just with strings.  Why would this be any different?

> > Indeed, conversion to string is implemented apart from
> conversion from string, but that hardly necessitates total separation.
>
> What necessitates total separation then?

Separate UDTs.  Different domains.  Many things.

> > It may well be, as I previously suggested, that there is an
> underlying set of functions for converting to strings and
> from strings to which convert defers.  That would permit you
> to get your preferred interface while others could use a more
> generic convert() interface, provided both were documented.
>
> OK here we agree then. Let's come up with good interface for to-string
> and from-string, and then feel free to propose a separate convert()
> library.

Why is that the necessary approach?  Perhaps the end result will be something that satisfies all and there will be no need to document the underlying conversion logic.  It's too early.

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