🚀 go-pugleaf

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