Hi Robert, Op 27-11-2016 om 23:58 schreef Robert Ramey:
On 11/27/16 1:24 PM, Barend Gehrels wrote:
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
Actually I really need to look at this a little more carefully.
Originally boost/serialization/array.hpp was for C++ native arrays. Now it's morphed to be std::array. Over the years stuff got added: fast serialization of bit serializable arrays, c++11 <array>, array_wrapper concept, std::vector, valarray and who knows what else. I'm generally against modification of the interface but do refactor from time to time to deal with all this. And of course this is what happens when people actually start to depend upon the library. As I said, I need to look at this some more - perhaps it's possible / better to adjust the contents of boost/serialization/array.hpp.
For your information: Because it is only in develop and not in master, it is currently not a problem for users. It was inconvenient for us (checking regressions) but luckily there were some columns not affected, and in the meantime I merged to master again and that looks good. Per release 1.64 we, as Boost.Geometry, will stop using Ublas. We currently use it only internally for matrix inversion and products, and will do that with Boost.QVM. That is basically already applied (but not yet submitted), but it is too late for this release, and not necessary because master is OK. Regards, Barend