On Tue, Aug 28, 2018 at 7:37 AM Mike Dev via Boost
- 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