Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!umd5!cvl!elsie!nih-csl!keith
From: keith@nih-csl.UUCP
Newsgroups: comp.lang.c++
Subject: Re: OOPS Class Library Availability
Message-ID: <285@nih-csl.UUCP>
Date: Sat, 21-Nov-87 12:13:16 EST
Article-I.D.: nih-csl.285
Posted: Sat Nov 21 12:13:16 1987
Date-Received: Tue, 24-Nov-87 04:03:34 EST
References: <283@nih-csl.UUCP> <4489@well.UUCP>
Organization: NIH-CSL, Bethesda, MD
Lines: 113
Keywords: C++, class library, OOPS, object-oriented programming
Summary: Answers to questions about generic classes

In article <4489@well.UUCP>, mitsu@well.UUCP (Mitsuharu Hadeishi) writes:
> 	We would like to find out how to get a hold of the USENIX C++
> library tape.

Please contact Peter Salus (usenix!peter) for further info.

>(BTW, Keith, we never did get a copy of your OOPS library;
> did you get our letter?)

I think so.  I'll check on it next week.

> We, too, have been thinking of using
> a pure object-oriented approach to using C++, but we have run into some
> difficulties.  How does your OOPS library handle dynamic binding?

Vanilla virtual functions.

> I presume your Collection classes handle pointers to things of type
> Object, is that right?  Does the caller have to type coerce the return
> value of the Collection class to get the correctly typed object ..

Yes.  There are two ways to make sure that the cast is safe: 1) make a
new class that uses the polymorphic class as a base class or member
variable, and write member functions that statically type-check the
objects added to the polymorphic class.  Then provide member functions
that return pointers cast to the desired type.  This approach adds no
run-time type checking overhead.  2) Check the class of the object at
run time before doing the cast.  OOPS has functions to facilitate
this.

A third approach, not implemented in OOPS, will be to have generic
collection classes that have type parameters, and instantiate the
generic class for the desired type.  This will be possible when type
parameters are implemented in C++.

> If your objects do have class object pointers, what's in those
> class objects?

A pointer to the class object of the base class, the name of the class
as a character string, a version number, the size in bytes of
instances of the class, a pointer to a function for reading instances
of the class from a stream, and some dull stuff.

> I presume some class variables and methods, but is there
> also a table of method pointers for the class, or do you use virtual
> functions to handle this?

Virtual functions.

> Do all of your methods universally return
> Object pointers (thus making the virtual function type difficulty moot?)

Yes. (more or less)

> Do you declare ALL methods virtual in that case?

Most of the member functions of the collection classes are virtual.

> Can you handle multiple
> inheritance?  How do you deal with the problems of virtual function
> table offsets in that case?

I have some ideas on how to make OOPS handle multiple inheritance
under the next release of C++, which will automatically take care
of the virtual function tables.

> what kind of macros do you use to do type coercion?

None, although I suppose I should have.  I do have member functions
that do type checking, however.

> What methods do
> you expect to be defined for all objects (aside from ==, =, Hash() or
> whatever, !=)?

storer(), reader(), compare(), deepenShallowCopy(), hash(), isA(),
isEqual(), printOn(), species() should be defined by each OOPS class.
Class Object implements isKindOf(), isMemberOf(), isSame(),
isSpecies(), shouldNotImplement(), storeOn(), addDependent(),
changed(), deepCopy(), dependents(), release(), removeDependent(),
shallowCopy(), update(), and some others.

> Do you use more general macros than those included
> in generic.h?

OOPS doesn't make much use of macros.  I have some m4 macros that can
generate a primitive container class for a fundamental type, but they
are currently used to generate only class Arraychar.  I used m4 macros
most extensively for the APL-like Vector classes, but these are not
practical, so I don't distribute them routinely.  I don't recommend
extensive use of C preprocessor macros such as those in generic.h --
they seem to break cpp on some machines.

> 	Finally, what is the performance hit in using instances of
> class Float or Integer instead of built-in classes?

It is unacceptable, in my opinion, so I don't define the arithmetic
operators for these.  They are a hack to allow floats and ints to be
stored in OOPS data structures.

> If you use
> virtual functions heavily, do you feel this is an overly-large
> memory hit?

In theory, no; in current practice, yes.  Due to limitations of the
UNIX loader, the virtual function pointer tables are unnecessarily
replicated.  I think I recall Bjarne saying he had a fix for this in
the next release.
-- 
	Keith Gorlen			phone: (301) 496-5363
	Building 12A, Room 2017		uucp: uunet!mimsy!elsie!nih-csl!keith
	National Institutes of Health
	Bethesda, MD 20892