Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!rutgers!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: objective C
Summary: Separate compilation-- it works, it works ...
Message-ID: <162@mole-end.UUCP>
Date: 4 May 89 06:50:17 GMT
References: <2614@ssc-vax.UUCP> <3180@stpstn.UUCP> <15327@gryphon.COM> <1546@sw1e.UUCP>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 68

> >>... reusing code involves binding a supplier's code with a consumer's code
> >>long after the supplier's code has been compiled (and therefore bound to
> >>whatever types the supplier knew about at the time...which fails to
> >>include the consumers') ...

Not so.  In general, something invoked through a calling sequence doesn't have
to know the name of the thing that invokes it.  If it is to use some resources
that are passed to it, it has to know what they are ... but it can present an
interface (a class) to be filled in and passed to it so that the resources are
presented on the invokee's own terms.

There's really no magic.

> >C++ does not *rely* on static binding, it *permits*, [it] ... Dynamic
> >binding ... is called "virtual functions". ...
 
> This gives me an opportunity to clear up a question I've had for quite a
> while.  Is it possible to do the following:
 
> Joe writes a class called Window and compiles it ... Window is of arbitrary
> complexity .  He then sends the compiled file plus a '.h' to Fred.

> Fred uses the .h to write a class derived from Window,  and links it ...
> with the object file for Window ... to produce a working program.

> Will this work?  ... no software house is going to want to have to send out
> sources.  ...  I hope C++ handles this (or that it soon will).
 
> By the way, I suspect that the answer to the question is no, ...

The answer is most definitely YES.  The class declaration contains all that
you need to know to compile a ``server'' or ``client.''  (Obviously, you
must be using the same version--or a compatible version--of the compiler.)

> For example, how to you handle inline functions of a class?  Is there a
> switch to tell the compiler to generate a standard function for such
> an inline and treat it as non-inline if only the '.o' is about?

Limitation--the inline must be visible to all instances which call it, which
means that you have to put it in the .h .  It's not worth making inline unless
it's either very small to begin with or it helps the interface.  As an almost
canonical example of the latter, consider:

	class	WhizzBang
	{
		friend ostream& operator<< ( ostream& o, const Whizzbang& w )
						{ return w.put( o ); };

		. . .
	  private:

		ostream& put( ostream& );
		. . .
	};

It's unlikely that inlines which look like this would give any great amount
away.  You are right; it's possible that a few inlines might NOT get written
to avoid disclosing source code.  On the other hand, look at the C standard
IO headers; the getc() and putc() macros give away some details of how the
buffering is done.

For really critical software, non-inline versions can be provided, with
inline-containing headers available under ``we hold your firstborn while
you program'' type licenses for people who need the last ounce of speed.
-- 

(This man's opinions are his own.)
From mole-end				Mark Terribile