Original Post
I’m trying to implement this structure for use with my tool I’m making. I would like to organize all the data that the program uses via data registration. I’ve been told that a std::map would be a good way to go on this one. But I’ve never uses a std::map. I’ve read about them, but I don’t think I need to deal with all this overhead just for an object-variable registration system. Basically, my plan is this, when the program I’m making requests an object be created, it is allocated and registered. All the registration is managed wit hone data structure. So this means that each child window is my MDI application can access data from different documents. This probably wouldn’t happen because one document doesn’t contain any information about what another document has. Once a document is destroyed, each object that it created and registered is also destroyed. So I may change the data registry from being one global instance to one local instance per-document. I would like my data registered so other components may have access to this data with out having to directly deal with the document architecture. Instead, an event is posted (in some form or another) that requests operations to be executed on some data. The document architecture would be the sender and the components or tools with in the application would be the receiver. The register is invoked for a reference that will be passed to the component by the document. This way, I don’t have to worry about using accessory methods of the document. I use the information received by the register to access and manipulate the data it’s self. The register plays the middle man. The document creates and registers the data objects with the register. When ever a request is made for the data to be manipulated, the document requests the object from the registry and passes this information along with flag or message identifier depicting the operation to be carried out on this data. While the application’s editing components receive this message and manipulate the data. The components are aware of what data to be manipulated from the information received through the message. The document is aware of what objects need to be manipulated from requesting the information from the registry. If the requested object is not present, then the operation can’t be carried out. Other wise the information about the objects size, physical memory location and identities are returned to the document. I’m having problems implementing data registration system this on my own. My theory is to use a linked list that contains special nodes. The nodes have special members that describe the variable being registered is and where it is located to in memory. My node looks like this: I only use a single linked list because I will only be traversing the list one when I search for an item. The dwID and lpszName parameters refer to special identities that are used when searching for an item.
typedef struct _REGNODE {
// Linking mechanism
_REGNODE* pNext;
// Generic object info
DWORD dwObjSize;
LPVOID lpObjPtr;
// Unique object info
DWORD dwID;
LPSTR lpszName;
} REGNODE, *LPREGNODE;