mat@mole-end.UUCP (Mark A Terribile) (04/28/89)
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
pj@hrc63.co.uk (Mr P Johnson "Baddow") (05/12/89)
In article <152@mole-end.UUCP>, mat@mole-end.UUCP (Mark A Terribile) writes: > 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. > > 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 A better way would be to put all the stuff in String which uses streams in a separate file. A linker will only pull in files containing functions needed by other files, so if you do not use the String IO stuff, streams will not be linked in either. Some linkers are even more intelligent and will do what you want even if all the String stuff is in one file. I do not know the AT&T compiler, but there are other circumstances than virtual functions where inlines are compiled normally. These include array initialisation (constructors have to have an address for this: I never use inline constructors because so many compilers seem to have bugs in this area). Sorry if this has been dealt with: we are running about 2 weeks behind here. Paul.