[boost] Ticket #2115 Avoid bad Apple macros

Subject: [boost] Ticket #2115 Avoid bad Apple macros
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-10-11 08:59:20

>  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:

debug_string, check, ncheck, check_string, ncheck_string, check_noerr, 
check_noerr_string, verify, nverify, verify_string, nverify_string, 
verify_noerr, verify_noerr_string, verify_action, require, nrequire, 
require_action, nrequire_action, require_quiet, nrequire_quiet, 
require_action_quiet, nrequire_action_quiet, require_string, 
nrequire_string, requireaction_string, nrequireaction_string, 
require_noerr, require_noerr_action, require_noerr_quiet, 
require_noerr_action_quiet, require_noerr_string, 
require_noerr_action_string.

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_.

--Beman