Re: Portable Class For Shared Memory
On Sep 25, 10:48 am, Zeljko Vrba <zvrba.nos...@ieee-sb1.cc.fer.hr>
wrote:
One should also be able to specify WHERE (at which address) the segment
will be attached.
True.
Copying is highly dubious - what will it do? Attach the segment once more,
at another address (so you end up with two mirror copies)? Increase some
internal (not related to the system's count of attachments) reference count?
I would have it increment system reference count.
Same for assignment - a=b would have to first detach segment a in order
to reattach segment b, again at which address? This assignment will also
probably invalidate all pointers that were obtained from a's base.
I would have the "handle" to underlying kernel mode object duplicated
before assignment.
It makes no sense for a process to attach a SHM segment more than once.
As a rule, I generally define copy and assignment constructors for a
class if it appears that there is no harm in doing so. At some later
time, it might happen that I want a free (compiler-generated) copy or
assignment of an encapsulating class, and so having the functions
would keep the class regular.
Which leaves us with a singleton map that maps segment names to
(noncopyable,
nonassignable) SHM descriptors. Other features of that map might be "create
segment descriptor", "destroy segment descriptor" and "map segment given a
descriptor" that would actually do OS-specific stuff.
Hmmm...I generally dislike singleton classes. I think of objects of
singleton-classes as global variables in disguise. Yes, they might be
massive global variables, that is essentially what they are.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]