Gennadiy Rozental wrote:
Adam Wulkiewicz
writes: In general I agree with you but the reality is that currently all (or nearly all?) Boost libraries support c++03 and there are more c++03 test runners than c++11 ones. I do not believe so. By my count about 10 out of 50 are c++03.
I'm not sure what you're counting, probably you're looking at the Test failures here: http://www.boost.org/development/tests/develop/developer/test.html I'm counting the yellow columns here: http://www.boost.org/development/tests/develop/developer/geometry.html Those failures are all caused by the changes in Test, I should rather say "regression". Correct me if I'm wrong but isn't the Test passing in more cases than Geometry only because -std=c++11 flag is defined in a Jamfile: https://github.com/boostorg/test/blob/develop/test/Jamfile.v2#L34 which is altering runners' setups and introducing a bias into the results?
Some of our users cannot move to c++11.
This is the reason why Test should support c++03, isn't it?
Are you saying that the support for c++03 in Test was dropped or will be in the near future? At some near point in a future. I do not have resources to maintain two branches of the library. Older releases are there forever. Anyone interested in c++03 compatible version can download it without ny problems.
Boost libraries authors cannot do that. Are you saying that the regression testing should always use e.g. Test master branch even in develop? I believe it's not that simple. Or that all Boost libraries supporting c++03 should not use Test anymore?
If that's the case shouldn't rather another module e.g. Test2 be created instead? Who is going to support old module? I do not have c++03 compatible setup anywhere. I was thinking about leaving the old Test nearly unmaintained so it could be used by the libraries the same way as in the past. Some of the authors already have choosen to do it (except I'm not sure about the "unmaintained" part) because the new interface of a library was designed (e.g. Signals, Spirit, MPL). And you could work on a new version requireing c++11 in a separate module. And I'm not saying that the entirely new code should be written. You could copy the content of the Test and just build on top of it in this new module.
IMO, we need to make a boost wide decision to stop making c++03 workarounds. 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.
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. Regards, Adam