Hi Robert, Op 27-11-2016 om 3:03 schreef Robert Ramey:
On 11/26/16 5:23 PM, Robert Ramey wrote:
On 11/26/16 1:31 PM, Barend Gehrels wrote:
The regression matrix in develop of Boost.Geometry contains many new > compilation failures due to:
1) : D:\t08\run\boost_root\boost/serialization/array.hpp(25) : error C2039: 'array' : is not a member of 'std'
2): ../boost/numeric/ublas/storage.hpp: In member function ???void boost::numeric::ublas::unbounded_array
::serialize(Archive&, unsigned int)???: ../boost/numeric/ublas/storage.hpp:331:18: error: ???make_array??? is not a member of ???boost::serialization??? ar & serialization::make_array(data_, s);and a The master is still OK.
Can this be solved?
Ping! This is still the case! Robert, can you explain this?
It is (of course) not only geometry failing, also ublas or (if there are) other libraries with ublas dependencies: http://www.boost.org/development/tests/develop/developer/numeric-ublas.html
All yellow!
It looks to me that these test are using std::array and the compiler is not supporting C++11+
I don't think this has anything to do with the serialization library.
OK - I've looked at this a little bit.
I made adjustments to more easily support all C++ compilers from C++98 to C++14 + and to factor common code from vector, valarray, native arrays, and who knows what else. One of the things this entailed was to put the implementation of an "array_wrapper" in a separate file. This is more general than the concept of an "array". It also includes the definition of "make_array" which perhaps should be called make_array_wrapper.
So I think the best would be for ublas / storage to replace
#include boost/serialization/array.hpp
with
#include boost/serialization/array_wrapper.hpp
A word of caution - I'm actually not quite done with this but I don't think the array_wapper concept/definition will change so I think it is safe to make this change. Unfortunately, this will mean that serialization and ublas will have to be merged to the master at the same time. I realize that this is not ideal - but still ...
Thanks for investigating. Your advice to replace it in ublas looks good - however, I don't know who is responsible for it and if it will be done on short term. Maybe we can prepare a PR for them. And indeed, then we have the merge problem. Are there people from Ublas on the list? I modified the subject to draw more attention. Regards, Barend