🚀 go-pugleaf

Shankar Unni wrote:
> 
> This not so much a standards issue as a migration issue.
> 
> As vendors phase in new (since the ARM) features, like "bool", "wchar_t"
> (builtin), namespaces, exceptions, etc., people trying to write code that
> works with multiple compilers have a hard time trying to come up with
> appropriate configuration macros so that their source will build cleanly
> on all target platforms.
> ...
> I had in mind a pseudo-standard set of macros that implementations could
> define as they phased in features, like, say:
> 
>   _BOOL_SUPPORTED
>   _WCHAR_T_SUPPORTED
>   _NAMESPACES_SUPPORTED
>   _EXCEPTIONS_SUPPORTED
>   _RTTI_SUPPORTED
>   _MEMBER_TEMPLATES_SUPPORTED
>   _TEMPLATE_DEFAULT_ARGS_SUPPORTED
> 
> and so on. ...

Each community of developers who write portable code face this issue,
and approach it essentially the same way.  However, there is a key 
insight that can reduce the amount of work this involves, over time.

Rather than defining a macro _BOOL_SUPPORTED (which, by the way, is
in the vendor's reserved namespace), define a macro BOOL_BROKEN.
As features are added (and bugs fixed), macros are eliminated, until 
there are none left.  Then, a conforming compiler has no such macros 
defined, and is ready right out of the box. 

Vendor extensions should still be described positively: 
_VARIABLE_AUTO_ARRAYS, _AUTO_FUNCTIONS, etc.; but vendors
should provide those names themselves, to make it easier 
for users to use them safely.

Finally, it's a lot less work to use somebody else's maintained set 
of such macros.  I won't recommend any particular set, here.

Nathan Myers
myersn@roguewave.com

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]