Re: [boost] Boost review of the Convert library is ongoing

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
>>> convenient:
>>>
>> 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?