Quote
non virtual method calls require no vmt lookup, correct?
Yes. And if the class itself has zero virtual functions, then it won't have any Virtual Method Table.

I think you're confusing a pointer to the vtable and the vtable itself. An object will store a pointer to the vtable not the full table. The vtables themselves are generally stored in a read only data segment.

Yep, already edited my post. I should remember to hold off on posting in the morning until after breakfast.

all this seems to imply that all method calls require dereferencing the object's vmt pointer to get the jump address of the actual method to use. i thought non-virtual methods had their jump addresses stored in the objects, to avoid the derferencing overhead.

so all method calls become: gosub vmt_ptr->method->address ?

IE gosub to the address of <method> stored in the vmt pointed to by vmt_ptr ?

for non-virtual, I thought it was more like: gosub instance.method_address[method]

and a stand alone function, by comparison is simply: gosub method_address, correct?

fascinating! i thought local declarations did a new in the background and a dispose on return, using the heap.[/quote] Things only go on the heap if they are explicitly allocated, either directly or indirectly. If the object you create on the stack uses allocation with new, then that data would go on the heap. The pointer to that data would be on the stack. If the object you created was on the heap then both the pointer and the other data would both go on the heap. Its basically recursive. Say you created an object on the heap and called a member function. If that member function has local variables then they would be pushed onto the stack even though the object itself was allocated on the heap. This is due to the way the compiler treats executable code.

would object1 go on the stack when main was called? or is main a special case and it goes in the data segment?

main is exactly like any other function except it is called by the operating system rather than your program.

object1 (its member var storage space) would go in the data segment?

That would go in the data segment. While I said that main is a special case, it's slightly more complicated than I implied. main is actually called indirectly by the operating system in most environments. The operating system will generally call a function implemented in the run-time library. You can read a little about it here. That link mentions that the run-time library will initialize global variables before main is called. If the operating system called main directly then none of the constructors for the global variables would be called, among other things.

A non-virtual member function and a stand-alone function are pretty much the same thing. The method address is known after linking.

ok, so the vmt addresses replace the non-virtual method calls at link time, correct?

i _thought_ they were the same thing....

Things only go on the heap if they are explicitly allocated, either directly or indirectly.

i was under the impression that all were allocated on the heap, except global instances, which were allocated in the data segment at load time.

thanks for clarifying that. (lending a machete to my intellectual thicket).

and locally declared instances, being allocated on the heap, are automatically de-allocated when they go out of scope. and they don't use the heap so no possibility of memory leak. just the usual cross your i's and dot your t's stuff with malloc and free under different names (new and dispose) - correct?

If a variable is global, or if a variable is a static member-variable of a class (which is just a global variable in the class's namespace), then you can't count on the order or timing of when they are constructed. The only thing you can depend on is that they'll be constructed before int main() enters... but other than that, the order is compiler-specific.

right, startup code constructor hell. you can't rely on other globals being valid during your custom constructor. i hear about this a fair amount. i would think an explicit init() would take care of it. bad form?

except global instances, which were allocated in the data segment at load time.

It depends on the compiler you use, but generally yes, a global object will exist in the data segment, specifically in the bss section if it is a basic datatype or a structure containing basic datatypes. This isn't written in stone, though, and it's possible for it to also be allocated on the heap, or even on the stack.