Re: [boost] [convert] no-throw and fallback feature

Subject: Re: [boost] [convert] no-throw and fallback feature
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-10 07:01:06

Vicente BOTET wrote:
> De : "Stewart, Robert"
> > Vicente BOTET wrote:
> > > De : "Stewart, Robert"
>
> > > > int i;
> > > > bool b;
> > > > ctie(i, b) = try_converting_to<int>(s);
> > > > if (!b)
> > > > {
> > > >    i = fallback;
> > > >    std::cerr << "using fallback\n";
> > > > }
> > > >
> > > > Compare that to this:
> > > >
> > > > int i(fallback);
> > > > if (!try_converting_to(s, i))
> > > > {
> > > >    std::cerr << "using fallback\n";
> > > > }
> > >
> > > The fist is more on the line of functional paradigm. The
> > > second on the procedural one. I understand that the
> > > procedural one can be more efficient, but the functional
> > > one separates clearly what are the in a,d the out
> > > parameters. Are both alternatives exclusive?
> >
> > They aren't exclusive, but they'd need different names and,
> > again, I suspect we'd be getting into the too-many-choices
> > conundrum.
>
> Couldn't overload be used here?

It could.  However, there are two issues.  First, note that the second doesn't require the target type template parameter because of the second argument.  Second, we're back to the discussion that a "try_" function not returning bool.  You've noted that optional offers the safe-bool implicit conversion, of course, but these issues will probably cause concern if not confusion.

Recall that the optional returning version can be written as convert_cast<optional<int>>(s) (or convert_to<optional<int>>(s)).  Doing so is clear, works nicely with auto, and avoids the issues with a non-bool return value and difference in template parameter treatment.  Consequently, I think that's a superior approach.

> > > > Besides, the same thing is done with the following which
> > > > is simpler and less tricky:
> > > >
> > > > int i;
> > > > if (try_converting_to(s, i)) ...
> > >
> > > If conversion to bool is implicit the bool parameter will
> > > be redundant and the preceding could be expressed as
> > >
> > > int i;
> > > if ((opt_tie(i) = try_convert_to(*int*)(s))) ...
> >
> > Ah, right. That's a curious approach to it. You're
> > suggesting, if I have all the parts aligned right, that
> > try_convert_to() return optional and that opt_tie() assign
> > to its argument iff the optional is set. That means there's
> > an optional-based API and the following is also possible:
> >
> > int i(fallback);
> > opt_tie(i) = try_convert_to(s);
>
> Yes this something I could use.

Note that such a function need not be named "try_convert_to."  I'm not sure what other name to give it, at present, but it would be useful either way.

It appears that we're suggesting that opt_tie() be overloaded:

int i;
bool b;
opt_tie(i, b) = convert_to<optional<int>>(s);
if (!b)
{
   i = fallback;
   std::cerr << "using fallback\n";
}

and

i = fallback;
opt_tie(i) = convert_to<optional<int>>(s);

Note that it seems to me that opt_tie() should be part of Boost.Optional.

For completeness, here's code making the optional explicit and showing the overload:

optional<int> o(convert_to<optional<int>>(s));
if (!o)
{
   o = fallback;
}

if (!try_convert_to(s, i))
{
   i = fallback;
}

(I haven't given up on "convert_cast" but I know you prefer "convert_to.")

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