Quite right. Messages to objects are relatively costly in Geos compared to
dynamic or static methods in C++, because they have to be dispatched by the
operating system by searching method tables for a suitable handler, possibly
through multiple levels of the class structure. In addition, depending on
additional flags and thread relationships of the objects exchanging messages, a
message may have to pass through the thread's message queue as well. This means
that the standard examples for C++ classes (operator overloading for complex
numbers, container classes) will normally not be implemented using Geos system
objectys.
The advantage of this is of course that an application doesn't have to worry
about the type of storage an object resides in, meaning that "object
persistence" is usually much less of a concern than with conventional object
oriented languages.
Automatic constructors/destructors: as Nathan writes, MSG_META_INITIALIZE and
MSG_META_DETACH provide these functions, except for static objects (see
description for these messages in the "Objects" reference of the SDK).
> 2. What's the best way of allocating several thousand small (i.e. less than
> fifty bytes) objects? If I use MemAlloc() for each one, or create an instance
> of a class, then I would end up using lots of handles, and the system could
> pretty well run out.
You can sub-allocate parts of a larger MemAlloc'ed block by creating a local
heap (LMem) in the block which can be used to efficently hold large numbers of
small objects. There are higher level utility functions that use LMem structures
to implement concepts like variable size arrays and arrays with keys which can
even contain a rudimentary form of automatic garbage collection.
> 3. Does GOC have dynamic binding, that is, can I send a message to an object
> without knowing what the class is?
It is actually more like the opposite way: there is no such thing as "static"
binding or "typesafe linking". You are free to send any message to any object,
even messages which were introduced in a class of which the object's class isn't
a subclass at all. Because the linking process converts messages to message
numbers, which may be ambiguous between object classes at the same level of the
class tree, this message may be misunderstood by the object it is sent to, or it
may just pass through unnoticed - in my opinion, this is one of the most
prominent weaknesses of the Geos object model, because it puts the burden of
checking class dependencies on the developer. At least the error checking build
of a program should provide some way of verifying this...
> 4. What sort of utility general storage classes are there available?
> Extendable arrays? Keyed arrays? BSP trees?
See above: Geos doesn't implement this as classes, but as utility functions
working with local memory.
> 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*?
As far as I know, objects stored in VM files are transparenty "relocated" and
"unreloced" by the system (in other words, object pointers in instance variables
are automatically converted to abstract block/chunk handles which remain valid
in the context of the file even across sessions). Which instance variable have
to be relocated and which haven't is part of the class definition.
> 6. Does anyone know where I can find either a GOC programming tutorial, some
> example code, or preferably both on the net?
There is some free source code available from 3rd party programmers, in addition
to what is in the SDK. You can find a few examples of my own stuff on my new web
page [advertising mode on]: :-)
http://ourworld.compuserve.com/homepages/mgroeber/
ciao marcus