Thread: best way to uniquely tag a node

hi just a quik query,

i am trying to implement unique id's for list nodes, that are safe, and can be locked,

in php or javascript i find this easy, and can do this in ways not possible in c language, for obvious reasons...
anyhow, i thought of assigning an integer type id to each node and incrementing that,
but i am a bit short on ideas of how to make this safe,

i thought of assigning my initial node's id with a value of one, and then on each new node created store the previous nodes id in a temp var, increment that and assign this to the next node, but i am worried that this might fall apart when deleting and and sorting nodes,

so then i thought perhaps i could have a predefined variable that gets incremented with each new node, and the respective node's id has this value, but this too seems like it might have potential problems, especially if every node suddenly took on the same value,....

well as i said i am a bit short on ideas,
if anybody know of a relatively standard safe way to implement this, advice would be awesome, no source code is needed, just a heads up

so then i thought perhaps i could have a predefined variable that gets incremented with each new node, and the respective node's id has this value, but this too seems like it might have potential problems, especially if every node suddenly took on the same value,....

I don't see why this wouldn't work...

ja thanks,

i came here a few minutes ago, read your post, told myself i was being lame and went put together something, i am glad to say that i will be able to do this:>

Originally Posted by Dino

Every node (item, thing, structure, whatever) in storage is going to be in memory at some particular address. If you have 5 items, each will have its own address in storage, like this:

Item1 is at address 40568
Item2 is at address 41770
Item3 is at address 6000C
Item4 is at address 1245644
Item5 is at address 0BC

No two items will ever occupy the same location in memory, therefore, they will all have unique addresses.

It is a very common practice to associate the address of something as its unique identifier. If you are familiar with HANDLES, like in Windows programming, that's the same thing. Sometimes this unique address is also called a TOKEN.

Visibility of where you keep your things in storage is a completely different aspect that the OP did not mention as a concern.

C and C++ are built upon the concept of addresses, addressing, address arithmetic and addressability. No big deal. It sounds like the C++ guy was more of a Java fan, (and Java is a great language too), but driving your car is inherently life threatening too, and we do it every day.

thanks for your answer.But how about using static int i and then i++ for each object created.Therefore it is much safer?
I hope I don't sound nit-picking or arguing with you.I'm more like wondering why should I travel using route A instead of route B.
thanks.

hi,

came check other replies for interest,
as this last post is suggesting, this is exactly how i went about implement a uniqe id,
using the address is not something that crossed my mind, but will check it out anyhow, thanks.

thanks man, its not so much that i mess up with pointers, but was having a bit of a paranoid moment i guess, and actually felt kinda silly when i realized how silly i was sounding, i am not quite sure yet which way i will use, would've have stuck to the static int, but using the address could save some, if you were to saving to file you could just regenerate the id's when reloading the list,

but you can tick this one as solved...

There is no reason why managing the primary keys yourself would be less safe. You should be handling all operations on your list using functions anyways. And thus your 'manual' becomes 'automatic'.

I would prefer to explicitly define how primary keys are generated and handled. I am thinking beyond a list; more like a database.

It's going to depend on what you are developing and for what purpose.

thanks all the poster above for your replies.It seem that I always thought of "cons" but not "pros".

Now I have a better judgement.