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