hokey@plus5.UUCP (Hokey) (06/26/88)
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? -- Hokey
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/27/88)
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.)
ado@elsie.UUCP (Arthur David Olson) (06/27/88)
< 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.
raeburn@athena.mit.edu (Ken Raeburn) (06/27/88)
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?)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/27/88)
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.
hokey@plus5.UUCP (Hokey) (06/27/88)
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
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/29/88)
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.