Closed awulkiew closed 5 years ago
It seems that it doesn't have to be x64 mode, it also fails with msvc-12 in x86 mode e.g.: https://www.boost.org/development/tests/develop/developer/output/teeks99-09-m-win2012R2-32on64-boost-bin-v2-libs-geometry-index-test-rtree-interprocess-rtree_interprocess_rstar_dyn-test-msvc-12-0-dbg-async-excpt-on-thrdp-wn32-thrd-mlt.html surprisingly this test passes with msvc-10 and 11.
FYI, I modified the code by replacing resize()
with ctor so these errors will probably disappear.
No idea of what the problem might be. If you provide me a simplified test I could try to understand how MSVC 10-12 does not like the code
After heavy digging I was able to write a simple failing test. There are some specific conditions for the error to happen. I tried to simplify the code and destille the problem as much as I could. However the limit here is Container and Variant interface. I suspect it's possible to simplify it even more by checking the internals of both libraries. I hope the code below will at least make your day. ;)
#include <boost/container/vector.hpp>
#include <boost/variant.hpp>
// conditions:
// sizeof(foo) == sizeof(bar)
// same number of members
// memory model doesn't matter
// both variant must be created and vector::resize() called
struct foo
{
void * a;
};
struct bar
{
// float a; // error with x86
double a; // error with x64
};
int main()
{
boost::variant<foo> root; // without it ok
boost::container::vector<bar> vec;
children_contents.resize(0); // without it ok
}
Actually I found a fix for this. It seems that the compiler tries to instantiate boost::aligned_storage
instead of boost::container::dtl::aligned_storage
in this specific case. The former doesn't have data
member variable, it has address()
member function. So it can be fixed or rather worked around by prefixing aligned_storage
with dtl::
namespace.
Side question, why are you using your own aligned_storage
? AFAIU the "common" one is not a big dependency and it's used in container::node_handle
anyway.
Closing the issue after merging:
https://github.com/boostorg/container/commit/28e8d6da78a163d71390eb1b8b16724495013529
Detected in Geometry R-tree tests. See https://www.boost.org/development/tests/develop/developer/geometry-index.html for msvc-10..12 x64 on x64, e.g.: https://www.boost.org/development/tests/develop/developer/output/teeks99-09-m-win2012R2-32on64-boost-bin-v2-libs-geometry-index-test-rtree-interprocess-rtree_interprocess_rstar_dyn-test-msvc-12-0-dbg-async-excpt-on-thrdp-wn32-thrd-mlt.html
For convenience, the error is:
The
vector::resize()
is called in the R-tree here: https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/index/detail/rtree/rstar/choose_next_node.hpp#L83container_from_elements_type
is defined here: https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/index/detail/rtree/node/node_elements.hpp#L97 and is simplyboost::container::vector<child_contents>
Elementchild_contents
isboost::tuple<size_t, double, double>
.I tired with type different than
boost::tuple<...>
but of the same size (tuple elements as members), the result is the same. However synthetic test, so creating a vector of elements of the same size and alignment and resizing it outside the R-tree code passes. Funnily enough (in the R-tree) creating a vector of desired size with ctor instead of creating wieh default ctor and resizing it works, so instead of this:this:
I'll try to prepare a limited/synthetic case for this issue but in the meanwhile maybe do you have an idea why this may be the case?