Re: [boost] [preprocessor] Sequences vs. All Other Data Structures

Subject: Re: [boost] [preprocessor] Sequences vs. All Other Data Structures
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-04-27 00:45:09

On Fri, 27 Apr 2012 04:17:37 +0000, Stephan T. Lavavej wrote:

> [Paul Mensonides]
>> The best case scenario, if you want to support legacy mode: compiler
>> switch to *disable* a compliant preprocessor.  I.e. do the right thing
>> _by default_ (just like with for-loop scoping).
> 
> Yeah, you're right. I take back what I said about pragmas, I see that
> they would be especially unworkable for macros.
> 
>> wanton macro abuse
> 
> I was inured to defending against macroized min/max, but we recently
> discovered that Yield was macroized too - fun.

Not just min/max.  Many many Windows API names too (i.e. A vs. W).  
Obviously this is an issue for C without overloading, but there could be 
separate C++ headers that have overloaded inline thunks.  Otherwise, all 
non-local (meaning locally defined, used, undefined) should be prefixed -
and- all uppercase.

Window headers aren't special (neither are other library headers... I'm 
looking at you Qt and Linux (e.g. "major")) and should obey the 
appropriate conventions.  The Windows headers are simply garbage from the 
dark ages that is inflicted on way too many users.  (The same actually 
goes for Qt's ridiculous signals/slots moc mechanism.)  Library authors: 
get it out of your heads that your library is "special."  In the 
particular cases of Windows and Qt, the use of either should be an 
insignificant part of any software.  Otherwise, the software is 
fundamentally poorly designed.

This is true even for preprocessor metaprogramming libraries.  The 
contract library referenced in this thread, Boost.Python, the MPL, etc., 
all use Boost.Preprocessor, but the use is ultimately incidental--an 
implementation detail.  By definition, a library simply cannot tell how 
pervasive or important it will be in a client or in a client's client (and 
so on).  That is *one* of the things that makes library building hard--you 
often don't know whether optimization in any particular case is necessary.

Regards,
Paul Mensonides