On 7 April 2018 at 09:58, Vicente J. Botet Escriba via Boost wrote:

Le 25/03/2018 à 11:18, Antony Polukhin via Boost a écrit :

...

Hello,

I've noted that many libraries depend on container_hash while it depends only on a single header from Boost.Detail library https://pdimov.github.io/boostdep-report/master/module-levels.html

Can we move "boost/detail/container_fwd.hpp" into Boost.Core or into Boost.ContainerHash? This will break the circular dependency, move the Boost.ContainerHash on level 4 and improve levels of Intrusive, Container, CircularBuffer, Unordered, Algorithm, Test, TypeIndex, Any, Function, Functional, ScopeExit, Signals, MultiArray, Variant.

Yes, please, move it to a specific Boost.ContainerHash.

I don't mind having more components, if we reach to manage better the dependencies.

IMO the problem is that detail depends on MPL. It really shouldn't be an expensive dependency, and shuffling things around is just causing extra complication while avoiding dealing with the real problem. Most uses of MPL can be replaced with more lightweight functionality. I think the only exception is the support for MPL lambdas which I don't think is necessary. I haven't checked but there's a decent chance they're not used at all in Boost (and since it's detail they aren't for public use), and I don't think the workarounds are required for any of the compilers in use nowadays anyway.

On 7 April 2018 at 13:53, Antony Polukhin wrote:

In that case I'd love to see both changes: * dropping circular dependency container_hash <=> detail * dropping dependency of detail on mpl

With both changes much more libraries improve in dependency levels.

Isn't the circular dependency because of the dependency on mpl? container_hash -> detail -> mpl -> utility -> iterator -> fusion -> container_hash It won't break over circular dependencies though, e.g. mpl and utility depend on each other.

Daniel James wrote:

IMO the problem is that detail depends on MPL. It really shouldn't be an expensive dependency, and shuffling things around is just causing extra complication while avoiding dealing with the real problem. Most uses of MPL can be replaced with more lightweight functionality.

This looks doable, the problem is that the Detail components that use MPL have no tests, so it won't be easy to determine whether the changes break something.

Daniel James wrote:

We can write tests if needed, but it won't be hard to work out which modules use the various parts of detail, so we can track their tests.

It's not hard, I agree. :-) C:\boost-git\develop>dist\bin\boostdep.exe boost/detail/is_xxx.hpp Inclusion report for (in module detail): from parameter: from python: C:\boost-git\develop>dist\bin\boostdep.exe boost/detail/is_incrementable.hpp Inclusion report for (in module detail): from icl: from iostreams: from iterator: and so on.

On 07/04/2018 15:24, Daniel James via Boost wrote:

We can write tests if needed, but it won't be hard to work out which modules use the various parts of detail, so we can track their tests. Several headers are only used by one to two libraries.

Another, possibly better, solution is to not use container_fwd.php. It doesn't do any good for libc++ and libstdc++ because of the way they use namespaces for versioning.

It's possible to handle that. I think forward declaration of those containers might be possible and really useful. Pulling a std header is really hard. The main problem is that in some libraries some elements are in the std namespace and others in the inline namespace. An example using std_ns_begin.hpp/std_ns_end.hpp forward declaring some STL utilities: https://github.com/boostorg/container/blob/develop/include/boost/container/d... It's a hack, but a really useful one if you don't want to pull half STL when writing a simple header. Ion

On 08/04/2018 14:49, degski via Boost wrote:

Isn't this "hack" actually specifically dis-allowed by the standard? (don't seek to discuss it, just a question)

Yes, it's disallowed. But since: -> We have a problem. -> There is no portable solution. -> There is are different solutions that cover nearly all platforms. ...a library in Boost dealing with this might be a good idea. Just like we had threads long before the standard allowed them and we have coroutines before the standard allows it. Best, Ion