Boost logo

Boost :

Subject: Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-05-14 18:13:02

On 5/14/17 7:56 AM, Niall Douglas via Boost wrote:

> Apparently some years ago they were common enough in submitted new Boost
> libraries, and indeed some internal sublibraries went on to later become
> Boost libraries in their own right.
> We should proceed here with the Outcome review the same way as it was
> with those preceding cases. Whatever the precedent is.
> (I'm not sure what the exact precedent is, whomever knows for sure
> please speak, but be aware that most of the dependency on boost-lite is
> substitutable for Boost proper)

I can't say I know for sure, but I do have some experience with this.

While creating the serialization library, I depended on existing boost
solutions to the extent possible. MPL, config, spirit and I'm sure a
bunch of others I don't remember. Someone else later added file_system
and system to the tests. So there is, was and always will be a strong
dependency between the serialization library and the rest of boost.

Still I needed some stuff that didn't exist: extended_type_info,
composable dataflow iterators, BOOST_STRONG_TYPEDEF, singleton,
state_saver, BOOST_STATIC_WARNING. I created them as "private
libraries" in order to keep the development effort within bounds. It's
much easier to build and maintain a library as the composite of 10
smaller otherwise decoupled components than try to understand things as
a whole. I also looked forward when some of these "private libraries"
might get promoted to being boost libraries in their own right. What
actually happened was:

a) I tried to put these in boost namespace as they were not really part
of the serialization library itself. I caught hell for this from an
important booster who is now no longer involved in boost. So I moved
them below the serialization namespace.

b) a number of these "private libraries" got adopted for general usage
such that I get bug reports related to usage outside the serialization
library. These include dataflow iterators, strong typedef, and singleton.

c) a number just didn't work out - BOOST_STATIC_WARNING could never
really be made to work across all platforms. BOOST_STRONG_TYPEDEF fell
out of use in the serialization library due to evolution in
understanding on my part - but continues to be used.

d) a number got supplanted by real boost libraries - though I didn't
update the serialization library to use them. Type index is similar to
extended type info. We now have a component for dealing with unicode
(which hasn't worked for me BTW). We now have boost.ranges which looks
to me to replace dataflow iterators

One key component doesn't fit the above - boost::utf8_codecvt written by
ron garcia many, many years ago. He must have done a good job as it
seems to be the only reliable implementation of this much needed
facility. This was one of the components I wanted to add to the boost
root but was prohibited from doing so. It was shared between several
libraries so it wasn't a good idea to put it under serialization. But
being in boost detail there was no place for tests - which was pretty
important since may standard libraries had quirky behavior in this area.
While no one was looking, I snuck in a test somewhere which helped but
we're still #including the source into other libraries because
utf8_codecvt was never "officially reviewed". This will be an ongoing
saga since <codecvt> is now being dropped from the standard for being
unreliable - oh well.

So that short story describes my experience in this area - I don't know
if it explains anything though. Make of it what you will.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at