[Interprocess] Collection of base shared_ptr
I'm using Boost 1.49, and Visual Studio 10. I'm having a hard time figuring out how to store a shared_ptr to a derived class in a collection of shared_ptr to the base class. This is something I do all the time with normal shared pointers. This is my code: { struct Base {}; struct Derived : public Base {}; typedef boost::interprocess::managed_shared_ptr < Base, boost::interprocess::managed_shared_memory >::type Base_ptr; typedef boost::interprocess::deque < Base_ptr, boost::interprocess::managed_shared_memory::allocator< Base_ptr
::type > Queue;
struct shm_remove { shm_remove() { boost::interprocess::shared_memory_object::remove("testing"); } ~shm_remove() { boost::interprocess::shared_memory_object::remove("testing"); } } remover; boost::interprocess::managed_shared_memory shared_memory( boost::interprocess::create_only, "testing", 65536); Queue* queue = shared_memory.construct< Queue
(boost::interprocess::anonymous_instance)( shared_memory.get_allocator< Base_ptr >());
queue->push_back(
bi::make_managed_shared_ptr< Derived >(
shared_memory.construct< Derived >(bi::anonymous_instance)(),
shared_memory));
}
The compiler tells me a bunch of cryptic stuff, I think it has to do with
the different deleter types:
boost/container/deque.hpp(1040): error C2664:
'boost::interprocess::shared_ptr
El 03/04/2012 21:18, Aaron_Wright@selinc.com escribió:
I'm using Boost 1.49, and Visual Studio 10.
I'm having a hard time figuring out how to store a shared_ptr to a derived class in a collection of shared_ptr to the base class. This is something I do all the time with normal shared pointers. This is my code:
You can't do that. In shared memory there is no place for virtuality (so no room for virtual destructors essential to be able to use derived classes). boost::interproces::shared_ptr is only for reference counted semantics. Best, Ion
Hmmm. I was almost thinking the same thing, but I was hoping there was
something I was missing.
What about boost::variant? Can I stuff that into a queue in shared memory?
---
Aaron Wright
From: Ion Gaztañaga
I'm using Boost 1.49, and Visual Studio 10.
I'm having a hard time figuring out how to store a shared_ptr to a derived class in a collection of shared_ptr to the base class. This is something I do all the time with normal shared pointers. This is my code:
You can't do that. In shared memory there is no place for virtuality (so no room for virtual destructors essential to be able to use derived classes). boost::interproces::shared_ptr is only for reference counted semantics. Best, Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
El 03/04/2012 23:37, Aaron_Wright@selinc.com escribió:
Hmmm. I was almost thinking the same thing, but I was hoping there was something I was missing.
What about boost::variant? Can I stuff that into a queue in shared memory?
I don't know boost::variant internals, but if it does not use any virtual function, it could be a choice. Ion
AMDG On 04/04/2012 08:26 AM, Ion Gaztañaga wrote:
El 03/04/2012 23:37, Aaron_Wright@selinc.com escribió:
Hmmm. I was almost thinking the same thing, but I was hoping there was something I was missing.
What about boost::variant? Can I stuff that into a queue in shared memory?
I don't know boost::variant internals, but if it does not use any virtual function, it could be a choice.
boost::variant doesn't use virtual functions, *but* under some conditions it can store a raw pointer which is also a problem for interprocess. In Christ, Steven Watanabe
Is it easy to figure out if I'll hit those conditions? Or are they sprinkled all around? I simply want to send messages through shared memory. I would like to do it with some type safety. The messages would be structs like so: struct Start {...}; struct Stop {...}; typedef boost::variant < Start, Stop
Message;
Would raw pointers come into play? Would it depend on the contents of the
structs?
---
Aaron Wright
From: Steven Watanabe
El 03/04/2012 23:37, Aaron_Wright@selinc.com escribió:
Hmmm. I was almost thinking the same thing, but I was hoping there was something I was missing.
What about boost::variant? Can I stuff that into a queue in shared memory?
I don't know boost::variant internals, but if it does not use any virtual function, it could be a choice.
boost::variant doesn't use virtual functions, *but* under some conditions it can store a raw pointer which is also a problem for interprocess. In Christ, Steven Watanabe _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
(on Boost.Variant and dynamic allocation) On Apr 6, 2012, at 7:45 PM, Aaron_Wright@selinc.com wrote:
Would raw pointers come into play? Would it depend on the contents of the structs?
Looks like you need nothrow copy constructors and to specialize some traits to label them as such. See "Enabling Optimizations" in http://www.boost.org/doc/libs/1_49_0/doc/html/variant/design.html#variant.de... Cheers, Gordon
If I read that web page correctly, the only time raw pointers are used is
when creating a backup for when a copy constructor fails. From the reading
it would seem that the backup point is not persisted. When the copy
constructor fails, the backup is copied off the heap into variant's
storage. When the copy constructor doesn't fail, the backup is discarded.
This raw pointer would only be needed for a small moment in one process.
It would not need to be shared with another process. So variant should
work fine with interprocess.
I'm making some assumptions here that that web page contains everything I
need to know. Am I assuming too much?
---
Aaron Wright
From: Gordon Woodhull
AMDG On 04/10/2012 11:58 AM, Aaron_Wright@selinc.com wrote:
If I read that web page correctly, the only time raw pointers are used is when creating a backup for when a copy constructor fails. From the reading it would seem that the backup point is not persisted. When the copy constructor fails, the backup is copied off the heap into variant's storage.
No. In this case, the backup isn't copied because that could also throw, and then how could we preserve the invariants? If the copy constructor fails, Boost.Variant simply stores the pointer to the heap backup.
When the copy constructor doesn't fail, the backup is discarded. This raw pointer would only be needed for a small moment in one process. It would not need to be shared with another process. So variant should work fine with interprocess.
I'm making some assumptions here that that web page contains everything I need to know. Am I assuming too much?
In Christ, Steven Watanabe
participants (4)
-
Aaron_Wright@selinc.com
-
Gordon Woodhull
-
Ion Gaztañaga
-
Steven Watanabe