On 11/3/18 4:21 PM, degski wrote:
On Sat, 3 Nov 2018 at 14:41, Andrey Semashev via Boost
mailto:boost@lists.boost.org> wrote: On 11/3/18 2:47 PM, Cromwell Enage via Boost wrote: > Hello, Andrey. > > It's possible to retain the old code for C++03 compilers. Which ones do > your library users have?
I don't have this data. Boost.Log is documented to support gcc since 4.5 and MSVC since 8.0 SP1. It might be ok to raise the minimum requirement a bit, if it makes it easier to support in Boost.Parameter and other lower level libraries, but switching sraight to C++11 might be big deal for users.
The following question has been asked many times by many posters and there never is an answer: "Those users who want to stick to the old ways of doing things and like to use unsafe compilers [Meltdown, Spectre come to mind], why can't they just use old versions of Boost?"
As it was answered, also many times: because we don't do support releases. Basically, if a bug is discovered, our recommendation is always "use a more recent Boost release". Of course, users can apply patches to their versions of Boost but this is a significant maintenance burden and may not be acceptable to everyone. Having new features and libraries might also be desirable. That the user's code base is C++03 doesn't necessarily mean it doesn't evolve.
There was, as far as I read it, considerable support to at least move to C++11, which is already 2 standards behind the current standard [and is by now fully supported on the main platforms]. Whatever is documented is not relevant, if the docs are out of date, they have to be updated. If every time this kind of question pops up, the answer is, "let's keep backward compatibility", then when are we gonna move to a newer standard? Or to put it differently, a direct question to you Andrey, at which point in time [which new std, 20, 23, 26, 29, 32???] do you think it will be opportune to move to C++11 and break with C++98 [because doing nothing will always be easier]?
If by "move" you mean actively stripping Boost from C++03 support then probably never. But as far as I'm concerned, Boost has moved to C++11 and later as soon as the first C++11 was accepted. At that point in time, the rest of Boost, still compatible with C++03, did not disappear and stayed relevant. C++03-compatible libraries are still a part of Boost and very much relevant, despite how many C++ versions have come out. Specifically for Boost.Log, it already does use some of the C++11 features, when available. And I even think it started doing so before C++11 was finalized. But I still consider C++03 compatibility a plus rather than a minus. On a personal note, I find this "C++11 holy cow" hype quite a pointless waste of breath (or... network bandwidth, I guess). There is no point in dropping libraries on the ground of C++03 compatibility, so that's never going to happen. Boost never rejected libraries that targeted newer C++ versions, that's not changing either. Declaring that we're not testing C++03 compilers anymore might make sense, but we actually do. So I don't quite understand what were the recent discussions about "dropping C++03" about. Just stop debating and start writing some great code, guys! Our users will be only happy. :)
I'm not adamantly against it, not to the point I would rewrite Boost.Log just to stay C++03 compatible. But it would seem that the C++11 requirement is not that necessary in Boost.Parameter either - you can just keep the existing code in C++03 mode it it'll work as before.
I guess, it's always possible to write more code [that's what you ask all maintainers to do] and work around the C++11 specificities?
It's a tradeoff, of course. In some cases, C++11 or whatever might be crucial for the library design or functionality. The particular case with Boost.Parameter doesn't seem to me like one, so yes, I'd *prefer* to keep the compatibility with C++03. If there appears a case that would make keeping the support for C++03 unreasonable (in Boost.Parameter or elswhere), I will accept it and Boost.Log, by induction, will become C++11-only.