mpi_process_group.cpp uses undefined class 'std::list'

[terry lyons <tlyons@…>]

Errors from building boost:

.\boost/graph/distributed/detail/mpi_process_group.ipp(137) : error C2976: 'std::list' : too few template arguments

.\boost/detail/container_fwd.hpp(134) : see declaration of 'std::list'

.\boost/graph/distributed/detail/mpi_process_group.ipp(137) : error C2079: 'boost::graph::distributed::mpi_process_group::impl::sent_batches' uses undefined class 'std::list'

There seems to be a problem where it is impossible to build the mpi components of boost graph etc. because of a lack of definition of list. I have reproduced this with just the file

c:\Program Files\boost\boost_1_60_0\libs\graph_parallel\src\mpi_process_group.cpp.

A forced include of

C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\list

allows error free compilation.

[terry lyons <tlyons@…>]

Attempts to build boost for msvc environments with MS MPI fall down in two places.

One reason is that mpi.jam needs modifying to be aware of current path and environment conventions (there is also a workaround definition needed for an irritating broken Microsoft macro).

Then there are these problems with graph documented above. Adding an include of <list> to mpi_process_group.ipp and added the long list of "std::" includes one finds in mpi_process_group.ipp to mpi_process_group.cpp including <list> (not tested that these latter includes are really needed) fix these errors.

After both changes are implemented boost builds error free on msMPI v7. I wonder how long this has been broken? It seems strange to me as I would have thought that making sure boost worked on the MS stack was important to many people.

It would be good to have this properly fixed. I have uploaded the modified mpi.jam, mpi_process_group.ipp and mpi_process_group.cpp . I hope they are useful.

I should add - when I say error free, I mean error free, as there are plenty of warnings about size_t being converted to int so maybe it still fails on some test!

I realise that this is all written by volunteers and I am very grateful, but I am surprised that one finds these 64/32 conversion errors in mature code such as boost and hope it does not lead to malicious opportunities for denial of service etc. in some loop.