[Boost] [Interprocess] Use of Boost.Move in interprocess affecting causing compilation errors with 1.46

Hi all, I'm having a problem compiling some code with boost 1.46 that was compiling fine with 1.36 to 1.43 (or thereabouts). It appears that this is somewhat related to the use of Boost.Move in the Boost.Interprocess library. I have tried to read up a bit on Boost.Move, but have failed to quite understand what of it applies to me. Here is a small piece of code that will cause the compilation error (explanations below): ---------------------- #include <boost/interprocess/ containers/vector.hpp> #include <boost/interprocess/containers/string.hpp> #include <boost/interprocess/managed_shared_memory.hpp> typedef boost::interprocess::basic_string < char, std::char_traits<char>, boost::interprocess::allocator < char, boost::interprocess::managed_shared_memory::segment_manager >
ShmString;
class A { #if 0 public: A(const A&); A& operator=(const A&); #endif private: #if 1 ShmString m_name; #endif }; typedef boost::interprocess::vector < A, boost::interprocess::allocator < A, boost::interprocess::managed_shared_memory::segment_manager >
AVector;
class B { public: void AddA(const A & a) {m_as.push_back(a);} private: AVector m_as; }; ---------------- g++ 4.4 compilation errors: ---------------- In file included from /usr/include/c++/4.4/memory:49, from /home/lars/boost_1_46_0/boost/interprocess/containers/container/vector.hpp:23, from /home/lars/boost_1_46_0/boost/interprocess/containers/vector.hpp:19, from mfp.cpp:1: /usr/include/c++/4.4/bits/stl_algobase.h: In static member function ‘static _OI std::__copy_move<false, false, std::random_access_iterator_tag>::__copy_m(_II, _II, _OI) [with _II = boost::container::constant_iterator<A, long int>, _OI = A*]’: /usr/include/c++/4.4/bits/stl_algobase.h:397: instantiated from ‘_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false, _II = boost::container::constant_iterator<A, long int>, _OI = A*]’ /usr/include/c++/4.4/bits/stl_algobase.h:436: instantiated from ‘_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false, _II = boost::container::constant_iterator<A, long int>, _OI = A*]’ /usr/include/c++/4.4/bits/stl_algobase.h:468: instantiated from ‘_OI std::copy(_II, _II, _OI) [with _II = boost::container::constant_iterator<A, long int>, _OI = A*]’ /home/lars/boost_1_46_0/boost/interprocess/detail/move.hpp:1105: instantiated from ‘F boost::interprocess::copy_or_move(I, I, F, typename boost::disable_if<boost::interprocess::move_detail::is_move_iterator<I>, void>::type*) [with I = boost::container::constant_iterator<A, long int>, F = A*]’ /home/lars/boost_1_46_0/boost/interprocess/containers/container/detail/advanced_insert_int.hpp:53: instantiated from ‘void boost::container::containers_detail::advanced_insert_aux_proxy<T, FwdIt, Iterator>::copy_all_to(Iterator) [with T = A, FwdIt = boost::container::constant_iterator<A, long int>, Iterator = A*]’ mfp.cpp:46: instantiated from here /usr/include/c++/4.4/bits/stl_algobase.h:343: error: no match for ‘operator=’ in ‘* __result = __first.boost::container::constant_iterator<T, Difference>::operator* [with T = A, Difference = long int]()’ mfp.cpp:17: note: candidates are: A& A::operator=(A&) Which may not say too much, but if I change either the #if 0 to #if 1 or the #if 1 to #if 0 it suddenly compiles. So I'm thinking that the use of BOOST_MOVE_MACRO_COPYABLE_AND_MOVABLE(basic_string) in the interprocess string is somehow causing me to have to implement copy constructors and copy assignment operators in all classes that use them. Is this the way it is meant to be? I was fine with the compiler-generated ones before... Cheers Lars

El 10/03/2011 7:58, Lars Hagstrom escribió:
Hi all,
I'm having a problem compiling some code with boost 1.46 that was compiling fine with 1.36 to 1.43 (or thereabouts). It appears that this is somewhat related to the use of Boost.Move in the Boost.Interprocess library. I have tried to read up a bit on Boost.Move, but have failed to quite understand what of it applies to me.
You are right. The new emulation (which is what Boost.Move will implement) is more efficient in several cases but forces you to define the assignment operator. Full explanation here: http://igaztanaga.drivehq.com/libs/move/doc/html/move/two_emulation_modes.ht...
Is this the way it is meant to be? I was fine with the compiler-generated ones before...
Yes, it was, but suboptimal for copyable and movable classes like containers. In the old approach if class A was movable and copyable, this would call the copy assignment instead of the move assignment A a (...); a = A(); ...and you could not reuse A()'s string memory in a. If your class implements copy assignment taking by value, this limitation does not arise, but value-taking copy assignment is suboptimal for containers. Sorry for the breaking change. Best, Ion

Thanks for the explanation! Now I know that I haven't misunderstood completely... :-) Cheers Lars 2011/3/10 Ion Gaztañaga <igaztanaga@gmail.com>
El 10/03/2011 7:58, Lars Hagstrom escribió:
Hi all,
I'm having a problem compiling some code with boost 1.46 that was compiling fine with 1.36 to 1.43 (or thereabouts). It appears that this is somewhat related to the use of Boost.Move in the Boost.Interprocess library. I have tried to read up a bit on Boost.Move, but have failed to quite understand what of it applies to me.
You are right. The new emulation (which is what Boost.Move will implement) is more efficient in several cases but forces you to define the assignment operator. Full explanation here:
http://igaztanaga.drivehq.com/libs/move/doc/html/move/two_emulation_modes.ht...
Is this the way it is meant to be? I was fine with the
compiler-generated ones before...
Yes, it was, but suboptimal for copyable and movable classes like containers. In the old approach if class A was movable and copyable, this would call the copy assignment instead of the move assignment
A a (...); a = A();
...and you could not reuse A()'s string memory in a. If your class implements copy assignment taking by value, this limitation does not arise, but value-taking copy assignment is suboptimal for containers. Sorry for the breaking change.
Best,
Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Ion Gaztañaga
-
Lars Hagstrom