Re: [boost] [review] boost::convert

Subject: Re: [boost] [review] boost::convert
From: Vladimir Batov (vbatov_at_[hidden])
Date: 2011-04-27 19:07:13

> Jeroen Habraken <vexocide <at> gmail.com> writes:
> ...
> Do you have a link to this discussion (if it was on a mailing list),
> I'm curious as to how this decision was reached?

The discussions that I participated in were over two years back. I am pretty
sure similar discussions/suggestions were well before that. So, no, I do not
have those links but you can search for convert/review/lexical_cast/my name. 

>> ... I thought
>> convert<int>::result does what you are seemingly trying to achieve with
>> boost::optional.
> 
> They seem to provide the same functionality but using
> boost::convert<int>::result when you need a boost::optional<int> in
> the end doesn't make sense. Can boost::convert<>::result be replaced
> by boost::optional?

They, indeed, seem to provide *similar* functionality. In fact, convert::result
*uses* boost::optional. If you have a look at convert::result (it's quite
small), then everything else in addition to boost::optional is what
convert::result adds. In words, IMHO convert::result is better than
boost::optional tailored for its domain (conversions).

> ...
> Eric Niebler argued that bad template errors are a library bug (see
> http://cpp-next.com/archive/2010/09/expressive-c-why-template-errors-suck-
> and-what-you-can-do-about-it/)
> and I agree with him, this should be fixed.

Regardless of the outcome with the proposed library I'll read the article as
indeed it seems quite interesting (I actually thought there was nothing we could
do about those cryptic and lo-o-o-ong template-related error messages). Thanks.

> As you say this is a solution to your problem, not the problem that
> boost::lexical_cast has which should ultimately be addressed by
> someone. I'll have a look in the archives (do you happen to have a
> link?).

Let me clarify. It's not *my* problem -- I have no problems. That's a problem
of a project or projects that need to make extensive use of the functionality
that 'convert' provides and lexical_cast does not.

> I'm not saying your library doesn't solve a problem for users, it
> definitely does. However, it isn't the optimal solution in my opinion.

"Optimal" is a subjective thing. For one speed comes first, for some others
richness of the interface is more important. For the projects that I am involved
in the existing std::stream-based performance is a non-issue and locales and
formatting are crucial. In other words, if something does not immediately match
your interpretation of "optimal", it's not a good reason to discard it yet
(obviously only if one stops looking at things from his-only molehill and
starts taking other-peoples needs into consideration).

What I am trying to say is that with 'convert' I am trying to give some users
*something* and to keep working to satisfy the needs of the remaining users who
need more. You, on the other hand, seem to prefer rejecting 'convert' outright
and giving everyone nothing. Do you really think it is constructive or
beneficial for anyone?

> Other approaches have been mentioned (see this thread for example,
> http://lists.boost.org/Archives/boost/2005/04/84296.php) 

You are teasing me, right? :-) Let me quote the link you provided -- "... a
feature request, though: the ability to use a default value rather than
throwing an exception on conversion failure. Basically, it would take a second
argument that would be the value returned if the conversion fails."

Isn't it the functionality that 'convert' *at very long last* provides? The
example below is from the "Getting Started" section

#include <boost/convert.hpp>
using boost::convert;
int i1 = convert<int>::from(str); // Throws if the conversion fails
int i2 = convert<int>::from(str, -1); // Returns -1 if the conversion fails

> but were
> rejected by the original author because he felt it should look like a
> cast. 

Exactly. How many times do you need to be told that lexical_cast is
closed for business and you should go and look someplace else? Instead, you
behave like a spoiled child who simply refuses to accept things as they are and
keeps nagging parents for something he won't get.

> Since he has abandoned the library I believe it is time for
> someone to step up and take it to the next level. 

How well are you qualified to make statements of that sort? Have you actually
talked to the author? Or is it merely your impression, opinion, etc? My take of
the situation is different (after I talked to the author and the then
maintainer, endured many days of discussions on the list, went through the pain
of actually reimplementing what was seemingly within the reach in the form of
lexical_cast). So, my take of the situation is that the author is of an opinion
that lexical_cast is *complete* as far as the original design envisaged by the
author is concerned and, therefore, lexical_cast is closed for extension
business. The fact that you might disagree with that opinion does not
immediately give you rights to "take over" and to "take it to the next level".
Your "next level" might not be someone else's "next level" and seemingly not
the author's "next level". Deal with it.

>> As for lexical_cast "can not be deprecated or worse, removed", then I used to
>> use lexical_cast a *lot*. I do not use it anymore and my world did not
>> implode. The reason -- it does not do what I need it to do. Therefore, the
>> impact of deprecating lexical_cast might not be as disastrous as you might
>> imagine. Things are being deprecated every day -- vinyl records, magnetic
>> tapes, CDs, (long list follows) -- it's called progress. 
> 
> This analogy doesn't hold, a vinyl or CD can't be adapted to meet new
> or extra demands, boost::lexical_cast on the other hand can.

Of course the analogy holds. You indicated lexical_cast could "not be deprecated
or worse, removed". I argued that *everything* is "depreciable". Could anyone
imagine in my happy days that a computer mammoth like DEC will be deprecated,
decimated, annihilated by a "printer" company? :-)

Have a great day,
V.