Boost logo

Boost :

Subject: Re: [boost] Ticket #2115 Avoid bad Apple macros
From: Howard Hinnant (hinnant_at_[hidden])
Date: 2008-10-11 21:31:47


On Oct 11, 2008, at 8:59 AM, Beman Dawes wrote:

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

How is <AssertMacros.h> being included? I'm assuming indirectly
through some standard header, but I'm not sure which one. Is there a
HelloWorld demo?

Thanks,
Howard


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk