--- Comment #10 from pcarlini at suse dot de 2005-11-15 22:38 ---
To be sure we don't confuse two issues here (see also my #7), all the
containers
are already able to use shared memory allocators such as libmm:
http://www.ossp.org/pkg/lib/mm/
(via a very lightweight wrapper). This is
--- Comment #9 from et at ihear dot com 2005-11-15 22:10 ---
This cripples virtual inheritance for fine-grain parallel processing. There
should at least be a compiler option for process-independent referencing,
because admittedly, this would slow down dereferencing. Or maybe a operator n
--
What|Removed |Added
CC||bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-10 18:32
---
Adding 16612.
This is a higher-priority enhancement request. We need a shared_memory
allocator, a lot of people want it, it would be cool and useful, etc.
The one in 16612 is not going to work. We don't and
--- Additional Comments From pcarlini at suse dot de 2005-05-02 18:10
---
Marc, we are talking about two completely different issues. Indeed, it's
*perfectly* possible using a shared-memory allocator with the STL containers.
In fact, we are in the process of providing an allocator of tha
--- Additional Comments From mronell at alumni dot upenn dot edu
2005-05-02 16:49 ---
Apologies for my persistence, but the following is still not clear to
me. Given the last reply to this concern, I now understand:
1. Placement into shared memory is not possible. If processes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
01:44 ---
(In reply to comment #4)
> However, as before, my approach depends on being able to place and share C++
> objects through shared memory. Its that still possible?
>
> Am I missing some esoteric compiler fl
