Subject: Re: [boost] [review] boost::convert
From: Vladimir Batov (vbatov_at_[hidden])
Date: 2011-04-27 21:52:23
> Michael Caisse <boost <at> objectmodelingdesigns.com> writes:
> I don't have an opinion on this library yet but hope to find time for a
> review of it.
Please do. As IMHO if the situation does not improve, the library should not be
considered for inclusion regardless how this current discussion progresses given
how little interest the library generates (which is starkly different from the
time the library was written/submitted).
> In the meantime, I thought I would comment on this statement. Variations
> came up in both the bigint and locale reviews. As I'm sure you know,
> Boost isn't just a collection of libraries. It strives to be a
> collection of "expertly designed" libraries. I don't remember "it is
> useful for some users" as being on the list of reasons to accept a
> library into Boost. Plenty of perfectly usable libraries have been
> rejected over the years simply because it could be better. I don't
> recall "giving everyone nothing" as an argument in the past but it sure
> has become popular recently.
I certainly do see your point and somewhat agree with that. On the other hand,
I favor pragmatism, actual results and gradual improvements over idealism and
idle pondering. That "expertly designed" approach can be viewed in the right
constructive context or instead viewed as elitist and can be too easily abused.
The outcome -- workable, usable, immediately useful but not immediately perfect
(which is relative anyway) libs are rejected at the whim of someone who may not
even need/use that library in the first place. Who wins here? Not the users
anyway. I do indeed appreciate the quality of Boost libs. However, I've never
used Boost libs out of admiration of their "expert design". I used them because
they were/are useful to me.
Consequently, I will take something over nothing any day. Even more so with
regard to convert/lexical_cast as those talks of "improving"/extending
lexical_cast on this list date back at least to 2005. Participants and
maintainers come and go. Talks, lexical_cast and the original lexical_cast
design stay. And in IMHO the author is perfectly entitled to his view and to his
vision. The author's put his name on a certain design and kindly offered it to
others. Some people might disagree with the design and might like to do it
differently. Fine. Go and do it outside lexical_cast. And that's what has been
collectively decided before 'convert' started. I do not believe it is
appropriate to approach it with the attitude -- "Yes, you, balding old man,
thank you for all your efforts but now we'll take over and take it to the next
As for "it is useful for some users", then I do not see anything wrong with
that. In fact, isn't it *always* the case? No library will be useful for every
> In this same thread that you responded to a few weeks back the current
> maintainer stated he no longer has time and is happy if someone else can
> pick it up: ...
Yes, I am aware of that. That situation has not dramatically changed from two
years back when it was decided to proceed with 'convert' -- the author was not
actively maintaining the library and then maintainer Alexander Nasonov was
improving *underlying* implementation. Despite many suggestions extending
interface had never been on the cards. What's changed? Unless now people are
bold enough to say -- we'll take what you've done, we'll keep your name and from
now on we'll do as *we* see fit. Not nice.
> ... if
> the library has no maintainer and the community decides that the best
> approach would be expanding lexical_cast to support these added
> features, then it will happen.
I wonder how you identify the "community". Is it those few who happen to be
currently on the list vocal on the topic? Surely the original author
is part of that community and on many occasions he expressed his view. What do
we do with "inconvenient" views?
Again, that topic of extending lexical_cast had place and resulted in submitting
'convert'. That was not even my idea. I was hoping Alexander Nasonov would do it
all for me ;-) withing lexical_cast. Re-hashing all again that *after* the fact
(the implementation based on our decision back then and subsequent submission)
And, again, the provided by convert functionality/flexibility are not achievable
within lexical_cast single-function interface.
Are there any participants of those old convert/lexical_cast discussions still
on the list to chime in?