I would like to add something here if I may.
Those changes in dependencies between the several boost libraries can make
it a lot harder to upgrade to a new release once it becomes available. I
have a rule to always do that in order to avoid long term tech debt.
So to have myself as an example, I usually have to patch new releases. At
th every least Preprocessor, which I need to downgrade to 1.49's version
because Incredibuild doesn't work properly with higher versions. Sometimes
other libs because of specific problems or bugs.
Now this in turn often forces me to downgrade or modify libs that are
dependencies and those that are dependent. And there's the catch. It can be
hard to figure out which exactly those are. If that changes so much between
the releases this has to be done every time, defeating the purpose of the
whole exercise.
If I consider the release as an entity that I only need to plug and play
(which would be the case in an ideal world) I wouldn't care much about the
interdependencies among the submodules. Personally I would prefer heavy
reuse among them to reduce bugs. But since above modifications are sadly
regular practice for me I prefer transparent and clean dependencies.
Just my 2 cents,
Stephan
On Wed, Jan 7, 2015 at 7:55 PM, Peter Dimov
John Maddock wrote:
So.... what is the minimal compiler requirement to be?
Same as today's. I don't think that any Boost-supported compiler has trouble with simple C++03 SFINAE.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost