From: Aaron Gaudio <icy_manipulator@mindless.com>
  To  : ggi-develop@eskimo.com
  Date: Fri, 19 Feb 1999 17:13:07 -0500 (EST)

Re: libGGI3d -- ready to code?

And lo, the chronicles report that Filip Spacek spake thusly unto the masses:
> 
> 
> 
> On Fri, 19 Feb 1999 G. Gregory wrote:
> 
> > But then again if you really do want a string, you could always use
> > something similar to C++ name mangeling. void_int_long_float_drawtriangle
> > for void drawtriangle(int,long,float).
> 

The direction I think we were going was to have all interfaces consist
of a single input object and a single outpout object, so your example
would turn into this:

typedef struct {
	int arg1;
	long arg2;
	float arg3;
} foo_input;

void drawtriangle( struct foo_input );

This allows the functions to be dynamically called without requiring
the overhead of something like CORBA to marshal arguments (because they
in effect are already marshalled).

> Well, string seemed to be the best from the point of view of speed and
> flexibility. But the way I see it just a simple C++ish name mangling is
> not sufficient. What would be needed is a _description_ of the data
> structure. For example how would one go about describing interface for a
> BSP-tree rasterizer? (ok, some people may say that that is way to specific
> to be in libGGI3d, but that is the beauty of libGGI3d -- it cannot be
> bloated and also having the actual tree might help in some other parts of
> the pipeline). 

You would describe the interface of the BSP-tree rasterizer the same as
any other rasterizer. GGI3D will only perform type-checking when manipulating
modules in the pipeline, it won't perform logical analysis. All it will
tell you is that you module can or cannot fit in the pipeline at a specific
spot, whether it makes sense to do so or not is up to you. There will
be other mechanisms for determining what a module does. Beyond this, if you
want you module's interface to be compatible with other modules, you'll have
to follow their documented interfaces. It's an interesting thought though,
I'll parse some ideas in my mind...

> 
> This looks to me like an argument for IDL, the only problem is that all
> that I know about IDL are those few bits I've read on this list. I'll have
> to do some reading, but if it isn't as slow as some people suggest, then
> this seems to me to be the best solution... (btw, anybody has a link for a
> nice introductory article on IDL+CORBA?)

IDL is not slow, in fact, at run-time it is not anything. IDL is just 
a language (very similar to C++) for defining interfaces. It is not
necessary to use an ORB with IDL.

However, this does not mean that IDL effectively is efficient. IDL was 
created so that programs written in any language, on any platform can access
the implementation the IDL interfaces represent. To do this, a naming
service must be set up in order to map the client's method-calls to
the implementation's methods. For instance:

Implementation (C++):
class Foo {
	int foobar( char* );
}

Foo::foobar may be mangled to anything (per C++'s specs, or lack thereof).
Statically it is impossible to determine what the symbol's name is from
code not compiled in the same language and compiler. So, IDL may end
up defining a corresponding C function which is Foo_foobar_charPtr, but
there is no guarantee that that's how the C++ compiler mangled the
name. So the C function must do a lookup through the naming service to
actually call the implementation function. This adds overhead and
inefficiency (at the minimum an extra level of indirection). At the
high levels this may be acceptable (although I tend to not see how
it is useful, since GGI3D will exist at a rather low programming level),
but it certainly is not at the low levels.

If IDL is used only to generate names in one language, then it's useless,
one might as well use C++ directly, for there is no added portability,
only added development complexity.

More to the point, it doesn't solve what you're talking about any more
than C or C++ does. Pehaps Smalltalk could do some of what you're
talking about, but Smalltalk isn't known for being very efficient, and
I doubt there are as many developers who know it enough to help out in
GGI3D as know C or C++ (actually, Smalltalk's messages can just as
easily be handled in C or C++ ;-).

Note: I"m no CORBA or IDL authority and may be wrong about some of this,
but that's the way I understand things.


-- 

¤--------------------------------------------------------------------¤
| Aaron Gaudio                   mailto:icy_manipulator@mindless.com |
|                    http://www.rit.edu/~adg1653/                    |
¤--------------------------------------------------------------------¤
|      "The fool finds ignorance all around him.                     |
|          The wise man finds ignorance within."                     |
¤--------------------------------------------------------------------¤

Use of any of my email addresses is subject to the terms found at
http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you
agree to be bound by the terms therein.