Re: Ticket #2115 Avoid bad Apple macros

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost