• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 380
  • Last Modified:

Locate a c++ class with virtual functions in a memory file for sharing between processes?

I have a C++ application that shares data with other applications that utilize the same classes, sharing via a memory mapped file.
Each class has a matching data structure defined which contains all the variables required by the class.
Each class instance has a matching data structure instance permanently located in the memory file.
Each class has only 1 member variable, a pointer to it's matching data structure.

The first process that starts is responsible for creating the memory file and initializing all class instances' data structures therein.  The layout of the memory file then remains constant, and the data within remains active, indefinitely.

In this manner different processes can start and stop and have instant access to the various class instances' data.

This approach works, but is ugly in a number of ways.

A less ugly solution might be to locate the class instances directly in the memory file, using placement-new &/or simple pointer assignment (depending on whether it is appropriate for the constructor to be called).  Is there any reason this would not work for non-virtual classes?

Classes with virtual functions are problematic, in that I need the data members shared, while the virtual function table pointer is specific to the process.

I'm guessing the value of the V-table pointer of the class instance would get assigned when (placement)new is called.  Is that correct?

One possibility, assuming I've guaranteed only 1 process has access at a time, might be to have each process call (placement)new for each class instance, each time it takes access, thereby initializing it's V-table pointer.  Excepting initial creation, the constructor used would be empty.  
Is this a viable approach?
Does new do any default initialization of member variables?

Do any other work arounds come to mind?

Should I stick with what I have?

Thank you,


Notes:
-Currently using Visual Studio 2005.
-The data exists only within 1 session of 1 machine, so cross OS/compiler compatibility is not an issue.
-None of the classes use virtual inheritance.
0
3mCanada
Asked:
3mCanada
1 Solution
 
evilrixSenior Software Engineer (Avast)Commented:
Maybe I've not quite understood what you are doing but this seems like overkill. Why are you memory mapping the actual classes? Why doesn't each process have its own class instance and the classes just contain references to the memory mapped data?

>> each time it takes access, thereby initializing it's V-table pointer
The C++ standard doesn't define how virtual functions are implemented, just how they need to behave so it is implementation dependent whether it is done using a v-table or any other mechanism.
0
 
3mCanadaAuthor Commented:
Evilrix:

Yes, I see your point.  

I came across a reference to placement-new describing it as being useful for sharing class instances between processes, and it sounded cleaner than the reference method (which is what I have now).

But as always the devil is in the details, and the more I read into the issues around virtual functions, the more it sounds like memory mapping class instances would be much trouble for no more benefit than eliminating the extra reference step out of the code.  In any case, it's good to have an expert opinion in agreement.

Thank you.
0
 
Infinity08Commented:
Not only do you have to be careful with polymorphic classes, but also with classes that contain any type of pointers (except offset pointers) or references as data member (directly or indirectly).

Static members are also a bit of a hassle, in order to make sure that the different processes see the same static member.

The general rule is to use shared memory only for trivial classes, and do more complex stuff if you really need to, and really know what you're doing.
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now