Re: [boost] [Review] Boost.Convert library, last day

Subject: Re: [boost] [Review] Boost.Convert library, last day
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-03 12:50:04

Matthew Chambers wrote:
> On 5/3/2011 10:36 AM, Stewart, Robert wrote:
> > Christopher Jefferson wrote:
>
> >> Out of interest, what would:
> >>
> >> auto str = boost::convert<std::string>::from(123);
> >>
> >> Do? If boost::convert stores by pointer/reference, it would
> >> be quite dangerous.
> >
> > str would be a boost::convert<std::string>::converter, not a
> > std::string as one would probably expect.
> >
> >> I think making libraries 'auto safe' is a good idea, I
> >> expect to see auto usage shoot up very quickly, and
> >> libraries should do their best to work well with auto.
> >
> > This may be one of the most compelling arguments against the
> > current interface.
>
> Agreed. I know I'll be jumping on the bandwagon as soon as auto
> becomes mainstream in my two main compilers, MSVC and GCC. So
> this is a compelling argument. But would it even be possible to
> keep the "smart result" (either convert<>::result or optional<>)
> and auto compatibility? If (as I suspect) not, this would seem
> to necessitate different syntax for value/throw and functor.

The above does provide the "smart result," but I think is surprising in the context.  Arguably, there would be times a user would want the "smart result," so it isn't certain that this example obviates that part of the interface.  Rather, this points to the need for distinct calling conventions -- whether by varying the argument list or using differently named functions (function templates) -- in order that what auto infers is what the user expects.

   auto i(convert_to<int>("123")); // 1
   auto j(convert_to<int>("123", -1)); // 2
   auto t(try_converting_to<int>("123")); // 3
   converter<int> f; // 4

In // 1, i is int and the call can throw an exception on conversion failure.

In // 2, j is int and the call will return -1 on conversion failure.

In // 3, t is boost::optional<int>.  Note that using optional rather than Boost.Convert's result type means that accessing the value will not throw an exception; it's undefined behavior, IIRC.  "try_converting_to" is rather verbose, so some other name is probably wise.

In // 4, auto isn't helpful, so I didn't show it.  I'm thinking f is a function object with a member function template function call operator that forwards to some customization interface that permits target/source-specific customizations.

I think that covers all of the use cases and plays well with auto.

In the first three cases, we could use "xxx_cast" instead of "convert_to" and "try_converting_to," as I'd previously suggested, except that "123" cannot be used to distinguish between the first two and the third cases.  Now, given "auto," we could make it work as follows:

   auto i(xxx_cast<int>("123")); // 1
   auto j(xxx_cast<int>("123", -1)); // 2
   auto t(xxx_cast<optional<int>>("123")); // 3

Because of "auto," there's no repetition of "optional<int>" in // 3.  Of course there may be those offended by the second argument in a new-style cast as in // 2.

More food for thought.

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