Re: [boost] [Boost-users] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core
On Sat, Mar 5, 2016 at 9:21 PM, Vicente J. Botet Escriba wrote:
Others could be considered also as function.hpp, lambda.hpp and lift.hpp, as the macros are there to workaround some missing language features, but those are much more specialized (Boost.Core?)
Boost.Core is where we move code from existing Boost libraries that enables breaking cyclic dependencies between different Boost libraries. I'm not so sure new libraries will need to (or want to) put code there. Glen
Le 06/03/2016 03:49, Glen Fernandes a écrit :
On Sat, Mar 5, 2016 at 9:21 PM, Vicente J. Botet Escriba wrote:
Others could be considered also as function.hpp, lambda.hpp and lift.hpp, as the macros are there to workaround some missing language features, but those are much more specialized (Boost.Core?)
Boost.Core is where we move code from existing Boost libraries that enables breaking cyclic dependencies between different Boost libraries. I'm not so sure new libraries will need to (or want to) put code there.
You are right for the "reason d'être" if the Core library. IMO, they could be the cause of cycles because most of them are simulation of fundamental missing language features. It is normal that there are a lot of libraries that depend on them. Currently Boost.Config contains other more basic macros [1][2] that could be in Boost.Core also, but this is another history. Vicente [1] http://www.boost.org/doc/libs/1_60_0/libs/config/doc/html/boost_config/boost... [2] http://www.boost.org/doc/libs/1_60_0/libs/config/doc/html/boost_config/boost...
participants (2)
-
Glen Fernandes -
Vicente J. Botet Escriba