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]>
wrote:

>
> - 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
C++20.
Such a library would eventually replace Boost.DateTime, but it would be so
radically
different that people would continue to use Boost.DateTime. I do plan on
removing
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
properly.
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
standards
action as of yet that I know of. If something came along, people would
continue
to use Boost.Format because another solution is unlikely to be compatible
with
the format string syntax anyway.

I don't have any specific proof of this statement, but I suspect that both
DateTime
and Format would both highly benefit from C++11 and later techniques. As
for
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
project
- 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
areas).
This makes the project code oblivious to which implementation is being used.
Selection there depends on language level at build time as well as
environment.

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
boost::date_time
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
abstracted"
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk