共享内存中的STL容器 [英] STL containers in shared memory
问题描述
亲爱的C ++专家，
在过去的几个月里，我一直在使用共享内存编写我的第一个程序
。至少可以说，它一直是一种深入人心的经历。目前共享内存包含一些固定大小的结构，但我真的需要能够在那里存储更多的b / b
复杂的可变大小的数据。所以接下来的任务是在这个
共享区域中解决如何存储C ++对象以及如果可能的STL容器的问题。
到目前为止，我已经完成了以下工作：
- 创建共享内存区域，并从
各种进程附加到它。它当然可以在不同的地址结束在不同的地址，这是一个关键问题。
- 基本C malloc（）/免费（ ）区域中的样式分配，使用偏移量
而不是指针，以便它可以在任何映射的地方工作。
- operator new，new []的实现，删除和删除[]使用
这些C风格的原语。
我现在还有两个挑战。首先，我想写一个
抵消< T>我可以在通常使用T *的地方使用的课程。
我认为这是可能的;我需要定义operator *，从T *转换为偏移< T>以及其他一些东西。
转换。任何
的建议都会受到欢迎，不过我认为我最终能够工作
。我的第一个决定是抵消是否相对于该地区的起点是相对的，在这种情况下，每过程全球是指
需要记录区域起始地址，或者它们是相对于它们存储的位置，这避免了全局但是实现了
更难。
对我来说，更困难的挑战是STL分配器。我只有这个最模糊的想法。据推测，我可以创建一个allocator
object。容器将使用，没有太多麻烦（虽然
一个例子会很好）。但是，我可以说服他们想要存储我的抵消的容器，而不是真正的指针吗？
我希望有人进来这个小组能够指出我的一些好例子，或者说服我说这是不可能的！
这是什么？
BTW这适用于Anyterm： http://chezphil.org/ anyterm / - 如果你需要做远程服务器管理员，可能会很有趣。
干杯，菲尔。
嗯。为什么不将指针放入共享区域，并且
动态地从堆中分配容器（或任何其他对象）？
< ph ******* @ treefic.com>写了亲爱的C ++专家，
在过去的几个月里，我一直在用共享内存编写我的第一个程序。至少可以说，它一直是一种在深层次的体验。目前共享内存包含几个固定大小的结构，但我真的需要能够在那里存储更多复杂的可变大小的数据。所以接下来的任务是在这个
共享区域中解决如何存储C ++对象以及如果可能的STL容器。
到目前为止，我已经完成了以下工作：
- 创建共享内存区域，并从各种进程附加到它。它当然可以在不同的进程中以不同的地址结束，这是一个关键问题。
- 区域内的基本C malloc（）/ free（）样式分配，使用偏移
而不是指针，以便它可以在任何映射的地方工作。
- 使用
这些C风格的operator new，new []，delete和delete []的实现原语。
我现在还有两个挑战。首先，我想写一个
偏移< T>我可以在通常使用T *的地方使用的课程。
我认为这是可能的;我需要定义operator *，从T *到offset< T>的转换，以及其他一些事情。任何
建议都会受到欢迎，不过我认为我最终能够完成它。我的第一个决定是抵消是否与该地区的起点相关，在这种情况下，每过程全球是指需要记录区域的起始地址，或者它们是相对于它们存储的位置，这样可以避免全局，但会使实现更难。
对我来说，更困难的挑战是STL分配器。我对此只有最模糊的想法。据推测，我可以创建一个allocator
对象。容器将使用，没有太多麻烦（虽然一个例子会很好）。但我可以说服那些他们想存储我的抵消的容器，而不是真正的指针吗？
我希望这个小组中的某个人能够指出一些很好的例子，或者说服我这是不可能的！
它是什么？
BTW这是针对Anyterm： http://chezphil.org/anyterm/ - 如果你需要做的话可能会很有趣远程服务器管理员。
干杯，菲尔。
ph ******* @ treefic.com 写道：
....
我现在还有两个挑战。首先，我想写一个
偏移< T>我可以在通常使用T *的地方使用的课程。
查看奥地利的相对指针
http://austria.sourceforge.net/dox/h...8h-source.html
它的行为依赖于编译器实现，但我认为它将与大多数编译器一起使用
。
....
我希望这个小组中的某个人能够指出我一些好的例子，或者说服我这是不可能的！
它是什么？
你会发现问题是如果你想在你的代码中有多个共享的
区域，你需要知道每个区域的偏移量是多少。
因此，共享内存指针解除引用的参数是您当前正在引用的区域的偏移量
。有一种技术可以通过使用this来将这个作为一个参数用于b
。指向
指出你正在引用哪个地图，但性能可能会成为一个重要的问题（虽然有很多策略可以用来支付
优化）。
一旦你遇到这个问题，就会出现带有虚拟方法的
对象的vtables问题。除非你从
编译器中获得一些支持，否则你就是SOL。
G
< BLOCKQUOTE>>嗯。为什么不将指针放入共享区域，
从
动态分配容器（或任何其他对象）
堆？
因为那时他们没有共享。
--Phil。
Dear C++ Experts,
Over the last couple of months I have been writing my first program
using shared memory. It has been something of an "in-at-the-deep-end"
experience, to say the least. At present the shared memory contains a
few fixed-size structs, but I really need to be able to store more
complex variable-sized data in there. So the next task is to work out
how to store C++ objects, and if possible STL containers, in this
shared region.
So far I have got the following bits working:
- Creating the shared memory region, and attaching to it from the
various processes. It can of course end up at different addresses in
the different processes, and this is a key problem.
- Basic C malloc()/free() style allocation in the region, using offsets
rather than pointers so that it works wherever it is mapped.
- Implementations of operator new, new[], delete and delete[] that use
these C-style primitives.
I now have two remaining challenges. First, I''d like to write an
offset<T> class that I can use in places where I would normally use T*.
I think that this is possible; I''ll need to define operator*, a
conversion from T* to offset<T>, and a few other things. Any
suggestions would be welcome, though I think I would be able to work it
out eventually. My first decision is whether the offsets are relative
to the start of the region, in which case a "per-process global" is
needed to record the region start address, or they''re relative to where
they are stored, which avoids the global but makes the implementation
harder.
For me the more difficult challenge is the STL allocators. I have only
the vaguest idea about this. Presumably I can create an "allocator
object" that the containers will use, without too much trouble (though
an example would be good). But can I persuade the containers that
they''d like to store my offsets, instead of real pointers?
I''m hoping that someone in this group will be able to either point me
to some good examples, or maybe convince me that it''s impossible!
Which is it to be?
BTW this is for Anyterm: http://chezphil.org/anyterm/ - could be
interesting if you ever need to do remote server admin.
Cheers, Phil.
Hmm. Why not put just the pointer(s) into the shared region, and
dynamically alloc the container(s) (or any other object) from the heap?
<ph*******@treefic.com> wroteDear C++ Experts,
Over the last couple of months I have been writing my first program
using shared memory. It has been something of an "in-at-the-deep-end"
experience, to say the least. At present the shared memory contains a
few fixed-size structs, but I really need to be able to store more
complex variable-sized data in there. So the next task is to work out
how to store C++ objects, and if possible STL containers, in this
shared region.
So far I have got the following bits working:
- Creating the shared memory region, and attaching to it from the
various processes. It can of course end up at different addresses in
the different processes, and this is a key problem.
- Basic C malloc()/free() style allocation in the region, using offsets
rather than pointers so that it works wherever it is mapped.
- Implementations of operator new, new[], delete and delete[] that use
these C-style primitives.
I now have two remaining challenges. First, I''d like to write an
offset<T> class that I can use in places where I would normally use T*.
I think that this is possible; I''ll need to define operator*, a
conversion from T* to offset<T>, and a few other things. Any
suggestions would be welcome, though I think I would be able to work it
out eventually. My first decision is whether the offsets are relative
to the start of the region, in which case a "per-process global" is
needed to record the region start address, or they''re relative to where
they are stored, which avoids the global but makes the implementation
harder.
For me the more difficult challenge is the STL allocators. I have only
the vaguest idea about this. Presumably I can create an "allocator
object" that the containers will use, without too much trouble (though
an example would be good). But can I persuade the containers that
they''d like to store my offsets, instead of real pointers?
I''m hoping that someone in this group will be able to either point me
to some good examples, or maybe convince me that it''s impossible!
Which is it to be?
BTW this is for Anyterm: http://chezphil.org/anyterm/ - could be
interesting if you ever need to do remote server admin.
Cheers, Phil.
ph*******@treefic.com wrote:
....
I now have two remaining challenges. First, I''d like to write an
offset<T> class that I can use in places where I would normally use T*.
See austria''s "relative pointer"
http://austria.sourceforge.net/dox/h...8h-source.html
It''s behaviour is compiler implementation dependant but I think it will
work with most compilers.
....
I''m hoping that someone in this group will be able to either point me
to some good examples, or maybe convince me that it''s impossible!
Which is it to be?
The problem you will find is that if you want to have multiple shared
regions in your code you need to know what the offset is for each one.
Hence a parameter to shared memory pointer dereferencing is the offset
of the region you''re currently referecing. There is a technique you can
use to take this out as a parameter by using the "this" pointer to
figure out which map you''re referencing, but performance may become a
significant issue (although there are a number of strategies for
optimization).
Once you have this problem licked, you have the issue of vtables for
objects with virtual methods. Unless you build in some support from the
compiler, you''re SOL.
G
> Hmm. Why not put just the pointer(s) into the shared region, anddynamically alloc the container(s) (or any other object) from the
heap?
Because then they''re not shared.
--Phil.
这篇关于共享内存中的STL容器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
