dynamic object names

[cam875]

I am trying to figure out for my physics simulator how to give my object name a variable or something, ill show an example and the compiler flags it an error but all i am trying to do is pass it the value not the variable

long atomID = 0;
atom atomID;

struct atom
{
short radius;
}

im just trying to get the object of atom to be called 0 so that i can reference all of my objects if lets say the simulator has 100 atoms operating in it at once. but doing it like this I want to be able to create all the atoms like this by just incrementing the atomID so i have a new variable name or something. does anyone have ideas for implementing an idea like this.

[Freaky_Chris]

erm did i miss something or do you not just want an array?

atom myAtoms[100];

Chris

[ArkM]

Did you want an array of atoms?
Possible answers:
1. I don't understand you.
2. You don't know any arrays of...
?

[cam875]

I have it working with a bunch of vectors but I wanted to see if you can do it with objects from structs, im inexperienced with objects so I want to know how can you have the name of the object change everytime you create a new one.

[ArkM]

Have you ever heard about pointers in C and C++?
What's "the name of the object" in your interpretation? There are anonymous objects in C and C++. Can you post pseudocode with desired "changed names"?

[cam875]

can the name possibly be a number or something, it has to be something that I can increment by 1 or something before I make another atom object, and yes I have used pointers like once or twice but havent found too much use for them yet in my programming, maybe now is the time :)

so basically everytime I create an atom object its name has to be slightly different to differentiate between all the atoms created in the simulator.

[Murtan]

This sounds a lot like another recent thread where the developer 'needed' to name the variables based on user input.

The name that you use inside the source need not have anything to do with the name the user sees. It would be your responsibility as the developer to map the elements of the array or vector or whatever other data structure you think would best fit your needs to the names the user is using.

[ArkM]

Well, you have used a compiled, not interpretive language, so "basically everytime you create an atom object its name (and therefore all your program source text) has to be slightly different to differentiate between all the atoms created in the simulator". In other words, you must recompile, relink and reload all your program "everytime you create an atom object". It's cool! Do you find it funny? I do ;)

Think: no source program names at run-time! There are a sequence of machine instructions. What unexistence entities are you intending to change "everytime you create an atom"?

[Bench]

can the name possibly be a number or something, it has to be something that I can increment by 1 or something before I make another atom object, and yes I have used pointers like once or twice but havent found too much use for them yet in my programming, maybe now is the time :)

so basically everytime I create an atom object its name has to be slightly different to differentiate between all the atoms created in the simulator.

Why do they need to have names at all? isn't it simply enough to be able to store un-named atoms in a vector and be able to find them using their position/index within the vector?
The "names" which you see when you're writing your code are for your convenience only - when you send your program through the compiler, those names become non-existant, because your computer doesn't need them - it remembers objects by their 'index' (address) in your computer's memory instead.

[cam875]

thats what I have been doing, I was just looking to do it with objects from structs but it doesnt matter anymore.

[Murtan]

If keeping the anonymous Atoms in a vector is what you have been doing, you were doing it right.

Objects from structs must be named for the compiler (according to the language's rules) at compile time, they cannot be defined at runtime.

But as I said before (and it is worth remembering) what the users see (or think they see) need not have any relationship to how the program stores and/or manipulates the data. If it is convenient, sure make the two similar, but when you run into a conflict, present the user with the 'correct' interface and massage the program to make it work. (Don't force the user to interact with the program in a certain way, just because that's how the data is stored/organized.)

[cam875]

alright thanks for the advice ill continue on with that.