Gennadiy Rozental wrote:
Adam Wulkiewicz
writes: I do not believe so. By my count about 10 out of 50 are c++03. I'm not sure what you're counting, I count configuration running c++11 capable compilers. gcc 4.8 is c++11 capable regardless if decide to test in in c++03 mode or not.
Only if by saying "c++11 capable" you have in mind that it has an _experimental_ support of nearly all of the features of c++11. You forget about a fact that the user must want to enable the support for them. There are users which cannot afford compiling the code using an unstable compiler. Which btw means that the runner's setup shouldn't be altered in a Jamfile. If a runner desires to test Boost passing specific compiler flags he should be able to do it. We should at least be honest and say that Test doesn't work if compiled against the default STD version supported by a compiler.
There is no reason to develop new code, which is bound to c++03 compatibility. Anyone interested in old code can use older releases of boost. This is not reasonable since it'd require from the user to manually replace only the Boost.Test code with some older version released in the past or stop using Test. Everything the libraries authors are dealing with now could more or less be an issue for the users. My claim was: there is little reason for user bound to c++03 to upgrade to new version of boost in a first place.
This is so untrue. I don't know how the majority of the industry works but at least in a part I know about the reality looks different than you think. Believe it or not but there are companies which are bound to c++03 simply because they're shipping some major version of a product on a particular OS comming with a specific compiler. And in the same time they want the latest Boost features and bugfixes so they're compiling against develop branch of a library.
By "workarounds", do you mean conditionally-enabled features? You'll always have some workarounds/#ifdefs, if not for c++03 then for c++11, c++14, etc. That's true, but problem grows exponentially once you try to maintain some combination of c++03, c++11, c++14, c++17 (and so on) code. At some point code becomes unreadable and thus very difficult to maintain.
It's obvious that there is an additional maintenance cost when more is supported. To be perfectly clear. I have nothing against Test dropping the support for c++03. It's up to the library author or maintainer what he will do with the library. My point is that this is a breaking change, a regression, and that there should at least be some planning involved, an announcement on the list that the support will be dropped so everyone would be able to prepare accordingly. Preferably a solution for those who don't want to use the new version or at least a clear declaration that there is not and there will be no such solution followed by some period of time when the libraries could drop the Test dependency, at least in those libraries which have a maintainer. Since we already have a rather unpleasant announcement behind us it's a good time for planning and a clear declaration. "I won't fix Test and simply move to c++11" would be ok too. Anything that allows to do some planning. Regards, Adam