alex <alexhighviz <at> hotmail.com> writes:
Vladimir Batov writes alex <alexhighviz <at> hotmail.com> writes:
... Alex, Thank you for your email, continuous involvement and suggestions. It's much appreciated. I took the liberty re-arranging our conversation... mostly for selfish reasons ;-) -- 1) the inlined replies were getting difficult to follow and 2) later it'll be easier for me to address a "bulleted" (as below) TODO list. Apologies if I managed to miss any of your points. Vladimir. RE#1: 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. REPLY: Thank you for voting for inclusion and for stating that you find the library useful (at least potentially). It's much appreciated. I whole-heartedly agree that we neeed a rich and advanced stringstream_based converter. In practice that happens to be my main converter as well (conversion performance is not a priority for me). Extending this particular converter is close to the top on my TODO list (the usual caveat: if the review successful). However, I'll need to gather user input/requirements what is the preferred interface, etc. Namely, I was leaning away from using the std manipulators (and was providing an alternative api) but you found it useful. So, now I feel we should be providing both interfaces. TODO: Provide "rich and advanced" stringstream_based converter. RE#2: Basic things that I would expect from a *generic* converter are not offered by the Convert library. REPLY-PART#1: Clearly there is no code that would satisfy every user's need. Far from it. *Currently* we are at the "consideration/evaluation" stage to see if that is the correct/valid/promising/sustainable *path* to go ahead and to implement all those bells and whistles. REPLY-PART#2: Well, the thing is -- there is no *generic* converter. More so, in my view there is no even Convert "library". :-) I see my proposal as a conversion/transformation *framework*. The difference between a library and a framework (in my view and in this particular case, anyway) is that the latter is merely the guidelines how to be able to develop code *later* that is to be deployed in and without disrupting the old/existing code. That's what convert::from API facade does. On its own it provides very little (if any) functionality. Its (sole?) purpose is to advertize and to force a *contract* between the user (service consumer) and the converter developer (service provider). That allows the user to write his domain-specific code *now* and to plug some converter later (when it becomes available) or to replace one converter with another (if/when the requirements change) without major disruption of the existing code-base. As you correctly pointed out one-particular-converter functionality can be called directly rather than via "meaningless" convert::from. The existence of Convert API facade is more for the purposes of *managing* a large development which includes *simultaneously* writing components which are meant to interact or rely on each other; adjusting to requirement changes without major existing code disruption (that includes major re-writes, major re-testing, etc.). That's why to this point I am not exactly sure if such an "administrative" proposal really belongs in Boost where it is overwhelmngly about clever code. RE#3: too much lexical_cast-related paranoia and too many lexical_cast references in the "convert" documentation. TODO: Focus documentation of "convert", create a separate lexical_cast-comparison-related chapter. RE#4: 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(); JUSTIFICATION: It's not compiling because applying std::stringstream to such a trivial type transformation is wasteful. TODO: Add "char const*->std::string" transformation specialization to sstream-based converter. RE#5: 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. REPLY: The statement above is incorrect. The default-constructible requirement was actually the main reason I was forced to stop using lexical_cast and to develop "convert". Please read "The Default Constructible Type Requirement" chapter. RE#6: 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". ANSWER: In the documentation it is called "callable". I am sure it is a fairly standard name, isn't it? TODO: Extend/elaborate the "Converters" chapter. It purpose/requirements. RE#7: Did you mean:
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); }
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); } REPLY: It was merely an example where one might need a generic interface to be able to plug in some functionality later. A converter can be passed in as in your example... or as a template parameter: type_out value_out = do_something<type_in, type_out, converter>(value_in) Clearly my chosen order of template-type arguments can be improved to allow for type deduction.