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

Nathan Myers (ncm@netcom.com) wrote:

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

Oh, I was talking about *vendors* defining those symbols as they staged
each new feature online in their implementations.  As long as the names
were "pseudo-standard"ized, users could simply blindly stick in

  #ifdef _BOOL_SUPPORTED

into their code.

Sure, users come up with a scaffolding for this themselves (and I can see a
great value in an autoconf-like package - maybe a mini-autoconf - that can
generate a common "feature header" which could be automatically generated
by a config script on each platform).

But I was going about it from the angle of what vendors could provide to
make users' lives easier without going through all this autoconf
rigmarole (or having each user reinvent the wheel).

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

That's right - that's exactly what I had in mind..
--
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. ]