PATCH: objc-improvements-branch merge -- Part 2

Matt Austern austern@apple.com
Fri Aug 13 18:11:00 GMT 2004


On Aug 13, 2004, at 10:52 AM, Ziemowit Laski wrote:

>
> On 12 Aug, 2004, at 19.06, Andrew Pinski wrote:
>
>> Mostly okay but a few problems I saw:
>>
>> On Aug 12, 2004, at 6:50 PM, Ziemowit Laski wrote:
>>
>>> retrieving revision 1.3
>>> diff -u -3 -p -r1.3 Object.h
>>> --- libobjc/objc/Object.h       23 May 2003 20:04:58 -0000      1.3
>>> +++ libobjc/objc/Object.h       13 Aug 2004 01:49:46 -0000
>>> @@ -27,6 +27,10 @@ Boston, MA 02111-1307, USA.  */
>>>  #ifndef __object_INCLUDE_GNU
>>>  #define __object_INCLUDE_GNU
>>>
>>> +#ifdef __cplusplus
>>> +extern "C" {
>>> +#endif
>>> +
>>>  #include <objc/objc.h>
>>>  #include <objc/typedstream.h>
>>
>> Never ever wrap extern "C" around other headers.
>
> Is that a GCC policy of some sort?  :-)

If not, it should be.  Several years before I came to SGI, some people 
there made the mistake of extern "C" blocks.  This appeared harmless at 
first but it caused a severe maintenance problem later.

The problem is that if header A.h #includes B.h in an extern "C" block, 
then neither B.h, nor any header that it includes transitively, can 
contain C++ features like overloading or templates.  And if you think 
that doesn't apply to these particular headers: are you sure that 
nobody five years from now will ever want to modify objc.h so that it 
includes inttypes.h or stdbool.h stddef.h, and that nobody a few years 
after that will ever modify one of those headers so that it uses those 
sorts of features?  The people at SGI who made this mistake were sure 
itg was safe too.  And it was---when they did it.

Wrapping extern "C" around a #include creates a nasty trap.  We should 
always avoid it.

			--Matt



More information about the Gcc-patches mailing list