Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!pp!riunite!rfg
From: rfg@riunite.ACA.MCC.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: #once cpp directive implemented!
Message-ID: <124@riunite.ACA.MCC.COM>
Date: 20 Mar 89 00:34:14 GMT
Reply-To: rfg@riunite.UUCP (Ron Guilmette)
Organization: MCC  Austin, Texas
Lines: 86

As someone pointed out recently, the subject of multiple
inclusion of individual include files was beaten to death
here not long ago.

At the risk of starting it all up again, I would like to
announce the availability of patches for the the GNU C
preprocessor (version 1.34) which implement the new #once
directive.  These patches may be aquired by simply sending
me mail and requesting the patches.  I hope that these patches
will soon become a standard part of the GNU releases, but till
then, I will distribute them.

The patch-kit also contains patches which implement two other
preprocessor extensions (both especially useful for C++).  These
are described below.

The semantics of the #once directive are simple.  The #once
directive causes any file it appears in to be included no more
than one time during any given individual compilation.  This
directive only takes effect when it is seen.  Thus, if "B.h"
includes "A.h", and if "A.h" looks like:

	#include "B.h"
	#once

Then "A.h" can get included multiple times.  For this reason
(and others) it is suggested that the #once directive be put on the
first line of any include file in which it appears.

Also included in the patch-kit are two related extensions which
may make working with inline functions/methods easier.  The first
of these is the capability to use relational operators on string
values in preprocessor conditional commands (e.g. #if).  The second
feature is the __BASE_FILE__ builtin symbol.  This symbol is always
defined (like __FILE__) to a string literal value.  It is only
defined once however at the start of each compilation, and it's
value remains the same even while include files are being processed.

These two features can be used together to make it easy to alternately
enable or disable the inlining of certain functions (or methods) whose
definitions appear in include files.

Specifically, consider the following include file:

sample.H
-----------------------------------------------------------------------
#include "other_stuff.H"

#if INLINING || (__BASE_FILE__ == "sample.C")

INLINE int dialing_for_dollars (int count, int amount)
{
	if (count == tv_count && amount == tv_amount)
		return winner;
	else
		return loser;
}

#endif
-----------------------------------------------------------------------

If this file is included into a compilation for which the following
defines are given:

	-DINLINING -DINLINE=inline

The the function "dialing_for_dollars" will be inlined.  If however, the
compilation options are:

	-UINLINING -DINLINE=

Then the function definition will effectively vanish, except when
the base file is the file "sample.C".

This is good, because if you do *not* want to inline the given
routine, then it should vanish in most compilations, but you still
need to have its source code present in one "home" compilation
so that the (one and only) out-of-line version of the routine
gets generated.


-- 
// Ron Guilmette  -  MCC  -  Experimental (parallel) Systems Kit Project
// 3500 West Balcones Center Drive,  Austin, TX  78759  -  (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg