Not so. MSG_META_INITIALIZE, and MSG_META_DETACH are the constructor and
destructor of every GEOS object.
<<<<<
MemAlloc is a Bad Thing - it creates a fixes block of memory, rather than
virtual
memory. Very antisocial, and a good way to run out of memory. Avoid.
>>>>>
Actually no. MemAlloc creates one of several blocks, depending on what you
want. The block can be fixed, swappable, discardable, sharable, etc. It
doesn't have to stay in memory, as the memory manager may very well swap it
to the swap file. VMAlloc will create blocks that are stored in a VM file,
making the memory manager even happier.
<<<<<
> 3. Does GOC have dynamic binding, that is, can I send a message to an
object
> without knowing what the class is?
Yes. In fact (correct me if I'm wrong, please!) _all_ messages are stored in
the
same table. If an object doesn't recognise a message, it uses a default null
method.
Unfortunately, this means that each object's messages have to have
standardized
unique names like MSG_VIS_TEXT_GET_ALL_VM_BLOCK.
>>>>>
Well, all messages to a particular class are stored in method tables. So if I
subclass MetaClass, my subclass will have it's own method table with my
additional messages in it. If GEOS can't find a message handler it's looking
for, the message being sent will simply disappear.
<<<<<
> 4. What sort of utility general storage classes are there available?
> Extendable arrays? Keyed arrays? BSP trees?
Unarranged LMem and the general-purpose Database library. (I think I'm
forgetting
some...)
>>>>>
Oh yeah, forgot about Database. Otherwise, there aren't any queue, stack, or
tree data structures that I know of.
<<<<<
> 5. When saving a VM file, I assume that you use something analogous to
Unix's
> mmap() to tell the kernel what data to save. However, if you have a fairly
> complex data structure, then your objects will contain pointers or handles
to
> other objects. How does the kernel know the format of your data, so it can
> store the complete data structure *and then reproduce it again*?
First, no pointers will survive the process. Neither will block handles. But
chunk handles will. The upper half of an optr (the block handle) has to be
reconstructed when the VM file is attached.
>>>>>
As I said in my previous post, the VM manager can automatically relocate
handles, pointers, class pointers, and optrs. Chunk handles will always work.
<<<<<
> 6. Does anyone know where I can find either a GOC programming tutorial,
some
> example code, or preferably both on the net?
No tutorials that I know of. I posted the source code to the last beta of
RenoComm
(my project) to comp.binaries.geos, and there's a copy at
http://www.cs.tu-berlin.de/~pilz
>>>>>
Well, there is the Tutorial that comes with the SDK, but it's not on the net.
Plus, there's the source code to my apps on my web site,
http://members.aol.com/nfiedler/.
Nathan