Re: [boost] [convert] Now with Boost.Parameter interface.

Subject: Re: [boost] [convert] Now with Boost.Parameter interface.
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-06-29 09:40:40

On Monday, May 04, 2009 12:12 AM
Vladimir.Batov_at_[hidden] wrote:

[I'm sorry it took so long to reply to this!  I lost your post for a while.]

> I've incorporated, uploaded to the Vault and started playing
> with the Boost.Parameter-based interface that Andrey Semashev
> was insisting from the set-go. And it is definitely growing on
> me and I like
>
>    int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
>
> instead of the original
>
>    int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
>
> I think people generally did not like locales and dothrow
> behaving like manipulators.

I was one of them.

> The more I use the Boost.Parameter-based interface the more I
> am inclined to push it further and apply it to manipulators as
> well. I.e.
>
>    int i = convert<int>::from(str)(radix_ = 16);
>
> instead of the original direct handling of std manipulators.
>
>    int i = convert<int>::from(str) >> std::hex;
>
> Something, again, Andrey was advocating from the start. Now it
> feels like allowing io-stream manipulators exposes too much
> implementation detail and raises some unwarranted expectations.

I am quite against this approach.  The whole point of this mechanism is to rely upon the insertion and extraction operators of UDTs (as well as built-ins) for IOStream conversions of one type to another.  You require such operators for the conversion to work.  What otherwise hidden implementation detail is exposed by supporting manipulators on that stream, too?

> That raises a few questions that I am hoping people could help
> me with:
>
> 1. Both interfaces (for locale and dothrow) are currently
> supported:
>
> #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
> #2 int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
>
> Should I remove #1?

You should remove #2, not #1.

> 2. Both interfaces
>
> #1        int i = convert<int>::from(str, 0) >> std::hex;
> #2        int i = convert<int>::from(str, 0)(radix_ = 16);
>
> are currently supported. Should I move away from direct
> manipulator support and remove #1?

#2 provides an interesting, high level abstraction that seems attractive, but only applies to numeric conversions.  The purpose is the same as >> std::hex so, I don't see the value of radix_ when that manipulator is commonly known, documented in the literature, and well understood on sight.  I don't think users can add their own named parameters for convert(), so the library provided named parameters will occupy special status and shouldn't favor one sort of conversion above another.  Consequently, use manipulators when available.

> 3. I only managed to figure out how to supply only one
> Boost.Parameter at a time like
>
>    int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
>
> I understand how to achieve
>
>    int i = convert<int>::from(str, 0)((locale_ = new_locale, throw_ = true));
>
> (with double quotes) but do not want to go there as it looks somewhat
> unorthodox. I cannot figure out how to achieve the following

The doubled parentheses are, indeed, rare outside Boost.Preprocessor type code.

>    int i = convert<int>::from(str, 0)(locale_ = new_locale, throw_ = true);

That is certainly preferable syntax.

> (a list inside single quotes). I remember Andrey mentioning I
> could do that with a Boost.Parameter macro but I admit of not
> being bright enough to figure it out by myself. Any help would
> be greatly appreciated.

I have no information to offer on that point.

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