Home arrow static arrow Java Programming [Archive] - java constructors drive me mad
Warning: Creating default object from empty value in /www/htdocs/w008deb8/wiki/components/com_staticxt/staticxt.php on line 51
Java Programming [Archive] - java constructors drive me mad
This topic has 219 replies on 15 pages.    « Previous | 1 | ... 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Next »

Posts:205
Registered: 6/15/04
Re: java constructors drive me mad  
Jun 19, 2004 8:12 AM (reply 75 of 219)



 
v-table is a collection of offset values
indicating values relative to the current object.. ..
the compiler must ensure that objects are created in a
specific order.

This is nonsense. You still don't understand the
principles of Java platform operation (they are not
much different from other implementaion of VTables ).
Please, anybody, give an URL link to this poor lost
boy.

This is how v-table work. If you think I'm wrong, do some reading and show me where I'm wrong (I'm not pretending, for a minute, to be infallable)

Non-virtual member functions are resolved statically. That is, the member function is selected statically (at compile-time) based on the type of the pointer (or reference) to the object.

In contrast, virtual member functions are resolved dynamically (at run-time). That is, the member function is selected dynamically (at run-time) based on the type of the object, not the type of the pointer/reference to that object. This is called "dynamic binding."

Most compilers use some variant of the following technique: if the object has one or more virtual functions, the compiler puts a hidden pointer in the object called a "virtual-pointer" or "v-pointer." This v-pointer points to a global table called the "virtual-table" or "v-table."

The compiler creates a v-table for each class that has at least one virtual function. For example, if class Circle has virtual functions for draw() and move() and resize(), there would be exactly one v-table associated with class Circle, even if there were a gazillion Circle objects, and the v-pointer of each of those Circle objects would point to the Circle v-table.

The v-table itself has pointers to each of the virtual functions in the class. For example, the Circle v-table would have three pointers: a pointer to Circle::draw(), a pointer to Circle::move(), and a pointer to Circle::resize().

During a dispatch of a virtual function, the run-time system follows the object's v-pointer to the class's v-table, then follows the appropriate slot in the v-table to the method code.
 

Posts:205
Registered: 6/15/04
Re: java constructors drive me mad  
Jun 19, 2004 8:12 AM (reply 76 of 219)



 
v-table is a collection of offset values
indicating values relative to the current object.. ..
the compiler must ensure that objects are created in a
specific order.

This is nonsense. You still don't understand the
principles of Java platform operation (they are not
much different from other implementaion of VTables ).
Please, anybody, give an URL link to this poor lost
boy.

This is how v-table work. If you think I'm wrong, do some reading and show me where I'm wrong (I'm not pretending, for a minute, to be infallable)

Non-virtual member functions are resolved statically. That is, the member function is selected statically (at compile-time) based on the type of the pointer (or reference) to the object.

In contrast, virtual member functions are resolved dynamically (at run-time). That is, the member function is selected dynamically (at run-time) based on the type of the object, not the type of the pointer/reference to that object. This is called "dynamic binding."

Most compilers use some variant of the following technique: if the object has one or more virtual functions, the compiler puts a hidden pointer in the object called a "virtual-pointer" or "v-pointer." This v-pointer points to a global table called the "virtual-table" or "v-table."

The compiler creates a v-table for each class that has at least one virtual function. For example, if class Circle has virtual functions for draw() and move() and resize(), there would be exactly one v-table associated with class Circle, even if there were a gazillion Circle objects, and the v-pointer of each of those Circle objects would point to the Circle v-table.

The v-table itself has pointers to each of the virtual functions in the class. For example, the Circle v-table would have three pointers: a pointer to Circle::draw(), a pointer to Circle::move(), and a pointer to Circle::resize().

During a dispatch of a virtual function, the run-time system follows the object's v-pointer to the class's v-table, then follows the appropriate slot in the v-table to the method code.
 

Posts:205
Registered: 6/15/04
Re: java constructors drive me mad  
Jun 19, 2004 8:12 AM (reply 77 of 219)



 
and I only posted that once!
 

Posts:835
Registered: 2/12/01
Re: java constructors drive me mad  
Jun 19, 2004 8:18 AM (reply 78 of 219)



 
Okay, that is nonsense. So is this ...
I understand you is a touchy boy who does not like truth. I've told you if you think it is a nonsense do not dumb the board.

I have given you a definition that human as is a monkey with a brain. I understand that the transition species does not exist.

Plesae, if you do not know how JVM is working, do not base your considerations on it.
 

Posts:205
Registered: 6/15/04
Re: java constructors drive me mad  
Jun 19, 2004 8:19 AM (reply 79 of 219)



 
there is no point continuing this discussion.
 

Posts:11,186
Registered: 06.04.04
Re: java constructors drive me mad  
Jun 19, 2004 8:26 AM (reply 80 of 219)



 
That is exactly what I have been saying (or at least trying to say). So, by that logic, how can memory be
allocated for an object, without traversing the hierarchy?

[ example deleted, see reply #71 ]

in order to allocate enough memory for the instantiation of Obj4, one must first initialize Obj3,
and in order to allocate enough memory for the instantiation of Obj3, one must first initialize Obj2,
and in order to allocate enough memory for the instantiation of Obj2, one must first initialize Obj1.
(maybe I'm proving my huge misconcepts about object instances in Java)

The raw memory for a new object is allocated in one consecutive area of memory; it is done in one
simple call. The initialization of all that memory is performed from the top to the bottom, i.e. first
the parent class initializes its fields and has its constructor invoked; afterwards, the derived class
gets its chance.

The compiler already figured out how much memory needed to be allocated (by walking the class
hierarchy), the new operator simply allocated that amount of memory and invokes the current
constructor. The compiler either checked that an appropriate super call was present in that
instructor, or it inserted a default super() call there, or, finally, it had checked if another this
invocation was present there. If not, it had issued an error diagnostic and refused to compile the class.

These compile time checks ensure that the object is constructed from the inside out, as an onion.
The inner layers first, the outer layers last. All the private/protected/public stuff is compile time duty
too; i.e. it simply generates the right calls or refers to the right slots in memory allocated for the
newborn object. Note that every member/method (non static) simply takes up 4 bytes, except for
a double or a long. Calculating the amount of memory needed for an object isn't that
difficult ...

The compiler simply refuses to (de)reference a member of an object under construction before
the super class constructor has finished; not because there is no memory allocated for it yet,
but simply because it isn't initialized at that stage; either by initialization code or the constructor itself.
It's just a safety measure ...

The funny thing is, that the vtab is already initialized, i.e. a constructor of a super class can call a
method from a sub class if it overrides a same method in the super class; I find that a bit sloppy ...
This vtab became initialized when the sub class was loaded by the class loader.

kind regards,

Jos
 

Posts:835
Registered: 2/12/01
Re: java constructors drive me mad  
Jun 19, 2004 8:27 AM (reply 81 of 219)



 
The last statemens are completely different from what you stated before:
v-table is a collection of offset values indicating where in memory space (in relation to the starting address of our object) methods can be found
There is no need to have a VT for each object.
 

Posts:11,186
Registered: 06.04.04
Re: java constructors drive me mad  
Jun 19, 2004 8:36 AM (reply 82 of 219)



 
During a dispatch of a virtual function, the run-time system follows the object's v-pointer to the class's
v-table, then follows the appropriate slot in the v-table to the method code.

That would be a double indirect call; the JVM can do better than that, i.e. it simply resolves the
symbolic reference to that vtab when the class is loaded; that turns it into a single indirect call.
Class loading involves linkage editing ... they take care of that indirect call; there's no need to
follow that v-pointer and then find the address of that method ... the code for all these virtual
methods is only loaded once when the class was loaded.

kind regards,

Jos
 

Posts:835
Registered: 2/12/01
Re: java constructors drive me mad  
Jun 19, 2004 8:36 AM (reply 83 of 219)



 
Yes you're right, I'm mixing up java and general considerations again.
 

Posts:835
Registered: 2/12/01
Re: java constructors drive me mad  
Jun 19, 2004 8:41 AM (reply 84 of 219)



 
Dynamically doadeable object could have a separate vtable indeed.
 

Posts:11,186
Registered: 06.04.04
Re: java constructors drive me mad  
Jun 19, 2004 8:49 AM (reply 85 of 219)



 
Dynamically loadeable object could have a separate vtable indeed.

[ changed a typo ]

Indeed, but Java doesn't have true dynamic loading without using the introspection mechanism.
It's more like lazy loading or delayed loading. Therefore all (virtual) method addresses can
be resolved when the class itself is loaded. The methods themselves are loaded with it and so
all their invocations can be resolved at class loading time; there's no need for a double indirection
through a 'v-pointer' or similar.

kind regards,

Jos
 

Posts:205
Registered: 6/15/04
Re: java constructors drive me mad  
Jun 19, 2004 9:04 AM (reply 86 of 219)



 
The raw memory for a new object is allocated in one consecutive area of memory;

This was never in question (at least not by me), I merely mentioned non-contiguous memory allocation to illustrate what could happen if the following were not to occur.

it is done in one simple call. The initialization of all that memory is performed from the top to the bottom, i.e. first
the parent class initializes its fields and has its constructor invoked; afterwards, the derived class
gets its chance.

The principle I have been talking about is exactly the same as corroberated by Jos, so how is it (valjok) that I am a confused boy and Jos is not?

- and forgive my abstractions, however, I find it very difficult when you keep swapping between Java specifics and programming in general.

Enjoy the rest of your weekend :o)

-ps. I'm not sore, since I have nothing to be sore about :o)

 

Posts:11,186
Registered: 06.04.04
Re: java constructors drive me mad  
Jun 19, 2004 9:17 AM (reply 87 of 219)



 
The principle I have been talking about is exactly the same as corroberated by Jos, so how is it (valjok)
that I am a confused boy and Jos is not?

I guess that all discussion partners misread some paragraphs from each other; e.g. your paragraph:

in order to allocate enough memory for the instantiation of Obj4, one must first initialize Obj3,
and in order to allocate enough memory for the instantiation of Obj3, one must first initialize Obj2,
and in order to allocate enough memory for the instantiation of Obj2, one must first initialize Obj1.
(maybe I'm proving my huge misconcepts about object instances in Java)

gave me the impression that an object would be allocated in fragments, i.e. first the base then the derived.
And you did overcomplicate things somewhat when you explained the v-pointer stuff by suggesting
that every virtual function call would be a double indirect call ...

No hard feelings ;-) enjoy the weekend.

Jos
 

Posts:205
Registered: 6/15/04
Re: java constructors drive me mad  
Jun 19, 2004 9:35 AM (reply 88 of 219)



 
I couldn't resist just one more reply ...

And you did overcomplicate things somewhat when you
explained the v-pointer stuff by suggesting
that every virtual function call would be a double
indirect call ...

yes, granted, however, I was under the impression that we were still talking "programming in general".

So to any I have confused, please accept my most humble apologies.

And now I really am off :o)
 

Posts:7,499
Registered: 02-11-14
Re: java constructors drive me mad  
Jun 20, 2004 8:42 AM (reply 89 of 219)



 
There is a wise (not english) proverb, "exchanging positions of
items does not change the sum" (math commutativity).

Not so wise when put in the context of language, for which Java is...

For instance, the items
V A L J O K
make your name, when in the proper order. But LOVJAK is not your name, although it is composed of the same items, just in a different order.

Then consider the phrase:
I Love Apples But I Hate Oranges.
Each word being an item, I can slightly re-position the the items, and get:
I Hate Apples But I Love Oranges.
Rather the opposite of what I intended to say...
 
This topic has 219 replies on 15 pages.    « Previous | 1 | ... 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Next »