Subject: Re: [boost] Boost review of the Convert library is ongoing
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-05-22 18:44:38
On 05/22/2014 08:40 PM, alex wrote:
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Vladimir
>>> On 05/22/2014 01:54 AM, feverzsj wrote:
>>> hi, list
>>> here are some personal opinions/thoughts on the convert lib:
>>> 1. in most cases, I found directly use of the converter would be more
>> Indeed, converters can be called directly. However, I advocate that
>> calling various conversions via one(!) familiar/known boost::convert()
>> interface ensures *known* behavior, better readability, better
>> adaptivity to requirement changes (when one needs to upgrade/replace
>> already deployed converter, etc.).
> If you really want only one known convert interface, maybe your design
> should reflect that.
Indeed, and I feel the current design does just that -- one interface --
boost::convert::from() (for the version under the review).
> At the moment you have one familiar / known interface
> for converter developers (success = cvr.from(in, out)) and one for converter
> users (out = convert<int>::from(in, cvr)).
Either I am confused or you misinterpret the meaning of "interface".
Interface is for the users... that's why it's called "interface" in the
first place... IMO anyway. "convert" does not have any interface that
converter developers need to use. In fact, converters are not aware or
coupled with "convert" infrastructure. What "convert" says with regard
to converters is -- if you want to be incorporated into "convert"
framework, you need a certain signature -- it's called a requirement.
> Whereby the boost::convert<> acts
> as the middle man. Anybody looking for efficiency will consider eliminating
> the middle man.
1) With that way of thinking we need to eliminate all the human
managers, team leaders, etc. from the process. Even though sometimes I
feel that way ;-) it's not for the reasons you mention. Big projects
won't survive without them. "convert" interface provides the same
benefits what lexical_cast does. If you do not appreciate advantages of
lexical_cast deployment over "direct" calls, then I won't be able to
convince you of "convert" interface advantages.
2) Anybody looking for efficiency will run a profiler and will see that
that mentioned "middleman" is nowhere on the list. More so, if you
really care for efficiency, try compiling optimized and then try finding
that "middleman" anywhere. :-)
> I don't see the problem of having two familiar/known interfaces; I believe
> it is quite usual to have convenience functions for users.
My experience tells me otherwise. I find two interfaces unnecessary,
confusing, complicating maintenance and readability. Why I need two when
one does it?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk