|
Thanks Guffa,
1.
Sorry I miss the context of discussion a bit. The conclusion is obj1 and class1 instances may have
different life time, and no reference to class1 instance does not mean no reference to obj1 instance, right?
2.
Do you think my sample (class1, obj1 and class2) is correct?
regards,
George
|
|
|
|
|
George_George wrote: The conclusion is obj1 and class1 instances may have
different life time, and no reference to class1 instance does not mean no reference to obj1 instance, right?
Yes, the life time of one object is never tied to the life time of another object. They live completely seperate lives, and it's only the active references to each object that determines how long the object is active.
George_George wrote: Do you think my sample (class1, obj1 and class2) is correct?
It's an example of a fairly common situation. It's only the conclusion that is wrong; that a reference to the same object that the Class1 object has a reference to would keep the Class1 object alive.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
1.
Guffa wrote: It's only the conclusion that is wrong; that a reference to the same object that the Class1 object has a reference to would keep the Class1 object alive.
My conclusion is obj1 and class1 instances can have different life time, do you mean my conclusion is wrong?
2.
What do you mean "that a reference to the same object that the Class1 object has a reference to would keep the Class1 object alive."? I am confused when read a couple of times. Could you say in some other words or give some pseudo code please?
regards,
George
|
|
|
|
|
Hi George,
George_George wrote: do not fully agree with you that in order to hold reference to obj1, we have to hold reference to class1.
is the only sentence I don't agree with, since I never said such thing.
objects are independent, they live their own lives; the only way they may interact is
by holding references to each other; a live object obj1 that holds a reference to
object obj2 keeps obj2 alive, not the other way around.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
|
George_George wrote: Any comments
yes, I suggest you use real-life examples rather than class1 and obj2. That often
makes things much more clear. Example:
A car has a couple of wheels, as long as the car is alive the wheels are alive.
But a wheel can exist on its own, just remove it from the car, and scrap the car.
Hence, the car keeps its wheels alive, but the wheel does not keep the car alive.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Thanks Luc,
I understand your points now. Sorry, I missed your points before.
regards,
George
|
|
|
|
|
Zoltan Balazs wrote: 1. no, the order of freeing objects is well defined.
Where?? I'd like to see your documentation on this. It's well-known that object finalization in .NET is non-deteministic. There is no guaranteed order of object finalization. Here...[^]
|
|
|
|
|
Dave Kreskowiak wrote: It's well-known that object finalization in .NET is non-deteministic.
Yes, I know that.
I was refering to when you have a class and that class has a member. In that case the freeing order is well defined.
As Luc pointed out in the car example, first you free the wheel object and after that the car. Don't you agree with me?
link[^]
"How Finalization Affects Collection
When the garbage collector first encounters an object that is otherwise dead but still needs to be finalized it must abandon its attempt to reclaim the space for that object at that time. The object is instead added to a list of objects needing finalization and, furthermore, the collector must then ensure that all of the pointers within the object remain valid until finalization is complete.
....
Since the internal object pointers must remain valid, not only will the objects directly needing finalization linger in memory but everything the object refers to, directly and indirectly, will also remain in memory. If a huge tree of objects was anchored by a single object that required finalization, then the entire tree would linger, potentially for a long time as we just discussed."
And yes this is for objects that need finalization.
|
|
|
|
|
OK. I thought the original question was the order of finalization. So long as an object as some reference to it, it's kept alive, even if the original object that created it no longer maintains it's own reference to the child object.
|
|
|
|
|
|
Thanks Zoltan,
I think the article only mentions, we need to keep the referred object alive. In my sample, pointer to instance of component1 (of instance of class1), needs to keep alive.
But it never mentions the order of when Finalizer will be called on class1 instance and component1 instance, agree?
regards,
George
|
|
|
|
|
Hi Zoltan,
I read the article you recommended, and it looks great! Cool!
But it does not contain any content about why "the order of freeing objects is well defined". Could you point out which section of the article you refer to please? 
have a good weekend,
George
|
|
|
|
|
George_George wrote: 1. When instance of Class1 is put to GC queue, its wrapped Obj instance is 100% ensured to move to GC queue, but the order of whether the memory and Finalize method of Class1 instance or obj1 instance will be called first can not be decided (GC may make different decision in different situations)?
When there are no more active references to the Class1 object, the references inside the object are automatically inactive. If there are no other references to the Component object, it's collectable at the exact same time as the Class1 object is collectable.
If you would have declared any Finalizer for the class, and if the Component class as a Finalizer, it's true that you can't foresee in what order they would be called.
George_George wrote: 2. If some instance does not hold the reference of Class1, but holds the reference to obj1 through public method PassOut, in this situation, Class1 instance is prevent from being GCed?
No.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
Two more comments,
1.
Guffa wrote: If you would have declared any Finalizer for the class, and if the Component class as a Finalizer, it's true that you can't foresee in what order they would be called.
Why if Finalizer exists, the order of GC are not decided? In other words, if no Finalizer methods, the order is decided?
2.
Guffa wrote: No.
Confused. Seems your points are different from Luc's points. We both think class1 and obj1 may have different life time, e.g. some object may hold reference to obj1, but not class1. You do not agree with this? Or you think my sample is wrong?
regards,
George
|
|
|
|
|
George_George wrote: Why if Finalizer exists, the order of GC are not decided? In other words, if no Finalizer methods, the order is decided?
The order of object destruction is not guaranteed at all, no matter if there are finalizers or not. It simply cannot be predicted, or relied upon, that Object A is going to be destroyed before Object B.
Object finalization (there are no destructors in .NET) is non-deterministic. This[^] is a pretty description of how it works.
|
|
|
|
|
|
George_George wrote: Why if Finalizer exists, the order of GC are not decided? In other words, if no Finalizer methods, the order is decided?
If there is a Finalizer method, the object can not be garbage collected until the Finalizer has been called.
If there are no Finalizer methods, the order of garbage collection is still not possible to foresee, but then it doesn't matter. With no Finalizer, nothing happens when the object is removed, it just goes away.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
Let me confirm, in the situation when class1 is the only instance who holds the reference to obj1.
1. If both of them have Finalizer methods, the order of whether Finalizer method of class1 or Finalizer method of obj1 is called is not decided;
2. If both of them do have Finalizer methods, the order of whether class1 or obj1's memory will be reclaimed is not decided.
My understanding correct?
regards,
George
|
|
|
|
|
George_George wrote: 1. If both of them have Finalizer methods, the order of whether Finalizer method of class1 or Finalizer method of obj1 is called is not decided;
Exactly. They will be placed on the queue to be finalized in the order that the garabge collector happens to notice that the object is unused and that it has a Finalizer method.
George_George wrote: 2. If both of them do have Finalizer methods, the order of whether class1 or obj1's memory will be reclaimed is not decided.
Exactly. When the finalisers has been run, the objects are up for garbage collection just like any other object without a Finalizer method, so it's not even sure that they will be collected in the same order that they were finalised.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
Cool!
regards,
George
|
|
|
|
|
George_George wrote: 1. If both of them have Finalizer methods, the order of whether Finalizer method of class1 or Finalizer method of obj1 is called is not decided;
George_George wrote: 2. If both of them do have Finalizer methods, the order of whether class1 or obj1's memory will be reclaimed is not decided.
True. There is never a decision on finalization and memory reclaim orders, no matter what the situation. Since the GC walks the managed heap object tree looking for objects that no longer have references to them, it can encounter objects in any order in memory, hence no order is deterministically possible.
By your statements, it also seems as though you have the meaning of Class and Object a bit confused. Classes never have a reference to anything. It's just a template to create an object with. An Object is an instance of a Class. So your 1st statement should actually be:
...in the situation when Object1 is the only instance that holds the reference to Object2.
|
|
|
|
|
Thanks for your clarification, Dave!
regards,
George
|
|
|
|
|
I've created media player using sound dll's of windows.
Its woking...But my doubts are..
1) How can i associate it to the mp3 and wave files in my system?
2) How can i make a selection sequence in program for the user to select or to use my program as his default player for mp3/wave?
And help me on the code to make a progressbar while its playing..
Thanks in advance
varun
|
|
|
|
|
Well, this[^] seems to show how you can associate a filetype with your program. As for setting it as the default, that would require a whole new google search.
My current favourite word is: Bacon!
-SK Genius
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
