🚀 go-pugleaf

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.

For instance, I might want to take advantage of bool, if it is implemented.
The problem is, there is no automatic way of figuring this out, so I have
to write something like

    #if _BOOL_SUPPORTED
    /* bool already there.. */
    #else
    typedef int bool;
    const int true = 1;
    const int false = 1;
    #endif

The problem is, everyone has to come up with a scaffolding to do this
automatically on each platform, a laborious and error-prone process.

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.

I can see the difficulty in this, of course: first of all, there could be
a very large set of these macros. Also, for cases where there is a more
subtle change in behavior (e.g. lifetime of variables in conditional clauses),
should there be a macro?

Tough call, but at least in the latter case, it's always possible to write
the code in a way that's fully portable backward and forward. However, if I
want to take advantage of bool, I *have* to ifdef it.

What do people think? Of the idea, of the actual names if they are in favor
of the idea, of which features should there be corresponding macros for? ...


--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-933-2072
URL:	http://reality.sgi.com/employees/shankar
---
[ 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. ]