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

Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-12-02 10:45:43

[I found this reply in my "drafts" folder.  I must have been forced to log off or reboot and forgot about it before finishing it and sending it.  Here's hoping there's still value in the content, if only to reawaken thoughts on the proposed library.]

On Thursday, February 26, 2009 1:35 AM
Vladimir Batov wrote:
> > From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
> > ...
> > 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.
>
> Well, that's IMHO too bad. I obviously cannot carry on
> forever and I do not

I wasn't suggesting anything so extreme as carrying on forever.

> see a consensus getting any closer. The crux of the matter
> (in my view) is that the convert() functionality is available
> and IMHO way better than lexical_cast has to offer. Rejecting
> it because Spirit can do formatting better or because convert()
> does not use Boost.Parameter would be shortsighted IMHO as in
> the end people will be still left with nothing -- a huge hole
> between lexical_cast and Spirit. Is it realistic/practical
> approach? I do not think so. When/If something better comes up,
> this functionality will die out by itself.

It is decidedly not better to have _anything_ because _something_
is needed.  There have been many ideas, some better than others
(and I don't mean mine were better and the rest weren't!), that
have shaped the current notions.  There may yet be a brilliant
idea that will reconcile things even better than now or a
simplification that better focuses the role of your proposal.

> > 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.
>
> Again, I am not convinced that what I have on offer is badly
> conceived.

I'm sorry that my phrasing led you to think that, but I didn't
mean to suggest that what you have now is badly conceived.  I
meant that we may be shortsighted or overreaching now and that
some compelling alternative or argument may yet be raised that
makes what we now have pale by comparison.

> Surely, there's been quite a discussion about names and the
> 'string' namespace. However, I hope that well-conceived means
> quite a bit more than just names... which we'll never come to
> an agreement about.

There has been a lot of discussion and about more than just
names.  It has all been useful as the arguments and suggested
alternatives raised thus far have either altered what was or have
permitted a better defense of what is.

> So, if it is really the case that the naming (rather than
> functionality) will be the deciding factor for an acceptance or
> a rejection, maybe it is better to drop the whole thing
> altogether.

This is too precipitous.  My suggestion was to have some
patience.  Let ideas settle.  See if others have more thoughts.
Produce use cases and see how well the various interfaces work
and show the results on the list.  Those harboring doubts may
warm to the idea or finally conceive what they'd rather have and
win the rest.

> >> > What about the concern I raised early on about implicit
> >> > conversions?
> > The output value can still be implicitly converted to the
> > caller's 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 &)
>
> Aha, now I understand. Passing a parameter by a non-const
> reference. Yes, as above we indeed avoid the implicit
> conversions. That's nice. Never occured to me. I admit I am
> allergic :-) to returning results this Pascal-style. Never grew
> on me. Sorry. Just not my cup of tea. Will probably do
> > *anything* just not to have it. :-) Truly sorry.

That interface provides support for types without a default
constructor and increases safety.  It can, of course, be built
atop the other interfaces, so there's no reason the library
couldn't supply it as a safer alternative for those not allergic
to output parameters.

> > Without that, the following might surprise someone:
> >
> >   foo f(convert<double>("1234.5"));
>
> Yes, that's typical of C/C++. Although I admit that after
> reviewing/looking at so much of somebody else's code it has
> never been my major concern. And isn't a compiler warns us of
> things like that?

That's a legitimate use of the converting constructor so the
conversion will be silent.  That's the danger of such
constructors generally, so it isn't just convert's problem, but
altering or extending convert's interface can overcome it
readily.

> > 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."
>
> Wel, calling it "advanced" is probably a bit rich. How about
> simple and "better" failure checks. They *are* failure checks,
> aren't they?

Those adjectives don't help.  Just note the use cases as testing
for the default or for a success flag.

> > 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.
>
> As I indicated, I am not convinced there is such a clear cut
> as I might be forced to provide a default (due to no def.ctor)
> but still want to throw. My thinking behind convet_to,
> convert_from is that the latter *is* the interface. I'd be
> happy to get rid of #1 (which is convert_to) but I think it'd
> better be there for better transition from lexical_cast.

I'm lost on the application of "convert_to" and "convert_from" to
my list.

> As you indicated in your very first reply to this thread (in
> relation to string::is()) #3 will have to actually try the
> conversion. If I remember correctly you did not like it much
> (or did you object to the name only?).

I'm not sure what reply you're referring to nor what the
discussion was about.  However, in order to return false on a
failure to convert, of course the conversion must be tried.  What
am I missing?

> > 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.
>
> Again, my real example:
>
> direction dir = convert_from(str, direction::up);
>
> It takes the default because it has to (no def.ctor). It does
> not mean I do not want to throw on failure... In real life, I
> don't. However, then I need a means to distinguish the
> failure. With
>
> convert::result<direction> dir = convert_from(str, direction::up);
> if (dir.good())
>
> I can achieve that without resorting to your #3 to actually try the
> conversion twice.

Why twice?

> > 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.
>
> I feel there is too much emphasise on formatting. I do not
> believe convert() is the tool for it. For good formatting we
> need good formatting tools (Spirit?). However, for basic
> formatting IOStream-based approach works for me -- I do not
> need to bring a cannon (Spirit) to shoot a few little birds
> (basic formatting).

That's a legitimate point, but then is the facility really to
handle conversions among multiple types or, as Emil Dotchevski
asserted, is it really just for conversion to and from string?
If the latter, then another interface is probably better since
the current interface implies arbitrary inter-type conversions.

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