Re: #import future (summary and proposed solutions)

["Timothy J. Wood" <tjw at omnigroup dot com>]

> 2) The implementation of #import will fail under certain circumstances
>    and cause a file to be read twice when it shouldn't have been.
>    This is also true of the #ifndef-wrapper optimization.  However,
>    when the #ifndef-wrapper optimization fails the only effect is a
>    small amount of wasted time, because the #ifndef prevents the
>    content of the header from being seen twice.  #import failing
>    causes the translation unit to be rejected spuriously.

  I addressed most of your points in my previous message, but not this 
one in detail...  #include (at least as used in many projects) will 
also incorrectly reject headers files.

  Consider the case that I'm using two packages from different vendors:

<PackageA/header1.h> has:

#include "header2.h"

<PackageB/header1.h> also has:

#include "header2.h"

  Both have the minimal '_FILENAME_H_' header guards w/o any sort of 
UUID (as is common practice), so the second header2.h will not get 
included.  Yes, there are ways to avoid this problem, but it does 
happen.

  This seems *much* more common than inode collision (i.e., I've 
actually seen it happen where as I've never hit any sort of inode 
problem with #import).

> 3) #import is poor language design:
>
>      #import is not a well designed feature.  It requires the users of
>      a header file to know that it should only be included once.  It
>      is much better for the header file's implementor to write the
>      file so that users don't need to know this.  Using a wrapper
>      #ifndef accomplishes this goal.
  And I can't resist stating again that I think #include is poorly 
designed.

  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