On 05/22/2014 08:40 PM, alex wrote:
From: Boost [mailto:boost-bounces@lists.boost.org] 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?