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

Subject: Re: [boost] Boost.Convert. Take 2.
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-02-10 13:12:45

2014-02-10 4:58 GMT+01:00 Vladimir Batov <Vladimir.Batov_at_[hidden]>:

>
> 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.
>

Hi Vladimir,
I never participated in the original review, so pardon me if what I bring
up was already addressed or dismissed.

There are at least two reasons why I would prefer your library to
lexical_cast. First, it lets me customize the locale, which I was always
missing. Second, it doesn't force me to throw exceptions (and make the
program go slower, if I just want to test if my string is convertible to
int).

But there are two reasons, that discourage me from using the library: first
that it "pretends" it returns my T, whereas in fact it returns a wrapper
convertible to T. Users will get a lot of surprise, when they try to write:

auto my_str = convert<std::string>::from(1, ..);
my_str.size();

Also, I am likely to select an incorrect function overload, if I pass the
result to the function template.

Second thing that bothers me is that for the result type to be able to
offer all these checks an otherwise unnecessary runtime overhead is
imposed. 'result' stores both optional<T> and a flag indicating how to deal
with the lack of value. since, in order to write into T you need to
default-construct it anyway (or move construct it), it looks it should be
enough to have 'result' contain a non-optional T and  more sophisticated
flag that also stores the information about having a real T.

I would like to suggest two things:

1. Would it not be possible to have an overload that does not take the
stream object? It would mean we want to use some default char-based stream
with any locale. The newbies would not have to bother with what it is, when
they only want to convert an int to a string?

2. Would it be possible to consider returning tr2::optional instead of
'result'? It is different than boost::optional in a couple of aspects.
After a lots of changes, the
final shape of it is here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html and the
reference implementation is here: https://github.com/akrzemi1/Optional

tr2::optional offers 4 ways of dealing with the missing (unset) value:
First: if (rslt) use (*rslt); // check it manually
Second: use (rslt.value_or(1)); // use default value
Third: use (rslt.value()); // throw if no value
Fourth: use (*rslt); // use without checks

the fourth result is not to be underestimated. Sometimes I am sure my int
will successfully convert to a string, and I do not want to pay the price
for an extra check.

Returning an optional would somehow separate responsibilities: conversion
function only converts, and optional is a well-understood general-purpose
wrapper for dealing with a potentially missing value.

I am pretty sure we could adapt boost::optional to tr2::optional's
interface.

Or are there reasons not to use optional?

Regards,
&rzej