Subject: Re: [boost] [convert] Now with Boost.Parameter interface.
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-07-01 07:28:36
> From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
>> >> #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ =
>> >> true);
>> >> #2 int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
>> 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.
Yes, I've heard that quote. The problem with its applicability here as I see
it is that 1) we have to define what constitutes a *foolish* consistency; 2)
in his "Self-Reliance" Emerson's interpretation of consistency was not even
close to our interpretation of the word within our s/w engineering domain.
Emerson's interpretation (and dismissal) of consistency is clearer when he
elaborates further -- "Speak what you think now in hard words, and to-morrow
speak what to-morrow thinks in hard words again, though it contradict every
thing you said to-day".
So, I feel that the deployment/interface consistency might not be that
easily dismissed with Emerson. Still, I do realize that for better or worse
i/o streams somewhat usurped >> & << operators. That said, I personally do
not feel it is such a hurdle (to me anyway) and I am guilty of using op>>()
for manipulators and locales.
> Combining the need for a using directive with the lack of named
> 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_());
I do not feel (or remember) there might have been arguments against the
interface above. It is an old and humble alternative to Boost.Parameter -
another approach to the "Named Parameter Idiom" described in
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.18. Still, I
personally like Boost.Parameter better as I feel it implements the idiom in
a generic and more consistent manner. More so, Boost.Parameter-based
interface is easier to deploy across different conversion specializations.
That said, it'd be ideal to collect more input from the people using
boost::convert. I admittedly have not had much (if any) input but still
hoping that the situation might improve with time and closer to the actuall
> That is, rather than named parameters *or* (to my mind) misusing
> 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.
Yes, as I said I do not have anything major against this apart from the fact
that I feel Boost.Parameter might fire better accomplishing that.
> 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?
Well, out of laziness or some other reason I am guilty of simply typing
"convert::from >> std::hex >> locale". I know 'std::hex' and 'locale' affect
different underlying parts. However, on the application level it does not
seem that important to me -- in the end it shapes up the conversion. So, I
am not that determined about "separating the interface to those two parts of
the machinery". It's like my transmission stick and the steering wheel are
two different interfaces to two different parts of machinery. However, I
would not probably mind if I could handle steering and transmission with
just one thing.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk