On 10/5/15 1:20 PM, Gennadiy Rozental wrote:
Robert Ramey
writes: I think a better way to look at Boost is a collection of more loosely coupled software components. The only coupling is to a minimal set of of practices and requirements: Compatiblity with C++, Formal Review, directory structure, and documentation requirements. In this view, there is no place for requiring a specific library for testing, requiring that some particular version of C++ not be supported.
For this we need a process of independent boost.XXX library version-ing and release procedures/schedule.
It's a question of degree. Libraries can be more or less tightly coupled. I one's library development depends heavily on Boost.Test it's coupled to Boost.Test. Otherwise it's not. I would argue that less coupling is better than more coupling and I think the structure of Boost encourages that.
c) I have my whole boost development tree to set to master branch so I'm testing against the next release. Only the serialization submodule is set to develop (or a feature branch).
Unfortunately this is not the way test runners operate
LOL - That's my point exactly. And it is one of the sources of these problems. If things were run the way I suggest, you could make a temporary mistake in development of Boost.Test which wouldn't ripple though to all the libraries which use it for development testing. It would make your life a lot easier.
d) Almost most all code is C++11/C++03 agnostic.
e) Some code is C++11+ specific. This is conditioned with BOOST_NO... macros. Some tests are conditioned on these macros as well.
In few cases this can work out like this. In many other cases maintaining c++03 compatibility can make library obsolete(I am not talking about my library). C++11/C+14 modern C++ code can and *should* look significantly different, with different API and implementation
It makes no economic sense to go back and re-write working code to just because there is a new standard. There is no benefit unless one want's to add features. Some might say that it makes maintenance easier - but this is a decision that only a the library maintainer is qualified to make.
This statement is conditioned on several big IFs IMO, but I am not going to argue.
Hmmm - there aren't any IFS here:
If the author of Boost.Test feels he can't support older compilers, that's his decision of course.
Hmmm - I presume agree with this.
But he should be aware it's going to cut his "market share" and encourage the usage of alternatives.
I doubt anyone would dispute this. Robert Ramey