Hi, can somebody explain me the different ?
Posted on 2003-03-25 12:16:47 by Forginforcer
I believe virtual data does not take up any space in exe file.
Posted on 2003-03-25 12:24:12 by Odyssey
red,

I am not sure of the language distinction but in MASM you can either set a structure in the .DATA section that is initialised with data or you can construct them on the stack as a LOCAL structure.

One is static and of global scope, the other is dynamic and of local scope.

Regards, **

hutch@movsds.com

** Crappy keyboards that often produce errors due to changes in the design to get the price down.
Posted on 2003-03-25 21:18:11 by hutch--
Are you talking about the METHODS or the STRUCTURE???

Is this an OOP question??



Posted on 2003-03-26 21:17:52 by AmkG

red,

I am not sure of the language distinction but in MASM you can either set a structure in the .DATA section that is initialised with data or you can construct them on the stack as a LOCAL structure.

One is static and of global scope, the other is dynamic and of local scope.

Regards, **

hutch@movsds.com

** Crappy keyboards that often produce errors due to changes in the design to get the price down.



What about dynamic of GLOBAL scope.. such as creating the struct in the .DATA section and using HeapAlloc to set aside memory for which the struct to point to..
Posted on 2003-11-27 02:57:27 by drarem
He said HeapAlloc, he MUST be referring to OOP :)
Posted on 2003-11-27 07:49:56 by Homer
He is referring to the C++ -like structures (classes), and also the OOP models posted here.
You should read "virtual" as "replaceable"

A virtual function is a procedure, whose address is written in the class' virtual table. The virtual table in fact, is an array of dwords, each element of which points to procedures, that belong to this class. Each class has one virtual table.
When you upgrade some code, but you still want to be able to use the old version's code, you need to inherit instead of replace. You just create a new class, that inherits from the old version class, and the functions that need to be replaced (upgraded) are included as "virtuals". But those functions that need replacement, should be already marked "virtual" (read "replaceable") in the old class definition.
But static class functions aren't upgradeable (replaceable).
The key to selection whether to use static or virtuals, is inheritage.

I've written some more info, and I've made a C++ to asm wrapper here:
http://www.asmcommunity.net/board/index.php?topic=15422
Posted on 2003-11-27 13:46:45 by Ultrano

He said HeapAlloc, he MUST be referring to OOP :)


BTW, here is a point open for debate. What is the better choice for the windows OS, when allocating memory for object instances? (Many small chunks of memory (approx 64-128 bytes in length).

HeapAlloc
GlobalAlloc
VirturalAlloc?

I guess the stack would be an option as well, but this would be a truely daunting task...

:NaN:
Posted on 2003-11-29 09:23:55 by NaN
The easiest for me: HeapAlloc. It allocates bytes_num+4, so no memory gets leaked a lot.
The best I've made and use is: use HeapAlloc to allocate 4kB pages , and handle allocation yourself. Also, there's an array that points to the different pages. Each page has several initial bytes, each bit of them shows if a cell has been taken or not. When all pages of a class type are full, then we call HeapAlloc for another, and when a page gets all its objects deleted, we call HeapFree. The size of a chunk might be set to different from 4096 bytes, but I think it's not good for speed.
Posted on 2003-11-29 09:51:42 by Ultrano
He's right - HeapAlloc does indeed allocate 4kb as a minimum , that's the "granularity", or page size, of the os internal memory manager - but don't worry, just because it allocates 4kb for the FIRST object, don't think that it'll allocate 40kb when you allocate the 10th lol - if you look at the addresses returned from a series of small Heap allocations, you will see that after a few paged allocations it will begin allocating in the earlier pages, at (PageAddress+sizeof struct), so infact this is not wasteful and no need to code a paged memory manager of your own unless you are a sicko. So when exactly does this wraparound occur? I dunno, I guess it depends on the fragmentation of your memory at the time.
Sometimes you even get nice serialized allocations on a single page, and then a jump to another 4kb page. Observations are based on NT behaviour.
BTW, even though GlobalAlloc supposedly uses HeapAlloc internally (allocating to the Process Heap), there IS a difference between memory allocated using HeapAlloc and memory allocated using GlobalAlloc - some DX calls will accept one and not the other and I honestly have NO IDEA WHY :|
Posted on 2003-11-29 16:03:37 by Homer
HeapAlloc is really enough - I had made that own allocation only because I thought HeapAlloc can allocate only 4kB or more :o . But if really speed of allocation does matter, I'll always bet on the specialized functions against the unified ones :grin: . When you alloc 100 bytes with HeapAlloc, you get the ptr in eax, and if you look the dword at , woah, A0000064. If you had allocated 255 bytes, it'd be A00000FF. The A0000000 mask is for the HeapFree to know if the pointer we give it is ok.
Thus, memory allocation with HeapAlloc is running through a linked list, which will be too slower than if it was custom-made. Also, the custom allocation I have, adds 2 bytes/struct, to mark on which of the allocated pages this object is . This way, object releasing takes less than 50 cycles usually. And object allocation takes less than 100 cycles. But this method isn't good for strings and other variable-len allocation.
Posted on 2003-11-29 17:29:19 by Ultrano
On which OS, ultrano? My win2k seems to do stuff differently... besides, just because you see a linked list structure doesn't necessarily mean this is the entire heap structure - there could be different size pools, free-list pointers etc... for generic memory allocation, I wouldn't bother with anything else but HeapAlloc - the default heap stuff on both 9x and (especially) NT seem adequate. Then again, generic allocations have never been a speed issue for me.

It can, however, certainly pay off when you're dealing with more specialized stuff... object pooling, constant-size allocations, frequent alloc/dealloc etc.

In any case, having your own wrapper code that does no more than calling Heap* functions is a good idea, as it will make it a lot easier to plug in another allocation system in case Heap* doesn't suffice (that is, without search+replace in a lot of files ^_^). Ohyeah, and make it easy to add sophisticated heap debugging stuff.
Posted on 2003-11-29 17:47:17 by f0dder
It's Win98SE :)
HeapAlloc is really enough for everybody. But I need to squeeze off any possible speed-up in most of the procs I write - music software runs at 11ms to 21ms latency, and it isn't rare to have to allocate/free objects in the few milliseconds that the procedures have.
Posted on 2003-11-29 18:29:09 by Ultrano