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
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?

I suppose it would be possible to either inherit (most hacky) or otherwise wrap an intrusive list and give it a "false", unconditionally throwing copy constructor, as you suggested. You can also wrap all your intrusive lists in shared_ptr (easiest) or use a multiarray of bare pointers to intrusive lists (as long as you manage their lifetime outside the multiarray). The best and correct solution, of course, is to update Boost.Multiarray for C++11, but that requires the most work :/