Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-04 13:24:53

Gordon Woodhull wrote:
> On May 4, 2011, at 9:57 AM, Matt Chambers wrote:
>
> > I definitely could do without the tags to pick an overload.
> > I'd much rather have the try_ prefix. So:
> >
> > int i = convert_cast<int>(s); // might throw
> > int i = convert_cast<int>(s, 17); // won't throw
> > optional<int> i = try_convert_cast<int>(s); // won't throw;
>
> Yep, not bad.
>
> > convert<int>::result i = try_convert_cast<int>(s, 17); //
> > won't throw; specialized version of optional is necessary to
> > detect failure
>
> No, no special optional thing is needed.  Please reread my
> 8:35am reply to Vladimir.
>
> Sorry, it's a pair<bool, int>.  Why do people hate pair?

I think I covered that well in reply to Vicente.

> There's a boolean and a value, why is that not a pair?  The
> returned value is not optional in this case.

I had forgotten the case of needing an initial value because T() isn't available (default constructor or zero-initialization, depending upon type), but also not wanting an exception.  That's what this one is supposed to handle, but I think it can be handled better another way.

   optional<int> o(try_convert_cast<int>(s, 17));

If the conversion succeeds, the optional is set and one extracts the value.  If the conversion fails, the optional isn't set.  17 represents a value supplied for a non-DefaultConstructible UDT to create the function local variable needed to store the return value.

Thus:

1. T convert_cast<T, S>(S)
2. T convert_cast<T, S>(S, T)
3. T convert_cast<T, S>(S, T, nothrow_t)
4. optional<T> try_convert_cast<T, S>(S)
5. optional<T> try_convert_cast<T, S>(S, T)

In 1, the result valid unless there's an exception.  It doesn't work for non-DefaultConstructible UDTs.

In 2, the result is always valid since it never throws.  It works for non-DefaultConstructible UDTs, but not for types without a suitable fallback value.

In 3, the result is valid unless there's an exception.  2 and 3 could be merged, but keeping them distinct is probably more efficient and should be easier to document.

In 4 and 5, the optional is set iff the conversion succeeds.

4 is useful for built-in types and DefaultConstructible UDTs.

5 is useful for all types.

Arguably, "try_convert_cast" wants a better name.

What's missing, then, is getting an exception when a conversion to a non-DefaultConstructible UDT or a type with no fallback value fails.  That is, a variant of 2 that throws on conversion failure:

> > // I'd get rid of these:
> > //int i = convert_cast<int>(s, 17,
> throw_even_though_i_specified_a_failback_); // what's the
> purpose of this overload?
>
> This is the nondefaultable case where you still want it to
> throw.

Right.  My case 3.

> > //optional<int> i = try_convert_cast<int>(s, 17); // this
> doesn't allow checking for failure, so there's not much point
>
> Again, it's for nondefaultable types.  You need to supply a
> value, but you wouldn't actually use it if conversion failed.

Right.  My case 5.

> > //pair<bool,int> i = convert_cast<int>(s, 17,
> fallback_and_report_success_); // it's burning my eyes
>
> Hahaha.  Again, this is replaced by your
> try_convert_cast<int>(s, 17) and you could call it something
> else but it's really a pair.

Not needed.

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