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

----

Vladimir Batov writes

alex writes:

During our first (failed) "convert" review quite a few years ago many questions were "why not use lex_cast, why not do as lex_cast does?, etc". So to avoid answering the same questions over and over again I added lex_cast in the docs.

I think you were right to add the comparisons, and I should have mentioned that you make the case very succinctly and clear. I just think that by interspersing this with the actual documentation of the library you are addressing the (past) reviewers and not the future users.

...

... String-to-type is obviously possible and there is quite a bit to be done improving the docs and the code... after/if it's decided it's worth doing.

I understand but it is the existing library that is being reviewed. The following is not compiling because of the way it uses enable_if in sstream.hpp. boost::cstringstream_converter cnv; std::string str = boost::convert::from("hello", cnv).value();

Well, to me "convert<int>::from<string>" seems like a good "translation" from English "convert int to string" to C++. ...

You are right and I now agree you should keep it that way. I would not have gotten confused if the documentation also covered conversion to string. My first reading of the code was that the reverse of "i = boost::convert<int>::from(str, cnv)" would be "str = boost::convert<int>::to(i,cnv)", but I certainly don't mean to suggest this would be better. Just that I got confused.

...

I think the effort to present Convert as a general conversion library is not helpful.

Here I have to respectfully disagree.

...

To me the importance of Convert is in providing one interface to varying conversion facilities... rather than any particular converter in isolation. IMO one *generic* interface (to do conversions or anything else) is essential if one writes any *generic* code:

But your *generic* interface only captures part of the features that make the specific cstringstream_converter stand out from for instance lexical_cast.

template do_something(type_in in, type_out out) { ... convert::from(in, cnv); }

Did you mean: template void do_something(type_in in, converter cnv) { ... type_out out = convert::from(in, cnv); } My feeling is that you didn't clarify the concept of a converter except that it is a function where something goes in and something goes out. So you might have just as well have called it "algorithm" or "function". Basic things that I would expect from a *generic* converter are not offered by the Convert library. For instance in the function above I cannot check whether the converter is able to convert from type_in to type_out. Also some advanced functionality that would make a *generic* converter library very useful is not made generic in your library. For instance, In the function above I cannot use something like cnv(std::hex) because you haven't made the concept of applying modifiers on a converter object generic. For instance some of the following would be useful: converter<int>::apply_modifier(cnv, mdf) traits<converter>::can_convert traits<converter>::supports_std_modifiers I also think that for a concept this basic, the implementation should not pose unnecessary restrictions; The convert<>::from function can only convert to default-constructable types, which I think is not necessary for a *generic* converter. ...

...

I vote for inclusion in Boost, conditional to using boost::optional as a return type and a simplification of the interface. I would recommend dropping the idea of a pluggable general conversion tool and providing only the stringstream based conversion.

Well, I appreciate your vote for inclusion but I feel you have to

reconsider

either your vote or your evaluation of the *existing* design. By "simplification of the interface" and "dropping ...a pluggable" you are effectively suggesting/requesting a totally different overall design and API. To me it kinda sounds like "I vote for an autobahn but only if we build a railroad instead". So, first, you vote the autobahn down and then provide the specs for and vote on the railroad.

I voted for inclusion because I would use the library, and would prefer it over lexical_cast in most applications. However I would strictly use it for the stringstream based converter. I am not sure about the need for a *generic* conversion library, but if there is need for one it should be better attuned to the specific nature of conversion tasks and not be a catch-all concept to do something with something. Moreover, I think that the way in which Convert invokes the converter object makes it more awkward to use than necessary. I understand your analogy; my perspective however is that you created a splendid autobahn but try to sell it as a generic solution to connect A to B with potential applications in transportation, communication and time-travel. I can give my review more nuance by saying: I vote for inclusion in Boost, but would strongly recommend that the library simplifies the interface AND / OR develops a concept of Converter that is rich enough to include the advanced functionality of the stringstream_based converter.