[interprocess] move semantics for shared objects, regions?
Hello,
In the interprocess library, move semantics are provided for all the container
types using boost::interprocess::move().
The code for move semantics is (mostly) present in the shared object types and
shared_region, but something is missing for it to actually work for these classes:
the necessary specialization of the 'is_movable' trait, and the correct signature on the
copy constructor and assignment operators.
For example, this does not compile:
//----------------
file_mapping m_file;
{
file_mapping f("file.bin", ipc::read_write);
m_file = move(f);
}
//----------------
But this workaround compiles and works as expected:
//----------------
file_mapping m_file;
{
file_mapping f("file.bin", ipc::read_write);
detail::moved_object
Bryan Green wrote:
Hello,
In the interprocess library, move semantics are provided for all the container types using boost::interprocess::move().
The code for move semantics is (mostly) present in the shared object types and shared_region, but something is missing for it to actually work for these classes: the necessary specialization of the 'is_movable' trait, and the correct signature on the copy constructor and assignment operators.
Sorry for the late reply.
Is there a reason this was left out?
Yes, this is a half-baked feature. It's almost ready but I had no time to test it for release date, so I just didn't activate it. I'll add it for the next version.
If it is an oversight, would a bug report with a patch file be welcome?
Sure.
Thanks, -bryan
Thanks! Ion
=?ISO-8859-1?Q?Ion_Gazta=F1aga?= writes:
Bryan Green wrote:
Hello,
In the interprocess library, move semantics are provided for all the containe r types using boost::interprocess::move().
The code for move semantics is (mostly) present in the shared object types an d shared_region, but something is missing for it to actually work for these cla sses: the necessary specialization of the 'is_movable' trait, and the correct signa ture on the copy constructor and assignment operators.
Sorry for the late reply.
Is there a reason this was left out?
Yes, this is a half-baked feature. It's almost ready but I had no time to test it for release date, so I just didn't activate it. I'll add it for the next version.
If it is an oversight, would a bug report with a patch file be welcome?
Sure.
Okay, thanks. :) Here is the bug/patch: http://svn.boost.org/trac/boost/ticket/1932 A note: The patch fixes "movability" for several types: file_mapping, shared_memory_object, mapped_region, windows_shared_memory, managed_head_memory, managed_external_buffer. The problem is a little harder for managed_shared_memory, managed_mapped_file, and managed_windows_shared_memory, because they derive from detail::managed_open_or_create_impl, which currently does not have a default constructor. I chose not to dig into that at this time. -bryan
participants (2)
-
Bryan Green -
Ion Gaztañaga