Re: [boost] Boost.Convert. Take 2.

Subject: Re: [boost] Boost.Convert. Take 2.
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-02-10 10:23:42

On 2/9/2014 10:58 PM, Vladimir Batov wrote:
>
> Another day I came across a topic called "String to T conversions -
> getting it right this time
> <http://groups.google.com/a/isocpp.org/group/std-proposals/t/a9905ba8e4f33f3e>"
> on the "ISO C++ Standard - Future Proposals
> <https://groups.google.com/a/isocpp.org/forum/#%21forum/std-proposals>"
> that got me interested/curious. Unfortunately, it seemed more of a
> discussion rather than a proposed/deployable solution to the string
> conversion issue. Then, I searched Boost archives to see if there was
> any development in that string-to-type conversion domain since my
> unsuccessful proposal about three years ago:
>
> From: Edward Diener <eldiener <at> tropicsoft.com>
> Subject: [Review] Boost.Convert, review manager analysis
> <http://news.gmane.org/find-root.php?message_id=iq12fm%24k6c%241%40dough.gmane.org>
>
> Newsgroups: gmane.comp.lib.boost.devel
> <http://news.gmane.org/gmane.comp.lib.boost.devel>,
> gmane.comp.lib.boost.user <http://news.gmane.org/gmane.comp.lib.boost.user>
> Date: 2011-05-06 15:01:06 GMT (2 years, 39 weeks, 6 days, 23 hours and
> 47 minutes ago)
>
> Unfortunately I was not able to find anything. Apologies if I missed
> something major/serious (I was not exactly closely monitoring the list).
> Is anyone aware of any work done in the area? If not, then I am thinking
> if we could revisit the issue the original (and failed) Boost.Convert
> tried to address. I am not sure about others but for me that quite
> essential and seemingly simple task is still quite important. I was
> watching the development of the lexical_cast but did not see it going
> beyond its original frugal design. So, maybe we might have another look
> at the code that Boost.Convert has become and that I've been
> using/working on?.. Convert V2... From past experience calling it
> Boost.Convert seems quite premature. :-) I only put Boost.Convert in the
> title as a reminder for those who participated in the original review.
>
> So, the code is at https://github.com/yet-another-user/boost.xtra. The
> docs are old (from the original proposal) so, if anyone interested, I'd
> suggest jumping right to the test/example code in libs/convert/test.
> Apologies for the inconvenience but for now I'll try to see if I should
> put any effort updating the docs for possible submission.

I would strongly suggest updating the docs for the library. Also either 
add in to the new docs the differences between the original version and 
the new version, or just include both the old and new version docs so 
that end-users could easily see what has changed.

I would be glad to be the review manager of the new library, if 
necessary, if you wanted the new library added to the Boost review queue 
once you felt everything was complete. OTOH I would also understand if 
you wanted someone else to be the review manager.

>
> The main difference from the original proposal is that the complicated
> blob was split in to two separate components -- Convert API facade and a
> converter. Here it seems very similar to (same as?) boost::lexical_cast
> which provides a uniform API facade which in turn deploys additional
> functionality (op<<, op>>). Similarly, Convert V2 requires a converter
> to be specified for conversion:
>
>      boost::cstringstream_based_converter ccnv; // char converter
>      boost::wstringstream_based_converter wcnv; // wchar_t converter
>
> Then,
>
>      int a000 = convert<int>::from(not_int_str,   -1, ccnv);
>      int a001 = convert<int>::from(std_str,       -1, ccnv);
>      int a002 = convert<int>::from(c_str,         -1, ccnv);
>      int a003 = convert<int>::from(wstd_str,      -1, wcnv);
>      int a004 = convert<int>::from(wc_str,        -1, wcnv);
>
> Now all the configuration (formatting, locales, etc.) is separate from
> the API facade and provided (or not) by the plugged in converter. The
> only available converter tringstream_based_converter allows something like:
>
>          std::locale rus_locale (rus_locale_name);
>          std::locale eng_locale ("");
>
>          // Set locale, case, precision,
> ccnv(std::setprecision(4))(std::scientific)(std::nouppercase);
>
>          string double_rus = convert<string>::from(double_v01,
> ccnv(rus_locale)).value();
>          string double_eng = convert<string>::from(double_v01,
> ccnv(eng_locale)).value();

Offhand this looks better. As I recall a general criticism was that you 
were trying to do too much in the convert library rather than just 
focusing in on 'convert' as a better, more flexible replacement than 
lexical_cast. Sometimes les is more <g>.

>
> Gosh, it's getting too long... cutting it short. The above is probably
> sufficient for those who participated in the original review. Those who
> did not might have a look at the (original and old) docs and the
> test/example code.