OK. It makes sense, that the multi_array expects its values to be copy-constructible. Still I would like to use the intrusive list since this part of algorithm is particularly sensitive to cache locality issues and I cannot lose the multi_array interface - stuff like views for example - because I already use it everywhere.

I know, I'm not going to copy the lists contained in the multi_array. Any ideas how to get an intrusive list inside the multi_array?

I can only think of implementing the intrusive list myself usin plain old pointer and reimplementing parts of STL-like interface. But it seems like a long path...

What about inheriting a class from intrusive list, providing a false copy constructor (which would i.e. throw an error when called to be safe)? Would something like this be possible?

Ah, evidently boost::multiarray expects its value_type to be copy-constructible (at least), which Boost.Intrusive data structures are not [1]: "Boost.Intrusive containers are non-copyable and non-assignable." Also explains the failure of std::vector< boost::intrusive::list >, too, in C++03 mode. In C++11 mode, I guess std::vector (and similar) are able to fall back to using the move constructors and assignment operators of the Boost.Intrusive data structures.

- Jeff

[1] http://www.boost.org/doc/libs/1_52_0/doc/html/intrusive/intrusive_vs_nontrusive.html
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users