On 8/28/18 4:37 AM, Mike Dev via Boost wrote:

=======Please quote from here ======================================

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

- Would you like to unconditionally use c++11 features if you would not have to worry about this breaking boost internal users? There is no value to these features at this point

- Would you like to unconditionally use c++11 features if you would not have to worry about this breaking any users?

- 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)

hmmm - normally I just respond to bug reports. If there are no users there would be no such reports so probably nothing would happen.

- Are you yourself using any boost library (in an up-to-date version) in a c++03, non-boost project?

within the boost serialization library or in other projects? In any case, I just incorporate an std header if there is one, next I select a boost header, and finally I write it myself.

- Do you have any Idea if the latest versions of your library is used by any important/significant number of c++02 projects? [It is only important if *you* consider those projects important and or the number significant]

I have no idea how frequently the boost serialization library is used. I'm sort of thinking it's more than 25 times. But I have not statistics on this. I would love to know this. ==== The one thing that might happen in the future is that BS depends upon some other boost library which gets "upgraded" to C++11 so that BS is no longer compatible with C++03. But this seems unlikely. Boost libraries don't get much maintenance. Once it works and passes all tests, no one messes with it. upgrading working code from C++03 to C++11 isn't going to add any benefit, so there it's more attractive to spend one's efforts somewhere else. Robert Ramey

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

Too many ;) Math, Multiprecision, Regex, Type_traits, Config

- Would you like to unconditionally use c++11 features if you would not have to worry about this breaking boost internal users?

Multiprecision: Builds with 03, but already makes fairly heavy C++11 use, and C++11 or later is really required for full functionality. C++03 support requires little maintenance other than some #ifdef's for rvalue refs etc.  Fairly heavy use of noexcept is also used, but IMO this is an untestable abomination anyway.  Generalised constexpr in C++14 is more useful than C++11, along with really robust SFINAE and enable_if support (in theory this is C++11-ish, but there are many early C++11 compilers which choke on the code, along with more recent C++03 compilers which handle things fine). Math: historically needs nothing that isn't in C++03.  Constexpr support has been gradually added to parts of the library, but is easy to macro-ise around.  Recently, some new components have been added which are more like C++14 as they really need generalised lambdas to work well.  The nicest feature to have would be constexpr-if, but that's C++17. TypeTraits: All the old C++98 cruft is still there, I don't intend to ever change it, and if someone files a bug against say VC7.1, the answer will be "upgrade your compiler".  There are C++11,14 and 17 isms throughout added to support newer features in new compilers. Many traits only work correctly post C++11.  The whole thing could probably be greatly simplified post C++11, but I don't see much gain from going through and ripping out the old code.  For folks that want to read the source, I try to keep the "modern"/conforming implementation first in the file, at least in new code. Regex: was obviously designed when C++98 was still being formulated ;)  Rvalue refs are the only C++11 feature that's nice to have, other things like C++17's string_view support will gradually get added in time no doubt.

- Would you like to unconditionally use c++11 features if you would not have to worry about this breaking any users?

Not especially, though I dare say I would just to save a few #ifdef's in new code.

- 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)

No.  While regex is in the std, I believe Boost.Regex continues to offer useful enhancements. Type_traits is an interesting one - if people stop using it, then deprecation might be an option.

- Are you yourself using any boost library (in an up-to-date version) in a c++03, non-boost project?

No.

- Do you have any Idea if the latest versions of your library is used by any important/significant number of c++02 projects? [It is only important if *you* consider those projects important and or the number significant]

No.  Generally I get more bug reports relating to very recent C++ versions that I haven't quite caught up with yet.  Of course these are mature libraries, so the C++03 side of things should be pretty stable. HTH, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

On Tue, Aug 28, 2018, 14:37 Mike Dev via Boost wrote: <...>

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

Any, Conversion, DLL, LexicalCast, Stacktrace, TypeIndex, Variant. - Would you like to unconditionally use c++11 features if you would

not have to worry about this breaking boost internal users?

This could be usefull for Variant - it will make the library slightly smaller and well maintainable. But not much better. - Would you like to unconditionally use c++11 features if you would

not have to worry about this breaking any users?

Same as above. - 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)

Not for c++11. - Are you yourself using any boost library (in an up-to-date version)

in a c++03, non-boost project?

No. - Do you have any Idea if the latest versions of your library is

used by any important/significant number of c++02 projects? [It is only important if *you* consider those projects important and or the number significant]

There are plenty. =======Please quote till here ======================================

Actually, I'd like to go further than you propose. There's a plenty of request to use C++17 classes in the Boost libraries I maintain. So my idea is to start a new fork/branch of Boost that requires C++17 compatible compiler. This will allow library developers to use modern features, experiment with them and invent cool things. This will allow me to drop Any and Variant. This will also allow me to * significantly improve/rewrite LexicalCast and drop the std::locale dependency that insanely slows down the runtime * implemet a DLL library that uses std::filesystem::path and std::system_error without unnecessary dependencies on Boost For the remaining libraries I'll be able to drop Config, TypeTriats and some other dependencies. This will improve compile times and reduce LOC to maintain. Best regards and thank you for your time

Mike

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

El 28/08/2018 a las 13:37, Mike Dev via Boost escribió:

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

MultiIndex and Flyweight (I also maintain PolyCollection, but this is C++11 from scratch).

- 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?

Yes. But I find these questions slightly misleading: If I don't have to worry *at all* about the consequences of using something, of course I'd be willing to use should it come handy. In practice, I fix bugs and add features respecting the C++03 baseline because I *do worry* about breaking my users. If something can't be written or it's too hard to emulate in C++03, I do it in C++1x and guard the code for backwards compatibility (for example, see https://www.boost.org/doc/libs/develop/libs/multi_index/doc/tutorial/key_ext... ).

- 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)

If any of my dependencies upgraded to require C++11+ I'd make an effort to replace it or, if the dependency is isolated within one particular feature, guard this feature to protect C++03 users and move on. If the thing became unmaintainable then I'd be forced to require C++11 myself: in practical terms, I see this scenario quite unlikely. My dependencies are: assert bind config container_hash core detail foreach integer interprocess iterator move mpl parameter preprocessor serialization smart_ptr static_assert throw_exception tuple type_traits utility which are either basically frozen (bind, foreach, mpl, preprocessor, etc.) or are designed with backwards compatibility in mind (move, config). From time to time I find a dependency has broken in an old compiler (e.g. MultiIndex currently breaks in MSVC 7.1 due to a problem with Integer: https://tinyurl.com/yavmhudg ). If the compiler is really really old I usually do nothing except when some actual user files a ticket.

- Are you yourself using any boost library (in an up-to-date version) in a c++03, non-boost project?

No.

- Do you have any Idea if the latest versions of your library is used by any important/significant number of c++02 projects? [It is only important if *you* consider those projects important and or the number significant]

I maintain a private record of projects/companies using MultiIndex that currently has ~300 entries, including, to drop some names: PowerDNS, CERN, Industrial Light & Magic, Autodesk, Amazon, MongoDB, Adobe, Baidu, BMW, Apple, Bitcoin. I assume real figures can be easily much higher (these are only projects I found on Internet). I don't know for sure, but I'd be surprised if all/most of these guys have already migrated their codebases to C++11. I don't know if they stick to an older version of Boost or regualrly update. For Flyweight I see very little use. Best regards, Joaquín M López Muñoz

On Tue, Aug 28, 2018 at 6:37 AM Mike Dev via Boost wrote:

=======Please quote from here ======================================

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

Boost Predef (and Boost Build, but that's not a library)

- Would you like to unconditionally use c++11 features if you would not have to worry about this breaking boost internal users?

No.

- Would you like to unconditionally use c++11 features if you would not have to worry about this breaking any users?

No. - 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)

No. - Are you yourself using any boost library (in an up-to-date version)

in a c++03, non-boost project?

No. - Do you have any Idea if the latest versions of your library is

used by any important/significant number of c++02 projects? [It is only important if *you* consider those projects important and or the number significant]

Yes. It's used by many Boost libraries (directly and indirectly). And it's used by a variety of external projects. I don't know what versions of C++ they use though. Especially since Predef supports C++ < 98, and C, and Objective C, and Objective C++, and CUDA.

=======Please quote till here ======================================

Yes, I realize this is an outlier data point. But it is data :-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net