I made this text basic example. To avoid alot of confusion for you guys.

Its a text output console window.

It has some text in every method. As well i print out what line of code is ran in main.exe, and then all the different methods that get called to show how methods interact with each other.

As well i show how polymorphism is advantageous as you dont need to know what type of object your calling an inherited method from. Polymorphism will sort it out for your.

In this example. Circle has an Area described by pi*(R)^2. So i polymorphically Overide the basic Shape area method, and make it specific to circle. Later i can still generically say "get this OBJECTS area" with out know what type of object it is, and still get the proper AREA method results if the object is a Circle Instance.

Check it out.. Pretty simple.

OOOOH YA!: BTW: I overlooked one thing in the creator tool!! My Bad :( , I will fix when i get another free moment. It doesnt place CMETHOD statements for methods generated. You need to manually replace methods like so (for now, sorry):

destructor dd ? ; Must be first... bla bla bla


CMETHOD destructor

Again, sorry about this, i revied the tool so fast i didnt get to properly check it.

Posted on 2001-09-22 15:02:29 by NaN
Hello NaN,

When looking at objects.inc I wonder if you have considered using LocalAlloc/LocalFree instead of HeapAlloc/HeapFree? With the "Local" functions, there would be no need to always get the process heap handle.

Posted on 2001-09-25 12:45:54 by japheth
From Iczelion's Tut#12:

Under Win16, there are two main categories of memory API

functions: Global and Local. Global-type API calls deal with
memory allocated in other segments thus they're "far" memory
functions. Local-type API calls deal with the local heap of the
process so they're "near" memory functions. Under Win32, these
two types are identical. Whether you call GlobalAlloc or LocalAlloc,
you get the same result.

So as i understand this, i would need to LOCK and UNLOCK any locally created object when i want to reference them. And since objects may want to call other objects. To UNLOCK the first, then call the next LOCK'n and UNLOCK'n, and then LOCK the origional to continue the method sounds like far more overhead.

Posted on 2001-09-26 13:25:07 by NaN
All other considerations aside, I read in the MS docs that the Heap functions are considerably faster than the Local/Global functions. However you could just retrieve the heap ptr once upon initialization after which it woulld be available as a dword.
Posted on 2001-09-26 13:41:14 by gfalen

You dont need to use LocalLock. When using LocalAlloc(LMEM_FIXED,bytes), you get the same block as with HeapAlloc(hHeap,0,bytes). And speed is the same. HeapAlloc may be faster if you use the "noserialize" flag, which isnt (and cant be) the case here.

Posted on 2001-09-26 13:52:05 by japheth
Well.. I dunno...

Sounds good to me.. But i will admit, I have only been programming windows for 10 months or so. So which is better in these areas i can't easily tell.

For this reason, i would like to hear others oppinions?? After all we built this for the community, so what do you guys think?

Posted on 2001-09-26 19:03:55 by NaN
For any large allocations, VirtualAlloc might be the best. As far as I
can see, this is the lowest level of memory allocation you can do,
and probably the fastest as well. But it's not good for small chunks
of memory, as allocations are done in chunks of 4k (the page size...)
Posted on 2001-09-26 19:20:23 by f0dder
That would be a very big class :) .

Roughly speaking thats: 800 methods, and 200 dword instance variables.. (80/20)%

But thanx anyways, i never knew of this API..

Posted on 2001-09-26 22:16:11 by NaN
Hehe, I hope we'll never see such a big class :]. But if you need
large chunks of data allocations inside a class, for example a chunked
memory manager, a cache system, or whatever, VirtualAlloc is nice.
Posted on 2001-09-27 09:07:34 by f0dder
Ya.. that i could be very usefull.. I've been using Global in these situations as this was all that i was aware of.

Posted on 2001-09-27 12:39:40 by NaN