 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / February 2004Re: What does the CLR do when you instantiate an object? - Continue
Hi Avon Last night I was able to duplicate your experiment with your sample classes with debug point at the parent class constructor On the stack dump, I did see the test class's main methos at the bottom of the stack, abov the Main mathod, it was childclass's constructor and then directly above that it is the parentclass constructor, and with method call of Console.ReadLine at the top That again conformed that the parent class cocntrucor is called before the object of the child class is create On the heap dump, I saw the a memory area of 20K with name Module1/Childclass. But I honestly disagree with you that that is a complete object of the child class. It is just a memory area with variable name and nothing else. When I used !Obja (object reference #), I did not see any thing either As I pointed earlier, an object is more than just an memory area with a varible name referenced on it. it has to have all class member data be writen to that memory. I did not see any evidence that in the experiment. To prove the contrary, I modified your classes so that the child class contains a method and two instance varibles with values 5, and 10 and then put degbug point at the parent class constructor, if you run the EXE you will see t that point, the values of the instance variables are not initialized to 5 and 10. That indicates that the instance of the child class was not completed yet. Instead when you move the debug point to child class constructor, the values are initialized to 5 and 10 correctly. Here is the code Module Module Public Int1 As Intege Public Int2 As Intege Public Class ParentClas Public Sub New( System.Console.WriteLine("Parent Class Constructor is called Int1 = " + Int1.ToString + " and Int2 = " + Int2.ToString End Su End Clas Public Class ChildClas Inherits ParentClas Public Sub New( Int1 = Int2 = 1 System.Console.WriteLine("Child Class Constructor is called and Int3 = " + AddXY().ToString End Su Public Function AddXY() As Intege Return (Int1 + Int2 End Functio End Clas Sub Main( Dim CC As ChildClass = New ChildClas System.Console.ReadLine( End Su End Modul > On the heap dump, I saw the a memory area of 20K with name Module1/Childclass. But I honestly disagree with you that that is a complete object of the child class. It >is just a memory area with variable name and nothing else. When I used !Obja (object reference #), I did not see any thing either. Did you happen to do "!DumpObj" of the single childclass instance when the debugger was stopped within the parent constructor? It shows: Name: VBCrypt.Module1/ChildClass MethodTable 0x007f5380 EEClass 0x06f133b0 Size 20(0x14) bytes mdToken: 02000004 (C:\Code\VBCrypt\bin\VBCrypt.exe) FieldDesc*: 007f5348 MT Field Offset Type Attr Value Name 007f5300 4000001 4 System.Int32 instance 0 Int 007f5380 4000002 8 System.Int32 instance 0 Int2 007f5380 4000003 c System.Int32 instance 0 Int3 That is a complete object. All the information is there of the childclass, including initial values of 0 with their member names. When you start adding initialization code within parent and child constructors, all you are doing is setting the values of the members to something other than the CLI mandated initial values, nothing more. The object is fully created. > Hi Avon; > [quoted text clipped - 44 lines] > > End Module I did the !DumpObj (addr) and got "Unmanaged Object" reply. Did I do somethng wrong You probably didn't type in the correct address of the object. When the debugger has stopped, and you are in the managed thread, do "!DumpStackObjects".This will show you all objects on the stack. The middle column "Objects" has the address of the object. Now do !DumpObj with that memory address and you will see a full child object. In my debugger examples, I have proved without a doubt that before the parent constructor is finished running, and in one test before the parent constructor even gets called, that: 1) Space for the ChildClass is allocated in managed memory. 2) That all the CLR data structures of ChildClass are initialized and user visible memory is zeroed. The debugger shows 1 and 2 are finished, I can see the member variables, their addresses and their initial zeroed memory. And the fact that the constructors don't have to do any initialization logic, that object is a fully created ChildClass object. Also do you realize when creating an object it perfect legitimate to accept the defaults of the runtime if the initial default values meet your requirements? You do not have to supply any constructor code to start using the member variables of the ChildClass instance. Matter of fact its common knowlegde that its senseless and a performance no-no to reinitialize members to their default values set by the runtime. In your response to Jon you wrote "Can you confidently say that an object of the child class has been instantiated when the values of its instance variables are not initialied by the constructor ?" Not only am I confident in saying yes, I proved it. Way back in this thread, your statement that started this argument was "right after the first constructor got called and before the CLR writes the drived class data into memory, you have an memory contains the parent class data only, that snap shoot of the meory is an object, and it is the object of the parent class.". I have shown this is absolutely false. Do you still stand by this statement? You have yet to come up with any evidence that even comes close to supporting this statement. If you still stand by this statement , please show me with the debugger tthat what you stated is true. More recently you argued "I honestly disagree with you that that is a complete object of the child class. It is just a memory area with variable name and nothing else". I have just proved this false also. I would like to put an end to this argument sometime in the near future. Please provide hard proof to support your arguments. > I did the !DumpObj (addr) and got "Unmanaged Object" reply. Did I do somethng wrong ? > In your response to Jon you wrote "Can you confidently say that an object of > the child class has been instantiated when the values of its instance > variables are not initialied by the constructor ?" Not only am I confident > in saying yes, I proved it. Oops.. I meant to say I concur with Jon: "I can confidently say that an object is an instance of the child type before the code specified for the constructor has been run." > You probably didn't type in the correct address of the object. When the > debugger has stopped, and you are in the managed thread, do [quoted text clipped - 45 lines] > > I did the !DumpObj (addr) and got "Unmanaged Object" reply. Did I do > somethng wrong ? I saw the data in the dump of !DumpObj. The fact that there is an address for the method table does not mean that all method data in the class chain are already stored in the table. Can you dump the content of the method table to see what is inside Also when the degugger stopped in side the code of Parent Construcor, the CLR already finished callingg the claas Object 's default constructor. How do you know that the method table contains anything else other than the 8 methods of the Object class ? You asked evidence to support what I said in my earlier posts. Well I do not not have physcial evidence, but I do have document to against your theory that on object is created even before any object constracor is called. The folloiwing is the quote form MSDN trainning document "It is important to realize how closely new and instance constructors collaborat to create objects. The only purpose of new is to acquire raw uninitialize memory. The only purpose of an instance constructor is to initialize th memory and convert it into an object that is ready to use. Specifically, new i not involved with initialization in any way, and instance constructors are no involved in acquiring memory in any way".(p.442 C# Programing for the Mocrosoft.ne MSDN Training Avon, I appreciate your taking time sharing your knwoledge with everyone who is interested in this subject. But please do not feell obligated to answer my questions, I do not intend to argue with any of you, so if you want to "put an end to this argument ", you can do so anytime. I am just trying to understand the process of object creation, so long as I am not convinced , I still can ask questions in this forum with or without your inputs. > I saw the data in the dump of !DumpObj. The fact that there is an address for the method table does not mean that all method data in the class chain are already stored in the table. Can you dump the >content of the method table to see what is inside? > Also when the degugger stopped in side the code of Parent Construcor, the CLR already finished callingg the claas Object 's default constructor. How do you know that the method table contains >anything else other than the 8 methods of the Object class ? I added a method to ChildClass and I did a "!DumpMT" (Dump Method Table) within the parent constructor. The new method is there, so yes I can see whats inside. All the ChildClass information is there. All the methods, all the member variables. Everything. >MSDN trainning document This isn't really a reference document you should be quoting. Here is a quote from the CLI standard: "Creating a new value of an object type by invoking a constructor involves the following steps in order: 1) Space for the new value is allocated in managed memory 2) VES data structures of the new value are initialized, and user visible memory is zeroed 3) The specified constructor for the object type is invoked. Inside the object constructor, the object type may do any initialization it chooses, possibly none." My examples have shown without a doubt 1) and 2) get done even before the Child and Parent class constructors finish. The only thing left is initialization logic inside the constructors and quoting the spec there doesn't have to be any. So if there is no initialization logic then 1) and 2) is a finished object. Here is another test to try. Especially look at the parent constructor. If the ChildClass, and its memory, and its method table did not exist, how can the parent class constructor get away with this? Module Module1 Public Class ParentClass Public Int As Integer Public Sub New() CType(Me, ChildClass).Int3 = 5 CType(Me, ChildClass).Int2 = 10 CType(Me, ChildClass).SomeSub() End Sub End Class Public Class ChildClass Inherits ParentClass Public Int2 As Integer Public Int3 As Integer Public Int4 As Integer Public Sub New() End Sub Public Sub SomeSub() Dim someTemp as Integer = 20 Int4 = 15 End Sub End Class Sub Main() Dim CC As ChildClass = New ChildClass End Sub End Module >so long as I am not convinced , I still can ask questions in this forum with or without your inputs. I apologize. But you did not ask a question, you made a bold statement with no proof to back it up. I like a good technical discussion but I keep providing different hard evidence you can try that points to the contrary of your initial statement, and you keep shooting it down with nothing in return or to back it up except your own opinions and a quote from a MSDN Training document (which I don't think proves your point). You should be relying on hard evidence when making such a stand and if you don't have any I really don't understand how you can make such a stand. So I'm sorry, but I feel this is one way conversation and am getting frustrated, and I realize I shouldn't, I'm just stating my feelings. All I ask is please explain why I can see ChildClass with all its members and methods and type information within the parent constructor which absolutely contradicts your initial statement "right after the first constructor got called and before the CLR writes the drived class data into memory, you have an memory contains the parent class data only, that snap shoot of the meory is an object, and it is the object of the parent class." Also please explain why the above ParentClass contructor can work? I only ask these to questions. A. > I saw the data in the dump of !DumpObj. The fact that there is an address for the method table does not mean that all method data in the class chain are already stored in the table. Can you dump the content of the method table to see what is inside? > Also when the degugger stopped in side the code of Parent Construcor, the CLR already finished callingg the claas Object 's default constructor. How do you know that the method table contains anything else other than the 8 methods of the Object class ? > You asked evidence to support what I said in my earlier posts. Well I do not not have physcial evidence, but I do have document to against your theory that on object is created even before any object constracor is called. The folloiwing is the quote form MSDN trainning document : > "It is important to realize how closely new and instance constructors collaborate > to create objects. The only purpose of new is to acquire raw uninitialized [quoted text clipped - 5 lines] > > Avon, I appreciate your taking time sharing your knwoledge with everyone who is interested in this subject. But please do not feell obligated to answer my questions, I do not intend to argue with any of you, so if you want to "put an end to this argument ", you can do so anytime. I am just trying to understand the process of object creation, so long as I am not convinced , I still can ask questions in this forum with or without your inputs. I did !DumpStackObjects and then !DumpMT. I did not see any thing came out here is the printout from the debug window 0:000> !dumpstackobject ESP/REG Object Nam 0012f308 0506a48c DumpTest.Module1/ChildClas 0012f328 0506a7b4 System.Reflection.Assembl 0012f444 0506a48c DumpTest.Module1/ChildClas 0012f44c 0506a4a0 System.String Child Class Constructor is called and I 0012f450 0506a48c DumpTest.Module1/ChildClas 0012f670 0506a48c DumpTest.Module1/ChildClas 0012f684 0506a48c DumpTest.Module1/ChildClas 0:000> !dumpmt 0506a48 No export dumpmt 0506a48c foun 0:000> !dumpm Missing MethodTable addres 0:000> !dumpmt 0506a48 No export dumpmt 0506a48c foun 0:000> !dumpMT 0506a48 No export dumpMT foun I appreciate if you will point out what is the difference between what I did and and yous <This isn't really a reference document you should be quoting. Here is < quote from the CLI standard I am puzzled by what you said here. Why should not I quote from MSDN, instead I should quote from CLI standard ? Do you mean the quote I gave from the MSDN is incorrect ? Or simple becasue you do not like the content of the quote, becuase it contradicts what you said in your earlier posts Moreover the quote you gave from the CLR standard "Creating a new value of an object type by invoking a constructor involves.....", aslo indicates that constructor invoking is needed for the creation of the new object, that is also against what you said in your previous posts that an object is created even before any constructors is called >..you keep shooting it down with nothing in retur or to back it up except your own opinions and a quote from a MSDN Trainin document (which I don't think proves your point) There are at least two kinds of proofs I know exist in the social and natural sciences, proof by experiemnts, and proof by logical induction. My reasoning was, and still is, based on assumption that MSDN quote I gave is correct, and based on the fact that, constructors invoking starts from the constructor of the derived class, all way up to the base class constructor (Object then coming back to the constructor of the derived class (like a round trip, you can prove that by stepping through the codes in VS IDE ). Each consctrucor is responsible for creating the objec of the class where the construcor is belonged to (based on my interpretation of the MSDN quote) and since the parent class's construcor finishes the call before the child class(by finishing, I mean all codes in the construcotr are run through, or all instance variables are correctly initialize ), I can say that the object is created before the object of the child class. You may not like this logic, or you may be able to prove the logic is wrong, but do not say again that I did not give you any "evidence > stepping through the codes in VS IDE ). Each consctrucor is responsible > for creating the object [quoted text clipped - 8 lines] > this logic, or you may be able to prove the logic is wrong, but do not say > again that I did not give you any "evidence" The problem is that you overestimate the role of the instance constructors, don't forget that they are optional, their primary role is to set the initial state of the object when you want this to be different from the default state (all fields 0). But their role is not to create an instance of their class. To illustrate this, I changed your program a bit, I extended the hierarchy by adding a GrandParent class with only a single int field. From the ParentClass ctor, I call a method (Foo) in ChildClass and I assign a value to all fields including the GrandParent's field someInt. Just run the program and watch the ouput. As you see, frield 'someInt' can be assigned a value, before it's class ctor has run. And if you still have some doubts, dump the IL using ildasm, remove the GrandParent ctor call from the ParentClass ctor and re-assemble the IL file using ilasm, run the .exe and watch the ouput being the same as with the ctor call. Module Module1 Public Class GrandParent Public someInt As Integer End Class Public Class ParentClass Inherits GrandParent Public Sub New() System.Console.WriteLine("Parent Class Constructor is called") Foo() End Sub Overridable Public Sub Foo() End Sub End Class Public Class ChildClass Inherits ParentClass Public Int1 As Integer Public Int2 As Integer Public Int3 As Integer Public Sub New() Int3 = someInt + AddXY() System.Console.WriteLine("Child Class Constructor is called and Int3 = " + Int3.ToString()) End Sub Public Function AddXY() As Integer Return (Int1 + Int2) End Function Overrides Public Sub Foo() int1 = 111 int2 = 222 someInt = 333 System.Console.WriteLine("In Foo Int1 = " + Int1.ToString() + " Int2 = " + Int2.ToString() + " Int3 = " + Int3.ToString()) End Sub End Class Sub Main() Dim CC As ChildClass = New ChildClass() End Sub End Module Willy. > I appreciate if you will point out what is the difference between what I did and and yous. When you do the !DumpObj on the ChildClass instance, in all that information, there is an address of the method table. Put that into !DumpMT -MD. > Moreover the quote you gave from the CLR standard "Creating a new value of an object type > by invoking a constructor involves.....", aslo indicates that constructor invoking is > needed for the creation of the new object, that is also against what you said > in your previous posts that an object is created even before any constructors is called. I never had a problem with this statement, at least I never meant to give that indication. I do have a problem with your statement that a parent object is created in memory before a child object. I stated that the runtime creates only one instance of child type right off the back, that it never creates a parent object, and before any constructors are called, that one child instance already exists and is initialized with defaults. Thats what this whole discussion is about, at least thats what I thought. > I am puzzled by what you said here. Why should not I quote from MSDN, > instead I should quote from CLI standard ? Do you mean the quote I gave from the MSDN > is incorrect ? Or simple becasue you do not like the content of the quote, becuase it > contradicts what you said in your earlier posts ? Its not a reference document. You said its a training document. The CLI mandates steps that runtimes like the MS CLR implementation must abide. Bust as an old Zen saying goes, " a finger pointing to the moon is not the moon". Both documents are open to interpretation, and as a matter of fact multiple runtimes can implement object creation steps in each own unique way. Thats why when this question was asked, it was important to investigate the MS CLR implementation to see what its actually doing to fulfill object creation. I'm going to reiterate the problem that I'm trying to address because it may not be clear anymore. The original question way back at the very beginning of this thread was does the runtime create two objects or one. I take this as physical creation by the runtime not logical creation. When you say "Each constructor is responsible for creating the object of the class where the construcor is belonged to (based on my interpretation of he MSDN quote), and since the parent class's construcor finishes the call before the child class(by finishing, I mean all codes in the construcotr are run through, or all instance variables are correctly initialized), I can say that the object is created before the object of the child class. ", I consider this logical creation, not physical creation, and its definitely not what the runtime is doing. I'll even admit that there is nothing wrong in thinking this from a logical point of view. But I submit the original message was asking about physical creation within the runtime not logical creation. Thats what I have set out to prove. I have given debugging examples that before single constructor of parent class or child class is completed, there is only one object in memory and thats a child object. Again, I submit the code below and please respond to this if you think at the time of the parent constructor there is only the parent object in memory. I ask if there is only one object in memory at the parent constructor, and that object is a parent object, then how does this parent constructor work? Module Module1 Public Class ParentClass Public Int As Integer Public Sub New() CType(Me, ChildClass).Int3 = 5 CType(Me, ChildClass).Int2 = 10 CType(Me, ChildClass).SomeSub() End Sub End Class Public Class ChildClass Inherits ParentClass Public Int2 As Integer Public Int3 As Integer Public Int4 As Integer Public Sub New() End Sub Public Sub SomeSub() Dim someTemp as Integer = 20 Int4 = 15 End Sub End Class Sub Main() Dim CC As ChildClass = New ChildClass End Sub End Module > I did !DumpStackObjects and then !DumpMT. I did not see any thing came out here is the printout from the debug window: > 0:000> !dumpstackobjects [quoted text clipped - 45 lines] > ), I can say that the object is created before the object of the child class. You may not like > this logic, or you may be able to prove the logic is wrong, but do not say again that I did not give you any "evidence" > Also when the degugger stopped in side the code of Parent Construcor, > the CLR already finished callingg the claas Object 's default constructor. > How do you know that the method table contains anything else other > than the 8 methods of the Object class ? Because if you ask for the type of the object (using GetType()) it will return the child type, so it therefore has the other methods. You can even call those other methods, which you wouldn't be able to do otherwise. For instance: using System; public class Base { public Base() { ((Derived)this).DoSomething(); } } public class Derived : Base { public void DoSomething() { Console.WriteLine ("I'm derived"); } } public class Test { static void Main() { new Derived(); } } How do you explain that working? Note that if you change the constructor call to "new Base()" you get a cast exception. This clearly shows that even in the Base constructor, there is a difference between a Derived object and a Base object.  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Anon, Jon, and Willy I thought to give you guys a holiday brake so I did not answer your latest posts earlier : Anon ,thanks for letting me know how to dump method table. I was able to se what is inside the MT. But I am troubled by what I saw. In my test, the parent class contains an instance variable and a public methods, called WrteString(). In the child class, It contains instance variables and one method variable and one public method called AddXY(). I put debug point at the Child Class's constructor (not inside) "Public Sub New()", Here is what I saw in the MT 0:000> !dumpmt -MD 0x009053c EEClass : 00c533b Module : 0016668 Name: DumpTest.Module1/ChildClas mdToken: 02000004 (C:\TEMP\DumpTest\bin\DumpTest.exe MethodTable Flags : 8000 Number of IFaces in IFaceMap : Interface Map : 0090540 Slots in VTable : ------------------------------------- MethodDesc Tabl Entry MethodDesc JIT Nam 79b7c4eb 79b7c4f0 None [DEFAULT] [hasThis] String System.Object.ToString( 79b7c473 79b7c478 None [DEFAULT] [hasThis] Boolean System.Object.Equals(Object 791f4a07 791f4a0c None [DEFAULT] [hasThis] Boolean System.Object.Equals(Object 79b7c52b 79b7c530 None [DEFAULT] [hasThis] Void System.Object.Finalize( 009053ab 009053b0 None [DEFAULT] [hasThis] Void DumpTest.Module1/ChildClass..ctor( 009053bb 009053c0 None [DEFAULT] [hasThis] I4 DumpTest.Module1/ChildClass.AddXY( yes it contains the Child Class's AddXY() method, Yes it contains 3 variables. But where ar the parent class's variables and methods ? ... Is there a pointer some where pointing to anothe method table If indeed that that is all data in the memory of the "Object", I do not think you can call it as instance of ChildClass, becasue the ChildClass is supposed to be inherited from the ParentClass not directly from Object class (by the way, where are other Object class's methods? I thought there are at least 7 (8 becuase one method, believe to be .Equals method, is overloaded). som of you said that .GetType method show it is childclass type, after seeing the MT content, you shoul know why you could at that point Anon, I agree with you that it is usefull to look back to where our debate started or where our opinio started to diverge so that we will not be carried away too from the origin. In the course of this discusison, I basically made 2 points 1) "Nothing wrong to say An Object of parent class is created whenever an object of its child class has been created, becuase every object of the child class is an object of the parent class I hope I am right on this point, at least no one has said anythng aginst 2) "not only the parent object is created, it is created before the object of the child class That is where many of you started jumping on me. In the last two posts, I spelled out my reasoning for saying so. So far, no one has proved, not even have said, that my logic is wrong. IF, that is IF my logic is is right, but the conclusion is wrong , then it has to be the assumption where my logic is based upon is wrong,i.e. Microssoft, once again, misled me, probably many others, with wron informatin. But none of you so far had said anything that I quotation I cited from MSDN is wrong One weak point in your arguments, and others, is that you think an instance(object) of the child clas is already in the memory after new (class) code is run, your arguments is that you can se the all class members of the child class in the MT and object dump, although the instance variables are still at default values. yes, you may have an object of some sort in the memory, but it may well be tha the obeject is still in wrong state, i.e. not ready to be used Take classical Circle class as example, the class contains an instance variable PI, say the value i 3.14. It also contains a method Area() with Radius as passing parameter, can you use that Circl object in any meanful way when PI is still initialized as 0 When most poeple, including me, talk about an object of a class has been instantiated, we usuall mean that the object is ready to be used, or object is already in good state.yet you keep saying that an object of the child class has been created, even you know that it is still in a wrong state, I believe that is one of our major difference in the whole discussion > 2) "not only the parent object is created, it is created before the > object of the child class" > > That is where many of you started jumping on me. In the last two > posts, I spelled out my reasoning for saying so. So far, no one has > proved, not even have said, that my logic is wrong. Okay, well, I'll do so now if I haven't before. There is only one object which is created. It is created as a child object immediately. There is no intermediate stage at which it is an instance of the parent object but not the child object. You certainly haven't shown that there is such a stage, and I've demonstrated that during the code for the constructor in the parent it's certainly an instance of the child. So, when do you believe it is an instance of the parent but not the child? > One weak point in your arguments, and others, is that you think an > instance(object) of the child class is already in the memory after new [quoted text clipped - 3 lines] > object of some sort in the memory, but it may well be that the obeject > is still in wrong state, i.e. not ready to be used. That doesn't mean it's not an instance of the child class. It's an instance of the child class in that: o It has the vtable of the child class o It has the variables of the child class o Calling GetType on the instance (and if there were no instance, wouldn't that call fail entirely?) returns the type of the child class Uninitialised != non-existant > Take classical Circle class as example, the class contains an instance > variable PI, say the value is 3.14. It also contains a method Area() > with Radius as passing parameter, can you use that Circle object in > any meanful way when PI is still initialized as 0 ? Yes - you can initialise PI, which you wouldn't be able to do if the object hadn't been created. (Any decent circle class wouldn't have Area as a method which *took* a radius - the radius would be part of the circle's instance data, IMO.) > When most poeple, including me, talk about an object of a class has > been instantiated, we usually mean that the object is ready to be > used, or object is already in good state.yet you keep saying that an > object of the child class has been created, even you know that it is > still in a wrong state, I believe that is one of our major difference > in the whole discussion. The object must be created before its variables are initialised, otherwise the variables aren't availbale to be initialised. If that weren't the case, you would be claiming that during the code for a constructor, no object has been created at all - in which case, what does "this" refer to? Where would we be storing the variables if the object hadn't been created? SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too > yes it contains the Child Class's AddXY() method, Yes it contains 3 variables. But where are > the parent class's variables and methods ? ... Is there a pointer some where pointing to another > method table ? When I set a break point at the beginning of the child constructor and do !DumpObject I do see parents member variables, so they are there already. As for the methods, I set a break point at the beginning of the child constructor and after the full creation of the object (after the new ChildClass statement) and it doesn't show them in either situation. So it looks like the debugger does not traverses the type linked list completely to show all methods available. It only shows the VTABLE entries. There is probably a way to do the traversal but unfortunately I don't have time at the moment to play around with it. I'm not ignoring this but I will get back to this at some point... > 1) "Nothing wrong to say An Object of parent class is created whenever an object of its child class > has been created, becuase every object of the child class is an object of the parent class" > > I hope I am right on this point, at least no one has said anythng aginst. I absolutely do not agree with this statement. When you do a New ChildClass, when its totally completed and the caller has the reference, there is only one object on the heap. Allocation profiler tool proves this. I would change your statement "every object of the child class is an object of the parent class" to "every object of the child class is a TYPE of the parent class", there is a huge difference! What you say tends to indicate that there are two objects, and saying this to lesser experience developers will confuse them. There is not two objects. > One weak point in your arguments, and others, is that you think an instance(object) of the child class > is already in the memory after new (class) code is run, your arguments is that you can see > the all class members of the child class in the MT and object dump, although the instance variables are still > at default values. yes, you may have an object of some sort in the memory, but it may well be that > the obeject is still in wrong state, i.e. not ready to be used. Its not a weak point, you are confusing what I was are arguing. Yes the object is in the incomplete initialization state, I never argued that, we even said that the object is not done being initialized. But the fact that the parent constructor can use all of the childs methods and members, and those values and method calls work and retain the values, means that a complete child instance does exist at that point in time. Willy, Jon, and I have repeatedly seperated the idea between initialization and instantiation. > That is where many of you started jumping on me. In the last two posts, I spelled out my reasoning > for saying so. So far, no one has proved, not even have said, that my logic is wrong. IF, that is IF, > my logic is is right, but the conclusion is wrong , then it has to be the assumption where my > logic is based upon is wrong,i.e. Microssoft, once again, misled me, probably many others, with wrong > informatin. But none of you so far had said anything that I quotation I cited from MSDN is wrong. Here your interpretation of the quote again: "constructors invoking starts from the constructor of the derived class, all way up to the base class constructor (Object) then coming back to the constructor of the derived class (like a round trip, you can prove that by stepping through the codes in VS IDE ). Each consctrucor is responsible for creating the object of the class where the construcor is belonged to (based on my interpretation of the MSDN quote)," The main error in your statement is each constructor IS NOT responsible for creating the object of the class where the constructor is belonged to, its responsibility is to INITIALIZE the members of the class where the constructor is belonged to. And according to the spec, the constructor is not required to do even that. Go back to step 3 of the CLI spec, "3) The specified constructor for the object type is invoked. Inside the object constructor, the object type may do any INITIALIZATION it chooses, POSSIBLY NONE.", this shows the constructor is used for initialization and not object creation. > When most poeple, including me, talk about an object of a class has been instantiated, we usually > mean that the object is ready to be used, or object is already in good state.yet you keep saying > that an object of the child class has been created, even you know that it is still in a wrong state, > I believe that is one of our major difference in the whole discussion. I agree with this statement. But I wasn't ever arguing this point, I was arguing "is there one or two objects created by the runtime when new ChildClass is called". Even so, if this is the new argument we are looking at, then when the object is being ready to be used, how many objects exist at that point? One. What type of object is it? ChildClass. If you cannot call it a full object until the call to "New ChildClass" pushes the reference to the newly created object onto the stack to be returned to the caller, can you say the parent object ever existed if all the user and the runtime ever sees and uses is a reference to the new childClass object? Thats an emphatic No. The only way you could say yes to this is, after the call to New ChildClass, there physically existed one ChildClass Object and one ParentClass Object, which is not true. > Anon, Jon, and Willy; > [quoted text clipped - 5 lines] > an instance variable and a public methods, called WrteString(). In the child class, It contains > instance variables and one method variable and one public method called AddXY(). I put debug point at the Child Class's constructor (not inside) "Public Sub New()", Here is what I saw in the MT: > 0:000> !dumpmt -MD 0x009053c8 > EEClass : 00c533b0 [quoted text clipped - 57 lines] > that an object of the child class has been created, even you know that it is still in a wrong state, > I believe that is one of our major difference in the whole discussion. Inline **** Willy > Anon, Jon, and Willy; > [quoted text clipped - 41 lines] > where pointing to another > method table ? *** - Where do you see 3 variables? Variables (fields) are in the GC heap they are the object state, they are not in the MT. What you look at here is a dump of the MD table, but the debugger breaks too early (SEE JIT none for Object methods) so I wonder where you set your breakpoint. Another point you should take care of is that what you see here is a dump made by the sos.dll debugger extention, and the info shown doesn't reflect the real structures of the MT and MD tables, if you want to go that level you need to look at the structures themself, but for this you will need the source code of the CLR. - And yes the MT of the ChildClass has a pointer to the parent's class MT, as I told you mamy times before, what is shown with the !dumpMT command is NOT the complete MT, it's only a part of the type descriptor structure constructed by the class loader, before the object instance gets created. > If indeed that that is all data in the memory of the "Object", I do not > think you can call it *** NO, it isn't all the data of the object, again you have to make a clear distinction between: -a) the instance of a class (the object STATE, the object data .... you name it), this is what in general is called an object. The object (state) is in strored in the GC heap -b) the class type (the objects associated BEHAVIOR,, the methods), the object's behavior (Method table, Method descriptors etc...) is defined by the class implementation, but this info is not stored in the GC heap, this info (a number of structures) is laid-out by the class loader when the type was loaded for the first time, and, as was said before there is only one such info available per type (class) in the hierachy, irrespective the number of object instances of that type (YES all method Table pointers of all objects of the same type will point to the same MT). Once the type info structures are loaded/initialized in memory, and the methods are JITted, they remain there, mapped at the same memory location, even if no object instance of that type exists in the GC heap. In oder to look at the object itself (instance of ChilClass), you should start with a !DumpstackObjects command, take the address of the object ChildClass object and issue a dumpobj <addr>, and look at the instance data. Take a look at the adress to the MT in the header (first word in object data). AND issue the command !ObjLength <addr>, you will see that the lenght corresponds to the sum of the length of all fields of all classes in the hierarchy. > as instance of ChildClass, becasue the ChildClass is supposed to be > inherited from the ParentClass, [quoted text clipped - 42 lines] > but it may well be that > the obeject is still in wrong state, i.e. not ready to be used. *** NO, my argument is that I can see the objects member fields in the GC heap, "application" state is not initialized, but here you assume that you need to run the ctor's to set the "default" state which is wrong, you can have empty ctor's , or you can initialize the state by calling a method. don't you. From the CLR point of view, once the object exists on the GC heap (initialized to 0) and the next free object pointer in the GC heap is pointing to the address behind this object, this is a real life object, it can be moved collected removed etc. But this was not the point by which this all started, the point was that you said an object was constructed by instanciating each object type separately starting from the top (Object) up to the most derived by calling the ctor's of each individual type in sequence top -> bottom, well this I say is wrong. **** Again you are looking at the wrong data, the member fields are in the GC heap, see above. > When most poeple, including me, talk about an object of a class has been > instantiated, we usually [quoted text clipped - 3 lines] > is still in a wrong state, > I believe that is one of our major difference in the whole discussion. What do you define as in a wrong state, application state? (fields initialized to a non default state) or valid CLR state? (fields contain default values), you keep pretending that an object is created in stages by calling instance ctor's starting from the Object class to the most derived one, an that this is done by the ctor calls, but this is wrong. It's in no way a requirement that Application state be initialized in the ctor. And calling the Object (top most class) ctor is a NOP, as the object carries no state at all. In a previous post I included a sample in which I initialized the fields in a method called from the base constructor, not in the ctor itself. Heck I even removed the ctor call (in IL) to the parent's ctor and still the object was there and the program running normally. ----------------------------------------- First let me make clear once for all, in this course of the discusison, I never said tha two "seperate objects" were created, I challenge any of you to find my original posts and let others who might have not seen the earlier discussion to see what my position or opinion is on this issue, that is if by "separate objects", you meant that two distinct memory area I have been saying that after the memory of the child class has been allocated o designated, within that same memory area, object of the parent class exists and it is created before the object of the child class instantiation is completed for the reasons I stated in the last threereplies I did not know that Anon had problem with the statement that "every object of a child class is also an object of its parent class". When I first made the statement, you response was "If you are viewing it from VB.NET/C# point of view and the fact that you ca cast an object to one of its parent types then yes I'd agree with you. I looks like two different objects exists and have been created So I thought you are OK with the statement. But since now you objected it, Let me say that I am OK with your suggestion to replace the words "object of a class" with "Type of a class". Personally, I think two phases are interchangeable and the formal i more commonly used in the media. Even yourself said many times that you had an object of child class in the memory, when I asked you whether you are confident to sa so, you said that you agreed with Jon that the object is "type of the child class". Then means that you did not use the term consistently yourself. I believe if the true value of "is" operator is guaranteed for a reference type (here I am talking "is" operator in C#, not VB.Net, the "is" operator has different meanings in the two languages), such as in the relationship between child and parent classes, for every object e of child class (e is Parent Class) is always true (actually compiler complains in such cases),then that object is an object of the parent class. It happens there is another Keyword TypeOf , when you say e is type of child class, in some cases the listeners will be confused with the keyword TypeOf, for that reason I still believe that "is an object" is a better words to be used. But anyway, I am OK with your terminology, so long as we all understand what it means. As for whether an object of child class is created "immediately" ( I interpreted Jon's "immediately' as right after new (class) is run but before the CLR loader calls the instance constructor), I said no, three of you think yes. I backed up my claim with MSDN document, you guys even could not find any official document to support your claim that an object of the child class is created before any constructor is called. Anon, cited the CLR standard, but the standard mentioned that constructor invoking is involved in the object creation. I even found a book by Jeffrey Richter titled "Applied Microsoft .NET Framework Programming", he also described what the new key word does when it is used to created new object, it basically said the same thing as in the quotation I cited from MSDN, 1) it allocates memory 2) It initializes the object’s overhead members (a point to the MT and creates SyncBlockIndex for object management purpose) 3) It calls instance constructor. Again it is against all of your opinion. I also visited Sun's web site to check what it says about the process of object creation in Java. In one page, it states that the sole purpose of a constructor is to create instance of class. I could not found a single source which supports you guy's claim. Then on debugging side, I did not see a MT table which contains all methods, including the methods inherited from the parent classes, Jon totally ignore that fact, Willy said that it is there it is just not in the dump, well, I do not think any one will buy black hole type of argument, and Anon indicated that further research is needed to find out. Therefore you did not provide any physical evidence either to back up your claim Even IF you guys are right that an object of the child class is already created in the memory before the CLR invoking any constructors, then it has to be the new key work triggs runtime to perform all the object creation task, that is in direct contradiction to the MSDN quotation I cited before, yet none of you has gut to say that MSDN is wrong ,and that the new key word does much more than what it is stated in the document. Are you afraid that you will loss MVP title if you declare that MSDN made false statement? oh you do not dare to say because you are not sure whether you are right ? To me, all the time you are barking at wrong tree when you tried to disprove my points Instead of focusing your arguments to address those key points in our discussion, some of you prefer to make some cheap shoot instead, like "any decent circle class will have...", Well, I used that to illustrate a point, not to make "a decent" class. I did not see any "decent class" came out your sample codes either. Besides, there is no such standard for a "decent class", any class serves author's purpose is decent to me > I have been saying that after the memory of the child class has been > allocated or designated, within that same memory area, object of the > parent class exists and it is created before the object of the child > class instantiation is completed for the reasons I stated in the last > threereplies. And it's that "before" that you have entirely failed to back up, whereas the rest of us have given ample (IMO) evidence that no, the memory for the child class is all set up in one block, at the same time as the memory for the parent class (it's just one lump of memory). > As for whether an object of child class is created "immediately" ( I > interpreted Jon's "immediately' as right after new (class) is run but > before the CLR loader calls the instance constructor), I said no, > three of you think yes. I backed up my claim with MSDN document ... which we believe you're misinterpreting. > you > guys even could not find any official document to support your claim > that an object of the child class is created before any constructor is > called. If it weren't, what object would the child class operate on? > Anon, cited the CLR standard, but the standard mentioned that > constructor invoking is involved in the object creation. Here's another quote from the CLR standard: partition III, newobj instruction call: <quote> The newobj instruction allocates a new instance of the class associated with "constructor" and initializes all the fields in the new instance to 0 (of the proper type) or null as appropriate. It then calls the constructor with the given arguments along with the newly created instance. </quote> That seems pretty straightforward and definitive to me. > I even found > a book by Jeffrey Richter titled "Applied Microsoft .NET Framework [quoted text clipped - 4 lines] > SyncBlockIndex for object management purpose) 3) It calls instance > constructor. Yes - but note that *all* the members are created before the instance constructor is called, contrary to your previous statements. The object is already an instance of the child type before the instance constructor is called. > Again it is against all of your opinion. No, not at all. > I also visited > Sun's web site to check what it says about the process of object > creation in Java. In one page, it states that the sole purpose of a > constructor is to create instance of class. I could not found a single > source which supports you guy's claim. There is a difference between what people write for the benefit of teaching a language and the exact nature of what happens in a specification. People are often woolly, unfortunately. > Then on debugging side, I did not see a MT table which contains all > methods, including the methods inherited from the parent classes, Jon [quoted text clipped - 3 lines] > out. Therefore you did not provide any physical evidence either to > back up your claim. Yes, I ignored the method table business - I don't know the details of the method table enough, but my guess is that the child method table contains a pointer to the parent method table. That doesn't seem unreasonable. What *you* have consistently ignored is that you can't show *any* point at which only the parent members are available, you can't show any point at which if (this is Derived) would fail, you can't show any point at which a call to GetType() would return the base type rather than the derived type, and you can't show any point at which calling an overridden method would in fact only call the base version rather then overriding method. > Even IF you guys are right that an object of the child class is already > created in the memory before the CLR invoking any constructors, then [quoted text clipped - 6 lines] > are not sure whether you are right ? To me, all the time you are > barking at wrong tree when you tried to disprove my points. The new keyword inserts a newobj instruction in the stream. That instruction is responsible for creating and initialising an object - it creates the object *and* calls the constructor. That doesn't mean that the object isn't created *before* the constructor is called, and indeed my quote from the CLR spec shows very clearly that the memory is allocated, then initialized to 0, then the constructor is called. > Instead of focusing your arguments to address those key points in our > discussion, some of you prefer to make some cheap shoot instead, like > "any decent circle class will have...", Well, I used that to > illustrate a point, not to make "a decent" class. Why call it "Circle" at all if you weren't going to suggest a class which would ever actually fit that description? As for cheap shots, I suggest you reread the paragraph you wrote above. > I did not see any > "decent class" came out your sample codes either. Besides, there is no > such standard for a "decent class", any class serves author's purpose > is decent to me. Then what about my many "decent" example programs which you've entirely ignored? SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too >"If you are viewing it from VB.NET/C# point of view and the fact that you >can > cast an object to one of its parent types then yes I'd agree with you. It > looks like two different objects exists and have been created" I used the word looks. I did not say is two different objects. > Even yourself said many times that you had an object of >child class in the memory, when I asked you whether you are confident to [quoted text clipped - 4 lines] > I believe if the true value of "is" operator is guaranteed for a >reference type (here I am talking "is" operator in C#, not VB.Net, >the "is" >operator has different meanings in the two languages), such as in the >relationship between child and parent classes, for >every object e of child >class (e is Parent Class) is always true (actually compiler complains in >such cases),then that object is an >object of the parent class. It happens >there is another Keyword TypeOf , when you say e is type of child class, in >some cases the >listeners will be confused with the keyword TypeOf, for that >reason I still believe that "is an object" is a better words to be used. >But anyway, I am OK with your terminology, so long as we all understand >what it means. The object IS a type of ChildClass, ParentClass, and Object. But its one object instance, ChildClass. An object is an in-memory representation of a Class definition. An Object of one type cannot be an object of another. Once created its always an instance of that one type, and if you cast it or pass it to a method that accepts a ParentClass it doesn't stop being an Object of ChildClass. Just look at the reference in the debugger when this happens, it knows its still a ChildClass instance. Sometimes specific terminology is not needed and sometime it is, depends on the problem domain. When we are dealing with low level runtime object creation its of upmost importance to use the correct terminology. Any ambiguity would cause confusion and frustration which it clearly has. If we were sitting around discussing how to build a UI then I wouldn't have had a problem. > Then on debugging side, I did not see a MT table which contains all methods, >including the methods inherited from the parent classes, Jon totally ignore that fact, >Willy said that it is there it is just not in the dump, well, I do not think any one will >buy black hole type of argument, and Anon indicated that further research is needed >to find out. Therefore you did not provide any physical evidence either to back up > your claim. You totally ignored the fact I said it doesn't show them after the complete object is created either but it doesn't mean their not there either. But I can still call them in code. It doesn't prove with or against. Its just inconclusive. But answer me this, in the PARENT CONSTRUCTOR we have shown working examples where you can call parent/child methods and set/get parent and child members. If there is no method table at that point, how is the parent constructor accessing them? By magic? Thats more than enough proof that the method table does exist for child and parent class at that point. You have totally ignored this in all your responses. Please explain why this can happen? >I backed up my claim with MSDN document, you guys even could not find any >official document to support your claim that an object of the child class >is created before any constructor is called. BS. What the F*** is the CLI document!! Its the mother of all documents when making a common language runtime, its submitted to the ECMA. Even MS has to abide by this. Look at Richters that you quote, in the brackets is CLI spec steps: 1) it allocates memory [Space for the new value is allocated in managed memory] - Jon, Willy, and I PROVED that by the time the parent constructor is called the child memory is created with or examples. 2) It initializes the object's overhead members (a point to the MT and creates SyncBlockIndex for object >management purpose) [VES data structures of the new value are initialized, and user visible memory is zeroed] - Jon, Willy, and I PROVED that by the time the parent constructor is called the child's method tables are created because we were able to call the child's methods and use the child's members 3) It calls instance constructor.[The specified constructor for the object type is invoked. Inside the object constructor, the object type may do any initialization it chooses, possibly none.] - This is the last step and Willy gave you examples where there is no constructors and an object is still created. The constructor is not required, its only needed if the developer wants to initialize the members to something other than the defaults in step2. You have totally ignored this in your response too. Not to mention the quote Jon gave: <quote> The newobj instruction allocates a new instance of the class associated with "constructor" and initializes all the fields in the new instance to 0 (of the proper type) or null as appropriate. It then calls the constructor with the given arguments along with the newly created instance. </quote> These all totally back up our claim. If we misinterpreted this then we couldn't have shown you the code that we wrote. We provided code that coincides with exactly what we have been saying along with CLI/Richter. You have not provided any code the proves otherwise. The ball is in you court. >that is in direct contradiction to the MSDN quotation I cited before, >yet none of you has gut to say that MSDN is wrong ,and that the >new key word does much more than what it is stated in the document. OK. I think its wrong. It does contradict the CLI spec and if I was going to quote one or the other I would use the industry standard ECMA spec instead of an MSDN Training document. "The only purpose of new is to acquire raw uninitialized memory." I'd say this false the CLI spec says its to acquire the memory, set up the structure, and set the members to the defaults (0, null, whatever) "Specifically, new is not involved with initialization in any way" Again it contradicts the CLI spec. Operation on the keyword new does initialize everything to the defaults. "The only purpose of an instance constructor is to initialize the memory and convert it into an object that is ready to use." Again it constradicts the CLI spec because there doesn't have to be any initialization done. Look at Willy's example where he has a class with no constructor. Guess what, the object can be created with the new keyword without a constructor. So the MSDN training document is wrong. >Are you afraid that you will loss MVP title if you declare that MSDN made false statement? I have been coming to these news groups since the beginning and I have the upmost respect for Willy and Jon. I ask you to show them the same. I don't think Jon meant to insult you. > First let me make clear once for all, in this course of the discusison, I never said that > two "seperate objects" were created, I challenge any of you to find my original posts and > let others who might have not seen the earlier discussion to see what my position or opinion is on this issue, that is if by "separate objects", you meant that two distinct memory areas > I have been saying that after the memory of the child class has been allocated or > designated, within that same memory area, object of the parent class exists and it is created before the object of the child class instantiation is completed for the reasons I stated in the last threereplies. > I did not know that Anon had problem with the statement that "every object of a child class is also an object of its parent class". When I first made the statement, you response was: > "If you are viewing it from VB.NET/C# point of view and the fact that you can > cast an object to one of its parent types then yes I'd agree with you. It [quoted text clipped - 4 lines] > with "Type of a class". Personally, I think two phases are interchangeable and the formal is > more commonly used in the media. Even yourself said many times that you had an object of child class in the memory, when I asked you whether you are confident to say > so, you said that you agreed with Jon that the object is "type of the child class". Then means that you did not use the term consistently yourself. > I believe if the true value of "is" operator is guaranteed for a reference type (here I am talking "is" operator in C#, not VB.Net, the "is" operator has different meanings in the two languages), such as in the relationship between child and parent classes, for every object e of child class (e is Parent Class) is always true (actually compiler complains in such cases),then that object is an object of the parent class. It happens there is another Keyword TypeOf , when you say e is type of child class, in some cases the listeners will be confused with the keyword TypeOf, for that reason I still believe that "is an object" is a better words to be used. But anyway, I am OK with your terminology, so long as we all understand what it means. > As for whether an object of child class is created "immediately" ( I interpreted Jon's > "immediately' as right after new (class) is run but before the CLR loader calls > the instance constructor), I said no, three of you think yes. I backed up my claim with MSDN document, you guys even could not find any official document to support your claim that an object of the child class is created before any constructor is called. Anon, cited the CLR standard, but the standard mentioned that constructor invoking is involved in the object creation. I even found a book by Jeffrey Richter titled "Applied Microsoft .NET Framework Programming", he also described what the new key word does when it is used to created new object, it basically said the same thing as in the quotation I cited from MSDN, 1) it allocates memory 2) It initializes the object's overhead members (a point to the MT and creates SyncBlockIndex for object management purpose) 3) It calls instance constructor. Again it is against all of your opinion. I also visited Sun's web site to check what it says about the process of object creation in Java. In one page, it states that the sole purpose of a constructor is to create instance of class. I could not found a single source which supports you guy's claim. > Then on debugging side, I did not see a MT table which contains all methods, including the methods inherited from the parent classes, Jon totally ignore that fact, Willy said that it is there it is just not in the dump, well, I do not think any one will buy black hole type of argument, and Anon indicated that further research is needed to find out. Therefore you did not provide any physical evidence either to back up your claim. > Even IF you guys are right that an object of the child class is already created in the memory before the CLR invoking any constructors, then it has to be the new key work triggs runtime to perform all the object creation task, that is in direct contradiction to the MSDN quotation I cited before, yet none of you has gut to say that MSDN is wrong ,and that the new key word does much more than what it is stated in the document. Are you afraid that you will loss MVP title if you declare that MSDN made false statement? oh you do not dare to say because you are not sure whether you are right ? To me, all the time you are barking at wrong tree when you tried to disprove my points. > Instead of focusing your arguments to address those key points in our discussion, some of you prefer to make some cheap shoot instead, like "any decent circle class will have...", Well, I used that to illustrate a point, not to make "a decent" class. I did not see any "decent class" came out your sample codes either. Besides, there is no such standard for a "decent class", any class serves author's purpose is decent to me. Here are the steps for seeing ParentClass class information. I stopped the process right at the beginning of the ChildClass constructor. ParentClass constructor has not been called yet. 1) !DumpObj with ChildClass object address 2) Get the EEClass address 3) !DumpClass with ChildClass EEClass address 4) Get the ParentClass Address 5) !DumpClass with ParentClass address 6) Get the method table address 7)!DumpMT -MD with parent's method table address. There you go, all class information of the child and its descendants are built before the parent constructor is called. Please do not confuse class type information with object instance. By doing dump its clear that only a ChildClass instance is created, but all type information needed is built before constructors start. This supports Willy,Jon, Myself, and the CLI spec. > First let me make clear once for all, in this course of the discusison, I never said that > two "seperate objects" were created, I challenge any of you to find my original posts and > let others who might have not seen the earlier discussion to see what my position or opinion is on this issue, that is if by "separate objects", you meant that two distinct memory areas > I have been saying that after the memory of the child class has been allocated or > designated, within that same memory area, object of the parent class exists and it is created before the object of the child class instantiation is completed for the reasons I stated in the last threereplies. > I did not know that Anon had problem with the statement that "every object of a child class is also an object of its parent class". When I first made the statement, you response was: > "If you are viewing it from VB.NET/C# point of view and the fact that you can > cast an object to one of its parent types then yes I'd agree with you. It [quoted text clipped - 4 lines] > with "Type of a class". Personally, I think two phases are interchangeable and the formal is > more commonly used in the media. Even yourself said many times that you had an object of child class in the memory, when I asked you whether you are confident to say > so, you said that you agreed with Jon that the object is "type of the child class". Then means that you did not use the term consistently yourself. > I believe if the true value of "is" operator is guaranteed for a reference type (here I am talking "is" operator in C#, not VB.Net, the "is" operator has different meanings in the two languages), such as in the relationship between child and parent classes, for every object e of child class (e is Parent Class) is always true (actually compiler complains in such cases),then that object is an object of the parent class. It happens there is another Keyword TypeOf , when you say e is type of child class, in some cases the listeners will be confused with the keyword TypeOf, for that reason I still believe that "is an object" is a better words to be used. But anyway, I am OK with your terminology, so long as we all understand what it means. > As for whether an object of child class is created "immediately" ( I interpreted Jon's > "immediately' as right after new (class) is run but before the CLR loader calls > the instance constructor), I said no, three of you think yes. I backed up my claim with MSDN document, you guys even could not find any official document to support your claim that an object of the child class is created before any constructor is called. Anon, cited the CLR standard, but the standard mentioned that constructor invoking is involved in the object creation. I even found a book by Jeffrey Richter titled "Applied Microsoft .NET Framework Programming", he also described what the new key word does when it is used to created new object, it basically said the same thing as in the quotation I cited from MSDN, 1) it allocates memory 2) It initializes the object's overhead members (a point to the MT and creates SyncBlockIndex for object management purpose) 3) It calls instance constructor. Again it is against all of your opinion. I also visited Sun's web site to check what it says about the process of object creation in Java. In one page, it states that the sole purpose of a constructor is to create instance of class. I could not found a single source which supports you guy's claim. > Then on debugging side, I did not see a MT table which contains all methods, including the methods inherited from the parent classes, Jon totally ignore that fact, Willy said that it is there it is just not in the dump, well, I do not think any one will buy black hole type of argument, and Anon indicated that further research is needed to find out. Therefore you did not provide any physical evidence either to back up your claim. > Even IF you guys are right that an object of the child class is already created in the memory before the CLR invoking any constructors, then it has to be the new key work triggs runtime to perform all the object creation task, that is in direct contradiction to the MSDN quotation I cited before, yet none of you has gut to say that MSDN is wrong ,and that the new key word does much more than what it is stated in the document. Are you afraid that you will loss MVP title if you declare that MSDN made false statement? oh you do not dare to say because you are not sure whether you are right ? To me, all the time you are barking at wrong tree when you tried to disprove my points. > Instead of focusing your arguments to address those key points in our discussion, some of you prefer to make some cheap shoot instead, like "any decent circle class will have...", Well, I used that to illustrate a point, not to make "a decent" class. I did not see any "decent class" came out your sample codes either. Besides, there is no such standard for a "decent class", any class serves author's purpose is decent to me. Thanks. I did see the parent class's members when I put debug point at the childclass' new constructor (not inside). But when I tried to test what has been changed in MT by puting the debug inside the childclass's constructor (after reruning the VS IDE and winddg), I could not dump the MT table anymore. I got "No export dump found" , I did it multi times, it was the same result. Could you please let me what you think might be wrong ? I'm not ignoring your request. While I didn't get this problem, I'm trying to find a more "elegant" way of doing this. I will get back when I get some time to investigate. > Thanks. I did see the parent class's members when I put debug point at the childclass's > new constructor (not inside). > > But when I tried to test what has been changed in MT by puting the debug inside the childclass's constructor (after reruning the VS IDE and winddg), I could not dump the MT table anymore. I got "No export dump found" , I did it multi times, it was the same result. > Could you please let me what you think might be wrong ? > Thanks. I did see the parent class's members when I put debug point at the > childclass's [quoted text clipped - 5 lines] > found" , I did it multi times, it was the same result. > Could you please let me what you think might be wrong ? Yes, you made an error when entering the command, "No export dump found" means you typed !dump instead of !dumpmt. Willy. > To prove the contrary, I modified your classes so that the child class > contains a method and two instance varibles with values 5, and 10 and > then put degbug point at the parent class constructor, if you run the > EXE you will see t that point, the values of the instance variables are > not initialized to 5 and 10. That indicates that the instance of the > child class was not completed yet. No, it indicates (as has been explained several times before) that the code within the constructor hasn't been run yet. That doesn't mean that the member variables aren't there. You even say that "the values of the instance variables are not initialized to 5 and 10" - that suggests that the instance variables are *there*, doesn't it? You still haven't explained how your theory ties in with the other sample programs which have been posted which go against it. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too when you move the debug point to child class constructor, the values are initialized to 5 and 10 correctly. Here is the code: > Module Module1 > Public Int1 As Integer > Public Int2 As Integer > > Public Class ParentClass Not sure what you want to prove here, the variables Int1 and Int2 are global, not instance variables. I would suggest you to take a look at the IL, that way you would see that the first constructor called is the ChildClass ctor, the compiler inserts a call to the ParentClass ctor Willy. I made the variables global becuae I want to show that variables were not initialized to 5 and 15 by the child class constructor. I can easily declare two instance variables and pass it to the the constructor of the parent class through global variables ( see the code below). Can you confidently say that an object of the child class has been instantiated when the values of its instance variables are not initialied by the constructor ? Module Module1 Public Int4 As Integer Public Int5 As Integer Public Class ParentClass Public Sub New() System.Console.WriteLine("Parent Class Constructor is called Int4 = " + Int4.ToString + " and Int5 = " + Int5.ToString) System.Console.ReadLine() End Sub End Class Public Class ChildClass Inherits ParentClass Public Int1 As Integer Public Int2 As Integer Public Sub New() Int1 = 5 Int2 = 10 Int4 = Int1 Int5 = Int2 System.Console.WriteLine("Child Class Constructor is called and Int3 = " + AddXY().ToString) End Sub Public Function AddXY() As Integer Return (Int1 + Int2) End Function End Class Sub Main() Dim CC As ChildClass = New ChildClass System.Console.ReadLine() End Sub End Module ----- Willy Denoyette [MVP] wrote: ----- "stack" <anonymous@discussions.microsoft.com> wrote in message news:DF3CD7E3-4BB4-4E3C-8933-B8A56347579E@microsoft.com... when you move the debug point to child class constructor, the values are initialized to 5 and 10 correctly. Here is the code: > Module Module1 > Public Int1 As Integer > Public Int2 As Integer >>> Public Class ParentClass > Not sure what you want to prove here, the variables Int1 and Int2 are global, not instance variables. I would suggest you to take a look at the IL, that way you would see that the first constructor called is the ChildClass ctor, the compiler inserts a call to the ParentClass ctor Willy. > I made the variables global becuae I want to show that variables were > not initialized to 5 and 15 by the child class constructor. I can [quoted text clipped - 3 lines] > has been instantiated when the values of its instance variables are > not initialied by the constructor ? I can confidently say that an object is an instance of the child type before the code specified for the constructor has been run. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.