Interacting with procedurally generated objects

[Ravenlore]

Hi there, I'm still fairly new to C++ and trying to get used to a more object oriented programming approach. However I'm struggling with how (or if it's even possible in c++) to implement this:

The concept
--------------------------
I have a program that creates an object of a given class every time a certain event happens. These objects contain functions for handling messages that are passed to them. The main program contains a message handling procedure to intercept these messages, identify which object they belong to, and pass the commands + arguments to the required function within the object.
--------------------------

The problem I have is in identifying each object after it has been created. My function for creating objects is just using new and has the object's constructor set everything up.

I could create a pointer to that object's memory address when it is created, but then I am just passing the problem from the object itself to the pointer - how do I uniquely identify each object without explicitly naming either the object itself or a pointer to it?

I have looked around for a way to procedurally generate the names as they are created, and played with some code to try and use the value of a variable or the return value of a function as the name for a new object / pointer but I couldn't find a solution. Is there a way to generate names this way?

My other option would be to build a database where on creation the object assigns itself an identifier internally, and passes this to a database alongside its memory location, and the message procedure looks in this database, but this seems sloppy.

Any guidance would be much appreciated!

[grumpy]

If you want to map messages to objects that will process those messages, then the function doing the mapping needs to have information about the data in the messages (eg a string that provides a name), information about each object (for example, a pointer), and a predictable means of mapping one to the other.

That means, when creating each object, you need to explicitly keep track of how to find them later. That either needs to be done by the function(s) that creates each object (when creating the object, register its address in some global list) or by each object (for example, the constructor of an object registers itself in some global list).

Even if you, conceptually at some high level, have a system of broadcasting messages that magically find their way to the right object, you will need some lower level mechanism that (possibly invisibly to the higher level code) keeps track of objects and maps messages to the correct objects.

[Ravenlore]

That's what I thought I might have to do, but it seemed a silly workaround if there was a method of naming the objects / pointers within the code, as the program would then build + maintain this global list itself. I just wanted to make sure I wasn't missing something obvious!

I guess this way is better now I think about it, because my naming algorithm for objects in this global list can incorporate some of the values of that object, which should facilitate easier searching and organising.

[phantomotap]

I guess this way is better now I think about it, because my naming algorithm for objects in this global list can incorporate some of the values of that object, which should facilitate easier searching and organising.

O_o

This sounds like a remarkably bad idea.

Instead of asking people how to do something you think you'd like to do, what don't you explain the situation and see what ideas might come up.

Soma

[C_ntua]

There is actually methods to get the type of the object, like typeid and dynamic_cast<> (search for more info).
So the system is actually making a list of objects. It can keep a list for other reasons as well. This is not necessarily supported by every system though.

But the point is that you have to ask for this list at runtime, which is costly and more complex than using your own list you can manipulate any way you want.
For example, depending on how you search for objects it can be more efficiently using a tree instead of an array to store objects. Then some objects you don't want to include in the global list, where the system would have to include everything. In the end your own way is more efficient and you know exactly what you are doing.

[Ravenlore]

There is actually methods to get the type of the object, like typeid and dynamic_cast<> (search for more info).
So the system is actually making a list of objects. It can keep a list for other reasons as well. This is not necessarily supported by every system though.

But the point is that you have to ask for this list at runtime, which is costly and more complex than using your own list you can manipulate any way you want.
For example, depending on how you search for objects it can be more efficiently using a tree instead of an array to store objects. Then some objects you don't want to include in the global list, where the system would have to include everything. In the end your own way is more efficient and you know exactly what you are doing.

Thanks for clearing that up. As it might be important to know later, how do I ask for this list?

This sounds like a remarkably bad idea.

Which part seems wrong? To give a hypothetical example, lets say all the objects are shoes. Each of these shoes has a shoesize of exactly two digits. It seems reasonable to have these two digits first in the unique ID, so the list can be easily searched / organised by size. The next three digits could be the manufacturer, and so on for however many items I think is appropriate, and the last digits would be a unique reference number that could be based on, say, the date and time of entry.

This way I can easily handle + pass messages that request a range of information using the same unique ID, which stays as a single integer value. The only limitation would be the fixed length of the ID number, but as long as I allocate enough digits it shouldn't be a problem. This isn't the best example because you'd want to store the values for this kind of database on disk rather than in memory as objects... but you get the idea.

[phantomotap]

O_o

Mostly, it is the bit where you are talking about duplicating information that is native to an instance in the handle of that instance.

Consider for a moment what happens if you need to update state information relative to that handle? It seems a little pointlessly complicated doesn't it?

You don't need to do that just to sort the instances of your class by a given metric. In fact, you can easily create an array to store the actual instances and several trees indexed by different members of those instances. (I'd suggest rapping everything in an interface to prevent mishaps.)

Soma

[Ravenlore]

O_o

Mostly, it is the bit where you are talking about duplicating information that is native to an instance in the handle of that instance.

Consider for a moment what happens if you need to update state information relative to that handle? It seems a little pointlessly complicated doesn't it?

You don't need to do that just to sort the instances of your class by a given metric. In fact, you can easily create an array to store the actual instances and several trees indexed by different members of those instances. (I'd suggest rapping everything in an interface to prevent mishaps.)

Soma

I need the facility for the object to delete itself after it's no longer needed. So objects are constantly creating and deleting themselves all the time. I think this would make storing them in an array a little complicated, as I either need a safe way to reuse indexes in the array or it will be enormous and inevitably overflow. And i'd also then be relying on knowing the array index to identify + interact with them. Or have I misinterpreted something here?

I managed to get the implementation I wanted using the global list suggestion, using vectors at first. It was a little messy but it worked ok. Currently rewriting it to query an SQL database instead which should make my lists much easier to manage. Thanks for the help everyone!