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

Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-02-25 09:16:55

On Wednesday, February 25, 2009 2:29 AM
Vladimir Batov wrote:
> > From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
>
> Surely, the 'string' namespace and some stuff are gone,
> implementation looks
> nothing as before. Although I'd expect "adjustments" like
> that to be an
> expected result of a review. Granted, my first "Review

The review should not be the means to find out what the finished library should be.  Ideally, you want nothing but praise and affirmation at that time.  There will usually be some late to the party who will find something new to disturb what had been thought so well in hand, but you shouldn't come to the review expecting to get lots of good ideas to completely reshape the library.

> Request" posting was
> not that much of a review (as Scott correctly noted) as I wanted to
> request/review/flash out what people actually needed from
> convert. Still,
> your point taken. Do you think we are any closer to "formal
> formal review
> request"?

I don't think there's any reason to pursue a review until things begin to quiesce which doesn't appear likely any time soon, if the current discussions are any indication.  I appreciate your excitement, but it would be far better to have a well conceived, broadly acceptable idea before heading for review.  Otherwise, you're quite likely to find your library rejected with comments like you're seeing now.

> > What about the concern I raised early on about implicit conversions?
> > The ideal interface has the compiler deducing both the source and
> > destination types to avoid implicit conversions of the
> source object to
> > the source parameter and the conversion result to the
> destination object.
>
> Unless I misunderstand, don't we achieve that with
>
> template<class TypeIn, class TypeOut>
> TypeOut
> convert_from(TypeIn const&, class TypeOut  const&)

The output value can still be implicitly converted to the callers destination object.  To avoid input and output conversions, you need the likes of this:

   template <class Out, class In>
   void
   convert(In const &, Out &); // or convert(Out &, In const &)

Without that, the following might surprise someone:

   struct foo
   {
      foo(int);
   };

   foo f(convert<double>("1234.5"));

> double d = convert_from<string, double>(str, -1/*implicitly
> converted to
> double*/)

That is always an issue, but the possibility of implicit conversion is clear when the caller identifies the exact specialization to use.

> > 4) and 5) are incompletely specified.  What are the use cases?
> > What sort of formatting control is needed?
> > Does the current interface support them?
> > Without use cases specifying the desired usage pattern,
> > it's hard to know whether the current interface is sufficient.
>
> As for #4 I tried covering that in the doc. and in a nutshell
> it is as
> follows:
>
> int i = convert_from(str, -1);
> if (i == -1) // simple check
>
> convert<string, int> i = convert_from(str, -1);
> if (i.good()) // "advanced" check

I had no idea that testing for the default value or querying a success flag was what you meant by simple and advanced "failure checks."  I think there should be two or three distinct signatures for using the conversion facilities:

   1. A call that throws on failure.
   2. A call that takes a default and always succeeds.
   3. A call that returns false on failure.

The third one is questionable.  Certainly the first could be built atop the third, but the second provides a means to approximate the third (assuming there's a default that can always be considered a failure value).

With that set of signatures, there's no implied need for a special return type that converts implicitly to the destination type and can be queried for success, or a throw/nothrow flag.  There may yet be a special return type to account for specifying the default value as I suggested elsewhere, or for some other peculiarity, but it isn't a given.

So, the questions are, whether all three signatures are needed and how they should differ.  I suggested a way that the first and second can be handled in the "[convert] Default Syntax Idea" thread, of course.  If we support the third, how should it look and work?  (I'll pursue that separately.)

> As for #5 then, it is as much or as little as std::stream
> provides. That, in
> fact, covers all my formatting need and I think could be a
> good basis. I am
> very reluctant getting more adventurous as I suspect the
> process will drag
> for long time and will fizzle out with no result in the end.

I had no idea that you were referring to the formatting facilities inherent in the underlying IOStreams implementation.  Still, there must be a large number of use cases of various kinds of UDT and builtin conversions, complete with a variety of formatting tasks, to determine if the interface will cope well in this context.

> > What about Emil Dotchevski's desire for from_string() and
> to_string()?
> > Have those been dropped entirely?
>
> Indeed, Emil was very vocal about those to/from_string. I
> followed the
> discussion and believe you provided very weighty arguments in
> favor of a
> more generic scope. That's the direction I took.

That's fine, but I wasn't sure you had made a conscious choice to pursue the generic approach at the expense of Emil's arguments.  On balance, I like the generic approach because it isn't string focused, it builds upon the IOStreams facilities, and it is extensible.  However, there remains merit in what Emil wanted because of the optimizations possible.  I think his functions can still be used under the facade, so he might yet be happy with that part.

> > I think it was Emil's intention that those functions be concerned
> > with providing optimized conversions to/from string with only
> > limited formatting support, ...
> > I didn't want Emil's concerns to be dropped altogether.)
>
> I do not think Emil's concerns have been dropped. Yes, there
> is probably no
> support for his specific needs in the current IOstream-based
> implementations. However, the "framework"-style approach supports
> specializations. I.e. Emil could write his own specific
> conversion (to/from
> any type) and have it deployed via the "framework" interface.
> That's what
> I've been doing with lexical_cast -- specializing it for my
> types to allow
> handling them via common (lexical_cast) interface.

I'm not sure whether the two can cooperate because one supports formatting the other isn't likely to support.

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