Boost :

alexhighviz_at_[hidden]

----
> Vladimir Batov writes
>
>alex <alexhighviz <at> hotmail.com> 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<std::string >::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<class type_in, class type_out, class cnv>
>do_something(type_in in, type_out out)
>{ ...
>    convert<type_out>::from<type_in>(in, cnv);
>}
>
Did you mean:
template<class type_in, class type_out, class converter>
void do_something(type_in in, converter cnv)
{ ...
    type_out out = convert<type_out>::from<type_in>(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<In,Out>
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.