Boost logo

Boost :

Subject: Re: [boost] [serialization][ublas][test] failures in serialization causing regressions
From: Barend Gehrels (barend_at_[hidden])
Date: 2016-11-27 16:24:53

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<T, ALLOC>::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:
>>> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at