Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-09 17:33:12

Vicente BOTET wrote:
> De : "Stewart, Robert"
>
> > To summarize, here's the complete API as I see it now:
> >
> > 1. convert::default_value customization point
> > * Default value, if needed, when not otherwise supplied
>
> I don't see this customization point exclusive for conversions.
> I will move it to the boost namespace.

I don't know about that.  If a type has a globally applicable default value, then it will have a default constructor (or be zero-initializable).  I see default_value as specific to conversions.

> > 2. convert::converter customization point
> > * Non-stream-based main logic
> > * Functor interface
>
> Do you mean that the default behavior is a call to the
> conversion operator?

The default behavior is to rely on T(S) or T = S.  Specializations of converter<T,S> can do things differently.

> > 3. T convert::convert_cast(S)
> > * Throws on failure unless T is convert::result
> > * Uses convert::converter to do conversion
>
> I prefer conversion::convert_to.

That looks every bit like a cast.  Why not name is so?  Still, if there are to be parallel namespaces (see below), then convert_to() would be good.

> > 4. T convert::convert_cast(S, T _fallback)
> > * Returns _fallback on failure unless T is convert::result
> > * Uses convert::converter to do conversion
>
> I prefer conversion::convert_to_or.

Overloading is a lot cleaner to my eyes and, of course, I don't like your name as I've noted.

> > 5. bool convert::try_converting_to(S, T & _value)
> > * Returns false and leaves _value unchanged on failure
> > * Uses convert::converter to do conversion
>
> I prefer conversion::try_convert_to.

It doesn't read properly, but I now see why you like it: you are adding "try_" to "convert_to" the name you want for #3.  There is asymmetry in convert_cast/try_converting_to versus your convert_to/try_convert_to, which is good.  However, convert_to_or simply has to go! ;-)

> > 6. convert::stream_converter customization point
> > * Stream-based main logic
> > * Functor interface
> > * Supports manipulators
>
> What about streamable::converter?

In my mind, there's one main namespace for the conversion library.  Therefore, that would need to be conversion::streamable::converter and then I'd expect conversion::something_else::converter for the non-stream-based converter.  I'd prefer conversion::converter and conversion::stream_converter, but that does require different names for the two sets of function templates.

> > 7. T convert::as(S, options)
> > * Throws on failure
> > * Uses convert::stream_converter to do conversion
>
> What about streamable::convert_to?

conversion::streamable::convert_to() is fine, but then the non-stream-based version should be conversion::something_else::convert_to().  Still, this makes for highly parallel interfaces -- other than where the streamable API includes support for the extra formatting, etc. -- so is worth further discussion if a good pair of namespace names can be found.

> > 8. T convert::as(S, T _fallback, options)
> > * Returns _fallback on failure
> > * Uses convert::stream_converter to do conversion
>
> What about streamable::convert_to_or?

Nope; I very much dislike the "to_or" naming.  Once again, I like the overloading.  They differ by one argument which dictates no exception.  I don't see why they need a different name.

> > 9. bool convert::try_as(S, T & _value, options)
> > * Returns false and leaves _value unchanged on failure
> > * Uses convert::stream_converter to do conversion
>
> What about streamable::try_convert_to?

If there's to be conversion::something_else::convert_to() and conversion::something_else::try_convert_to(), then conversion::streamable::try_convert_to() is fine.

BTW, I think "streaming" or even "stream" is better than "streamable."

> > Does that cover everything satisfactorily? Did I miss
> > something? Except where I have suggested specific support
> > for convert::result, I don't think it should be allowed.
> > (That is, use SFINAE to ensure that convert::result isn't
> > used with the other parts of the API.)
>
> If try_ will return bool, I think that we need also a function
> that returns optional.

OK.  There are those that dislike non-const reference arguments, so such an interface would satisfy those.

> Even if the function has the problem related to a template
> parameter, the name of the function don't reflect that the
> result will be the parameter T, and doesn't return a bloated
> interface, but a well know and useful class that I believe is
> proposed for TR2, or if it is not the case it should be.

I'm sorry.  I couldn't parse that.

> The names I have suggested allow to have two more or less
> independent libraries, that follows the same interface on the
> common needs, but having a different default behavior. For the
> specific stream conversions there are surely a lot of variants
> that can be provided.

I won't summarize the API this time because there are names to be ironed out, but there is the optional-based interface to add.  I think that's best handled by making the use of optional explicit:

   optional<int> const o1(convert_cast<optional<int>>(s));
   optional<int> const o2(as<optional<int>>(s));

When auto is added to the mix, it works very nicely.

   auto const o1(convert_cast<optional<int>>(s));
   auto const o2(as<optional<int>>(s));

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
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.