🚀 go-pugleaf

In article <2459@plus5.UUCP> hokey@plus5.UUCP (Hokey) writes:
>Does anybody besides me think a __STDCPP__ predefined symbol would be of
>value?

No, because it's nonstandard.

If you avoid using the new features (#, ## for example), it should be
possible to write your code without #ifdefs so that either older or
Standard-conforming preprocessors interpret it the same way.  (This
assumes you never got dependent on Reiserisms in the first place.)

< We are in an environment in which we use a cpp which meets the (proposed)
< C standard, but we don't have a standard C compiler.
< 
< As y'all well know, a standard cpp does some things differently than "older"
< cpps, so we get to #ifdef our code in certain places.  Using __STDC__ as
< an indicator is not going to cut it, as it indicates a standard cpp as well
< as a standard C compiler.
< 
< Does anybody besides me think a __STDCPP__ predefined symbol would be of
< value?

Sorry; I proposed "__STDP__" to X3J11 a couple of drafts ago; it was
categorized as "inventive" and the committee decided against incorporating
the suggestion.  You'll see it listed in the boilerplate that the Committee
sends out in response to letters.
-- 
	ado@ncifcrf.gov			ADO is a trademark of Ampex.

On a vaguely related note, is there any way of distinguishing at
compile time between a hosted and a standalone implementation?  The
__STDC__ macro says you've got at least standalone, but how do you
know if you can assume a fully-conforming hosted implementation?  (At
least, you can rely on __STDC__ if the compiler isn't fooling you.
Maybe someday Metaware will get it right....)

The alternative to utilizing the hosted environment would presumably
be to supply your own support routines.  (Hm, there's a question.  If
you're on a standalone implementation, are the library procedure names
still considered reserved?)

In article <5924@bloom-beacon.MIT.EDU> raeburn@athena.mit.edu (Ken Raeburn) writes:
>On a vaguely related note, is there any way of distinguishing at
>compile time between a hosted and a standalone implementation?

No, because the same compiler may be used for both.

Doug,

It appears you are advocating two items.

First, no new/additional features should be added because they are
nonstandard (or perhaps "inventive" (Hi, ado!)).

Second, since it is possible to write code which will interpret on both old
and Standard preprocessors, we should do so.  Therefore, why bother with
all these new mechanisms anyway?

Can this be true?
-- 
Hokey

In article <2460@plus5.UUCP> hokey@plus5.UUCP (Hokey) writes:
>It appears you are advocating two items.
>First, no new/additional features should be added because they are
>nonstandard (or perhaps "inventive" (Hi, ado!)).

No, you asked whether __STDCPP__ would be useful.  To be useful for the
intended purpose, you would have to have it defined for all Standard-
conforming preprocessors.  Since it is not in the Standard, it won't be
so defined.  Therefore it is not useful.

>Second, since it is possible to write code which will interpret on both old
>and Standard preprocessors, we should do so.  Therefore, why bother with
>all these new mechanisms anyway?

Certainly if you are concerned with both compilation environments, it
is generally more work to provide code for each separately than to just
use their common intersection.