Subject: Re: [boost] [convert] Now with Boost.Parameter interface.
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-06-30 05:00:50
> From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
> [I'm sorry it took so long to reply to this! I lost your post for a
Hi, Rob, it's nice hearing from you.
>> 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.
Yes, that is *exactly* the conclusion I've come to. #2 indeed looks cute and
aestetically I much prefer #2... but it seems to be merely a sugar coating
over #1. On the other hand, #1 hardly needs *any* explanations/support for
the reasons you mention and that imho makes it a clear favorite. On top of
it, I either do not see how named-parameters-based interface can be made
user-extendable unless we pack all the parameters into ArgumentPacks and
pass them to the user. Maybe that might be the way to pursue in the future
but I feel we pretty much get all that right off the bat with ol'
>> 1. Both interfaces (for locale and dothrow) are currently
>> #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ =
>> #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
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');
3) I do not seem to find any other use for the named-parameter-based
interface beyond locale_ and throw_ (so that the support base for #1 is
somewhat small... although this interface clearly scales better and more
These are just my musings how I torn feel about both rather than serious
arguments for or against.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk