Boost logo

Boost :

Subject: Re: [boost] [convert] Now with Boost.Parameter interface.
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-06-30 08:22:47

Vladimir Batov wrote:
> From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
> >> 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.
> Yes, that's what I *actually* meant to say back then. :-) Now
> though after having both around I am not sure. As I mentioned I
> do like named-parameter-based interface -- I find it pleasant
> aesthetically (I just happen to like op()) and friendly.
> However, while typing I find myself favoring the frugality and
> practicality of #2. It is probably because
> 1) #2 uses the same interface/notation as ">> std::hex" (I
> admit of being a consistency/uniformity freak);

I like consistency, too, but as Emerson said, "a foolish consistency is the hobgoblin of little minds," so let's not put too much stock in it.

> 2) #2 is less to type (#1 requires using namespace
> boost::conversion::parameter;) (surely a weak argument but it
> saves me a round trip to the top of the file to add 'using');

That's a good argument actually, especially when coupled with...

> 3) I do not seem to find any other use for the named-parameter-
> based interface beyond locale_ and throw_ (so that the support
> basefor #1 is somewhat small... although this interface clearly
> scales better and more uniformly).

Combining the need for a using directive with the lack of named parameters, I find the use of named parameters questionable. They add compile time overhead and some code complexity for relatively little value.

I have forgotten now the arguments against the following, but I offer it again as a better interface because there's no using directive needed, yet there's a distinction between influencing the convert framework's behavior and the IOStreams conversion operation:

   int i(convert<int>::from(str, 0).locale(new_locale).throw_());

That is, rather than named parameters *or* (to my mind) misusing manipulators, simply use function calls to set those options. That even permits named functions for related options like classic_locale(), nothrow(), etc., easily providing additional flexibility and expressiveness.

Manipulators added to that convert expression, then, are ordinary manipulators that affect the underlying stream. There are none that apply to the convert framework while the rest apply to the stream. Separating the interface to those two parts of the machinery is a wise course, don't you agree?

Rob Stewart robert.stewart_at_[hidden]
Software Engineer, Core Software using std::disclaimer;
Susquehanna International Group, LLP

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at