Boost logo

Boost :

Subject: Re: [boost] c++03 library survey
From: James E. King III (jking_at_[hidden])
Date: 2018-08-29 03:53:14

On Tue, Aug 28, 2018 at 7:37 AM Mike Dev via Boost <boost_at_[hidden]>

> - Which library/ies are you maintaining? (I assume this isn't some
> sort of private information - otherwise ignore the question)

DateTime, Format, Uuid directly, and by virtue of being on the CMT
assign, concept_check, disjoint_sets, dynamic_bitset, function
interval, iostreams, logic, mpl, pool, property_map
ptr_container, rational, statechart, tokenizer.

> - Would you like to unconditionally use c++11 features if you would
> not have to worry about this breaking boost internal users?
> - Would you like to unconditionally use c++11 features if you would
> not have to worry about this breaking any users?
I think that for CMT repositories, it doesn't matter. Nobody's really
doing any serious refactoring on those and they are all quite old.

I understand that Howard Hinnant is working on a date/time library for
Such a library would eventually replace Boost.DateTime, but it would be so
different that people would continue to use Boost.DateTime. I do plan on
the link library from DateTime at some point and make it header-only. Also
the timezone
handling in DateTime is sub-par and cannot leverage the IANA TZ database
Neither of these things would be affected by switching to C++11.

I've heard a number of projects to make a better Boost.Format, but no
action as of yet that I know of. If something came along, people would
to use Boost.Format because another solution is unlikely to be compatible
the format string syntax anyway.

I don't have any specific proof of this statement, but I suspect that both
and Format would both highly benefit from C++11 and later techniques. As
poor little Uuid, it's fine the way that it is. I don't think it would
benefit significantly
from C++11. C++03 compatible move semantics were just added recently for
example, which leverage Boost.Move and therefore should leverage C++11
when it is enabled. In fact, making a Boost.Format v2 would be a great
- a lot of fun, and would learn a lot - but would require significant time
I don't have.

> - Would you deprecate your library completely if there were no
> boost-internal users and your current dependencies required
> c++11 (e.g. because your library has been merged into the c++11
> standard library anyway)

Looking at how boost::shared_ptr was eventually replaced with
std::shared_ptr, where the two were interchangeable with the same
signatures then I use the following solution: I add a stdcxx namespace
and use namespace forwarding and aliasing to select either boost or
std for a variety of things (mostly in atomic, function/bind, and smart_ptr
This makes the project code oblivious to which implementation is being used.
Selection there depends on language level at build time as well as

I think that in the interest of reducing workload on a project, it sure
would be nice
to say "if you want boost::date_time then use 1.xx or earlier, otherwise
use C++20".
That said, there are likely so many downstream dependencies on
it would be impossible to declare it would be removed in the future. It
would cause
too much work internally in Boost let alone outside Boost.

> - Are you yourself using any boost library (in an up-to-date version)
> in a c++03, non-boost project?
Apache Thrift uses C++03 in the C++ thrift runtime. It's "mostly
based on the above (i.e. ready for C++11) and there have been pull requests
from other folks in the community, however those were never completed and
so the projects still uses C++03.

> - Do you have any Idea if the latest versions of your library is
> used by any important/significant number of c++03 projects?
> [It is only important if *you* consider those projects important
> and or the number significant]
I know that boost::format and boost::uuid are used by a commercial entity
with a C++03 project with plans to move up to something newer, but those
were just plans last I knew.

- Jim

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