Xref: utzoo comp.std.c:109 comp.lang.c:10968
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: __STDCPP__ anybody?
Message-ID: <8178@brl-smoke.ARPA>
Date: 28 Jun 88 17:04:57 GMT
References: <2459@plus5.UUCP> <8164@brl-smoke.ARPA> <2460@plus5.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 16

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.