Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ames!purdue!tut.cis.ohio-state.edu!rutgers!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Symbols, libraries, and friend classes
Keywords: friend, linking, symbols
Message-ID: <152@mole-end.UUCP>
Date: 28 Apr 89 05:01:59 GMT
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 32

In the real world, we sometimes want to provide facilities that work together
when all are present, but that don't all have to be present.  For example,
having defined a String, we would like to be able (let us say) to use stream
I/O with it, but not to require that stream I/O be loaded.

One way to do this is to create a class called (let us say) String_IO and
to make declare it a friend of class Stream.  Then we can declare, in a header
file for String_IO, the various I/O operations.  If we have to write a
member functions String::xyz() that uses String_IO, then String must also
be a friend of String_IO *and* we must ensure that if this function is never
called, the String_IO symbol(s) are never inserted in the actual executable.
One way to do this, at least in AT&T C++ is to use those symbols only in
non-virtual inline functions.

This depends on being sure that certain symbols will or won't be compiled into
the executable.  In particular, it must be possible to declare a friend
without that friend being seen by the compiler or linker, and it must be
possible to ensure that a non-virtual inline function will actually be
expanded, and won't be expanded if not used, and that if not used, symbols
that appear in it won't appear in the executable.

There is, to my knowledge, no guarantee of these things in C++.  My questions
are:

	Do all the existing C++ processors behave in this manner?

	Is there merit to defining behavior such as this as part of the
		language?
-- 

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