However,
in the object-oriented programming world, processes prefer to share
objects rather than raw information. With objects, there is no need
to serialize, transport, and de-serialize the information contained
within the object. Shared objects also reside in shared memory, and
although such objects "belong" to the process that created them, all
processes on the system can access them. Hence, all of the information
within a shared object should be strictly process-neutral.
This is a direct contradiction to the C++ object model currently adopted
by all popular compilers: C++ objects invariably contain pointers
to various Vee-Tables and sub-objects that are process-specific. For
such objects to be sharable, you need to make sure that the target
of these pointers resides at the same address in all the processes.
With the help of a small sample program, this article illustrates
cases where the C++ model succeeds, where it fails to work with the
shared memory model, and where possible workarounds exist. The discussion
and the sample program are limited to non-static data members and
virtual functions. Other situations are not as relevant to the C++
object model as these are: static and non-static non-virtual member
functions do not have any issues in shared environment. Per-process
static members do not reside in shared memory (and thus have no issues),
while shared static members have issues similar to those discussed
here.
Environmental assumptions
This text is highly specific to the Red Hat Linux 7.1 distribution
for 32-bit x86 Intel architectures, as GNU C++ compiler version 2.95
and associated tools were used to build and test the sample program.
However, you can apply the overall concepts equally well to any machine
architecture, operating system, and compiler combinations.
Sample program
The sample program consists of two clients, shm_client1 and shm_client2,
and uses the shared objects services provided by the shared library
shm_server. Object definitions reside in common.h:
Listing 1. Definitions in common.h
#ifndef __COMMON_H__
#define __COMMON_H__
class A {
public:
int m_nA;
virtual void WhoAmI();
static void * m_sArena;
void * operator new (unsigned int);
};
Start
Earning A Residual Income With Your Website
Cash
in on the popularity of online gaming with little or no
marketing investment and, most importantly, earn tremendous
amounts of money. |
class B : public A {
public:
int m_nB;
virtual void WhoAmI();
};
class C : virtual public A {
public:
int m_nC;
virtual void WhoAmI();
};
void GetObjects(A ** pA, B ** pB, C ** pC);
#endif //__COMMON_H__
Listing 1 defines three classes (A, B and C) with a common virtual
function WhoAmI(). The base class, A, has a member named m_nA. The
static member m_sArena and overloaded operator new() are there to
enable the construction of objects in shared memory. Class B is simply
derived from A, and class C is virtually derived from A. Both B::m_nB
and C::m_nC are provided to ensure that the sizes of A, B, and C are
distinct. This simplifies the implementation of A::operator new().
The interface GetObjects() returns the shared objects pointers.
The shared library implementation is in shm_server.cpp:
Read
the Full Article.
*originally published at IBM
DeveloperWorks
About the Author:
Sachin has been working extensively in C++ for five years, including
three years of research into the C++ object models of various compilers.
He currently works for IBM Global Services India. You can contact
him at sachin_agrawal@in.ibm.com.
Read this newsletter at:
http://www.linuxpronews.com/2004/0630.html |
|
| From
the Forum: |
| In
desperate need of a forum converter.. |
I currently have a LARGE forum on infopop. It
is in the ubb.x format. I am redesigning my site in phpnuke
and need a converter from ubb.x to phpbb.
Can anyone help here? I need to convert my memberdatabase as
well as the forum content.
Thanks ...
|
 |
By
Sachin O. Agrawal