This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: #import future (summary and proposed solutions)


On Saturday 25 January 2003 11:49 pm, Timothy J. Wood wrote:
>
>    You should always design for the common case (single inclusion).  If
> K&R had seen far enough into the future, I'd hope they'd agree that a
> '#pragma allow_multiple_inclusion' would be a much better way to let
> the header declare that it wants to be included more than once.
>
> -tim
Hmm... Perhaps -

In the header file -
The (real or effective) appearance of a: "#pragma exclude_multiple" thingy -
This does the same as the "#Ifndef... #Def... #Endif" style header 
guards succeeding.

In the header file -
The (real or effective) appearance of a: "#pragma multiple_include" thingy -
This has the same effect as the "#Ifndef..." always failing.

In the source file -
#import xyz.h -
This predefines (defaults) for the file scope of the xyz.h;
 "#pragma exclude_multiple"

In the source file -
#include xyz.h -
This predefines (defaults) for the file scope of the xyz.h;
 "#pragma multiple_include"

I think this would give the author of the source file the
"expected behavior"

The author of the header file could actually include the
text "#pragma {exclude_multiple | multiple_include} to
over-ride the input default as required for special
cases.

This would give the author of the header file the
"expected control" regardless of how the source
file grabs hold of his header.

Mike


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]