Re: [boost] Ticket #2115 Avoid bad Apple macros

Subject: Re: [boost] Ticket #2115 Avoid bad Apple macros
From: Marshall Clow (marshall_at_[hidden])
Date: 2008-10-12 11:49:30

>>  Apple has a header called <AssertMacros.h> that #defines both "check"
>>  and "check_error." These macros naturally collide with the same names
>>  in Boost. We should consider a global change.
>
>What global change? That Boost not use these names?
>
>What about the other horrid macros in that header? Here is a list 
>from Marshall:

[ list containing about 60 names elided ]

>Marshall comments: IMHO, the really nasty ones are: check, verify, 
>require and check_error.
>
>>  That would also
>>  probably require a global policy change for checkins.
>>
>>  Assigning to Beman, Cc'ing John M, component "inspection script"
>>  assigned to John although I might be wrong about that, but obviously
>>  we need to discuss this. Maybe we'll decide to make it "wontfix"
>
>I really don't want to start a policy of avoiding every name that is 
>defined in any vendor header. I forget the details, but at least one 
>vendor has shipped a header defining "read" and "write" macros!
>
>The fix for this one is to complain to Apple. They need to provide a 
>new new header that supplies the functionality but using macro 
>naming discipline, deprecate the old header, and add a warning to 
>the old header suggesting that users migrate to the new header. If 
>they wanted to be really helpful, they could provide a script to 
>automatically change the old names to the new names. And if they 
>have any other headers that fail to apply macro naming discipline, 
>they should do the same for those headers too. By "naming 
>discipline", I mean something like the Boost policy for macro names 
>always being all uppercase and beginning with BOOST_.

[ sorry for the excessive quoting, but I think the context is important ]

While I agree with Beman (complain to Apple), and Howard has filed a 
bug report with Apple, that still leaves us hurting at the present 
time.

I think a good workaround is to define __ASSERTMACROS__ in the darwin 
jam file, which will disable all those macros (by preventing 
/usr/include/AssertMacros.h from being parsed), and mentioning it in 
the docs.

-- 
-- Marshall
Marshall Clow     Idio Software   <mailto:marshall_at_[hidden]>
It is by caffeine alone I set my mind in motion.
It is by the beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.