Re: pointers are unique?
In an actual P2P application, each client would have a unique IP address. Although you may indeed use these as IDs (perhaps, for example, as keys to a large hash-table), it would probably be simpler to just use the pointers as the "ID's" to connect one node to another, internally. When displaying the connections to the user, however, you would probably want to use the IPs.
As for deleting inactive nodes when they are no longer needed, the simplest way would be to check all the nodes that point to the current node (since it is a P2P application, the graph should be bidirectional), remove all references to the current node, and then deallocate it (this would be partially analogous to a real-world socket closing when it finds that the ip is was connected to is no longer active). However, if you wanted an even more "real-world"-like approach, you could give each node a boolean 'active' or 'live' property: when a live node wants to contact another node, it will check the other node's live status it; when the live node finds that the node it's looking for is dead (ie. inactive, offline or whathave you), it will remove it from its "contact-list" (ie. the edge-list. This is again analogous to a socket closing). Using this approach, each node could have a reference counter that keeps track of how many other nodes are pointing to it - when that counter reaches 0, the node can safely be deleted (this is the approach that many naive garbage collectors use).
Hope that didn't sound *too* rushed :)
-BlueRaja
On 6/20/07, gexarchakos <gexarchakos@gmail.com > wrote:
Hi BlueRaja,
Well, the thing is that I am building a P2P simulator. In P2Ps there
is not guarrantee that a node has always valid and active neighbours.
A node may disappear without notifying its neighbours. Therefore,
explicitly deleting all the pointers to a deleted object does not 100%
represent an actual P2P.
-- George
On Jun 20, 3:08 pm, BlueRaja <blueraja.ad...@gmail.com> wrote:
> If there is any possibility that there will still be references to an
> object elsewhere after it is deleted, it should not be deleted in the first
> place; this is not a problem with pointers but rather with the design of
> your program.
> You would have to give a more in-depth description of the program (and,
> especially, what should happen when a node is deleted) in order for us to
> give a recommendation of what to do with your garbage-pointers.
>
> -BlueRaja
>
> On 6/20/07, Saurabh Saha < saurs...@gmail.com> wrote:
>
>
>
> > Hi George
>
> > I completely agree with you but the doubt that I possess is how do you
> > plan to allocate the same memory area that you freed because as soon as you
> > free taht portion of the area, the area becomes a part of the free pool of
> > memory space that is available to be allocated with of course the garbage
> > values or values wrt the earlier object.
>
> > Now what exactly is the probability that a new node will take up exactly
> > the same area that you freed in the last node as now it is not about the
> > memory area but the picture is rather the free pool of memory in the heap.
>
> > Now allocation of memory to the new node is the OS's responsibility and
> > hence it takes care of it not the coder at the code level.Wat say????
>
> > Regards
> > Saurabh
>
> > On 6/20/07, gexarchakos <gexarcha...@gmail.com> wrote:
>
> > > Many thanks Saurabh,
>
> > > actually you are right, that's exactly what I meant. I think I agree
> > > with your points...
>
> > > I am building a network simulator and created a directional graph and
> > > initially I was using the pointers as IDs. But now I expand the
> > > simulator with dynamic insertion and deletion of nodes. This means
> > > that a new node may take the same memory space as an old deleted one.
> > > In this case, not updated pointers from other nodes to the old one
> > > will actually point to the new node. If no new node is inserted in the
> > > same memory space then these pointers will be broken, right?
>
> > > That was the problem that generated the question.
>
> > > Many thanks again,
> > > --George
>
> > > On Jun 20, 11:54 am, "Saurabh Saha" < saurs...@gmail.com> wrote:
> > > > Hi George
>
> > > > When u talk about deleting a memory address what exactly do u actually
> > > > mean-It does not mean u delete any memory area but rather it means
> > > that u
> > > > free portion of d dynamic memory which was allocated to the object at
> > > > runtime so I believe there is of course a possibility that the same
> > > memory
> > > > area can be taken up by another object unless of course the developer
> > > > forgets to de allocate the memory allocated thus resulting in a memory
> > > leak.
>
> > > > So talking about delete from the OS point of view does not quite mean
> > > that
> > > > whatever u delete from th UI is actually deleted but rather that the
> > > > reference entity pointing to d memory area gets allocated 2 Null
> > > permanently
> > > > and hence cannot point to d memory area it was earlier pointing to.
>
> > > > Correct me if i am wrong guys,.
>
> > > > Regards
> > > > Saurabh
>
> > > > On 6/20/07, gexarchakos <gexarcha...@gmail.com> wrote:
>
> > > > > Hello everyone,
>
> > > > > just a question on pointers:
> > > > > Assume that you dynamically allocate memory for an object. Sometime
> > > > > later, you dynamically delete it...
> > > > > Is there a possibility that another dynamically created object will
> > > > > take the same memory address as one previously deleted? In that
> > > case,
> > > > > pointers cannot work as IDs of objects, right?
>
> > > > > To me it makes sense if there is such a possibility. I'd like your
> > > > > opinion...
>
> > > > > Thanks,
> > > > > -- George
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "C++ Programming" group.
To post to this group, send email to Cpp-Programming@googlegroups.com
To unsubscribe from this group, send email to Cpp-Programming-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/Cpp-Programming?hl=en
-~----------~----~----~----~------~----~------~--~---
0 Comments:
Post a Comment
<< Home