Re: [boost] [convert] Version in the Vault ready for review.

Subject: Re: [boost] [convert] Version in the Vault ready for review.
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-04-01 09:59:35

On Wednesday, April 01, 2009 2:22 AM
Vladimir Batov wrote:
> > From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
>
> > 3. Caller wants to convert to a target type having no
> > default constructor, getting an exception on failure as
> > if there had been no default supplied:
> >
> >   Foo def(/* something appropriate */);
> >   convert<Foo>::result r(convert<Foo>::from(str, def));
> >   Foo f(r.required());
>
> The current interface does it with
> Foo foo = convert<Foo>::from(str, def)
>         >> throw_on_failure/dothrow;
> which I personally find easier to read as there is no
> convert<>::result-related noise.

My version can be written like this:

   Foo f(convert<Foo>::from(str, def).required());

> > 5. Caller wants generic code to react to a valid value
> consistently for
> > all types:
> >      convert<T>::result r(/* call other code */);
> >      if (r.valid())
> >
> > 6. Caller wants generic code to react to a failed
> conversion consistently
> > for all types:
> >      convert<T>::result r(/* get result somehow */);
> >      if (!r.converted())
>
> Yes, these #5&6 use-cases are better catered by the interface
> you advocate.  It might be that I indirectly indicated that I
> do not feel like encouraging this interface.  I see
> convert<>::result as a very transient on-the-spot token to
> get more information. I do not feel passing it around is a
> good and helpful idea. You obviously think differently.

Consider an enlarged variation of those use cases for a moment.  Imagine code that invokes a callback or hook to produce a conversion result, the return value of the callable type.  If the conversion fails, the code must report the error, throw some special exception, maybe even loop to try again.  If the conversion succeeds, the value is stored somewhere or otherwise used.  Whether the conversion uses a default is irrelevant.  Now imagine similar code that invokes a callback or hook to get a conversion result but only acts if there's an available value.  The calling code is ignorant of whether there's a default, but it must avoid an exception.  I can imagine these use cases apply to processing user input, configuration file input, or just collections of callbacks or hook functions used for application customization.

> Yes, I've got the idea and I see the need for the interface you are
> suggesting... if we are to endorse the outlined #5&6 use-cases. In
> theory #5&6 cases are valid, in reality I personally and others in
> my vicinity have not been using and needing those (otherwise, I'd
> have no choice but to implement the functionality already).
> Therefore, I do not feel like I am prepared to pay that price...yet.

They seem like valuable use cases to me.

> >> ... If I were to save convert<>::result and pass it to some other
> >> function, I'd agree that valid() would be useful
> >
> > Why isn't that a valid use case?
>
> Because I do not feel like encouraging spreading the
> evaluation of the conversion all over the place (by passing
> convert::result around). I see convert as a very direct local
> operation rather than via some function. It might be a
> limited view but it served me well so far.

If those use cases prove necessary later, how will you retrofit them to your design?

> >> I interpret manipulators somewhat more liberally (rather than
> >> so firmly associated with std::stream) and do not feel I cannot
> >> extend the concept onto convert adding more manipulators in the
> >> process.
> >
> > I've never seen manipulators used for any other purpose and
> > I think most would be surprised at their being used any other
> > way.  Thus, it would be confusing to think that a dothrow
> > manipulator did not affect the ostream's exception throwing
> > behavior but instead affected the convert<>::from() call.
>
> I hear you. I truly do. I just feel you are painting the
> situation somewhat darker than it really is. I do not believe
> the "surprise" will be such a big shock. Boost is full of far
> bigger surprises.

That there are more complicated things in Boost, I'd agree, but I don't know what surprises, of this sort, you think exist.

Did you note my reference to the stream's exception behavior?  I was referring to std::basic_ios::exceptions().  The manipulator, whether you call it "throw_on_failure" or something else, would seem to imply a call to std::basic_ios::exceptions() rather than to affect the conversion object, so the difference in expectations and reality will be a surprise.

> As I indicated we can pass that throwing information differenty. Like
>
> int i = convert<int>::from(str, -1)(throw_on_failure);
> int i = convert<int>::from(str, -1).throw_on_failure();

That latter must be on the result type and is no different than the required() I suggested.

> I found
>
> int i = convert<int>::from(str, -1) >> throw_on_failure;
>
> the least objectionable (to me) as it re-uses already
> deployed op>>() and syntax.  I.e. the same op>>() and syntax
> to configure the conversion.  I am not trying to look under
> convert() and see std::stream there.  As a user I care for
> conversion and not what *might* be under the hood.  After
> all, std::stream might *not* be there.

convert *uses* std::ostream-based operations for the conversion.  How can you suggestion it might not be present?  Those operations are prominent in making convert work, and any formatting the caller applies will be through manipulators, so the different target of your throw_on_failure manipulator must be understood.

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