steve@taumet.com (Stephen Clamage) writes:

>Second, how do you specify in a standard how this is going to work?  There
>has to be a central clearing house to assign or approve a string for each
>compiler.  Who supports such an organization?  Who runs it?  Who ensures
>its continued existence when the current operators get bored or die?  Who
>enforces compliance, and how?  There are both volunteer and government-
>run institutions which perform comparable services, but no language
>standard could possibly address these issues.

>Third, the standard could not enumerate all possible C compilers,
>since some would come into existence between approval and publication,
>let alone after publication.  So you would have to find out on a compiler-
>by-compiler basis what the special strings were and modify your program
>for each new compiler.  This is just what you have to do now with no
>intervention by the standard.

There is already a way to do this.  It is called domain names.  Most
makers of compilers already have one, and the rest can easily get one.
They simply prepend whatever product and version names they feel are
necessary and make their compiler define it.
--
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/

Does the proposed standard (C or C++) have a way of identifying whose compiler
is being used?  I know its bad form to build code specific to a compiler when
that compiler conforms to a standard, but it seems that every compiler has its
little quirks that are specific to it.  What I was wondering was if one could:

 #if (__COMPILER__ == "BC++ v2.02")
  ...
 #endif

That way, *if you have to*, you could gear your code to a quirk.  Is there a
standard for this?  If not, why not?
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"

cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:

>Does the proposed standard (C or C++) have a way of identifying whose compiler
>is being used?

No.

>... it seems that every compiler has its
>little quirks that are specific to it.  What I was wondering was if one could:

> #if (__COMPILER__ == "BC++ v2.02")
>  ...
> #endif

You cannot do exactly this in C at all.  Nowhere in the C language is it
helpful to compare literal strings with ==.  (Even the expression
 "hi" == "hi"
need not result in equality.)

Trying to specify a way to do what you want in the standard opens up
quite a can of worms.

First, the standard deals with the definition of the language, not
specific implementation issues.

Second, how do you specify in a standard how this is going to work?  There
has to be a central clearing house to assign or approve a string for each
compiler.  Who supports such an organization?  Who runs it?  Who ensures
its continued existence when the current operators get bored or die?  Who
enforces compliance, and how?  There are both volunteer and government-
run institutions which perform comparable services, but no language
standard could possibly address these issues.

(We have a different situation with Ada, which is a creation of the
US Government.  It owns the "Ada" name and sets all the rules.  If you
don't follow the rules, you can't call your product an Ada compiler.)

Third, the standard could not enumerate all possible C compilers,
since some would come into existence between approval and publication,
let alone after publication.  So you would have to find out on a compiler-
by-compiler basis what the special strings were and modify your program
for each new compiler.  This is just what you have to do now with no
intervention by the standard.

Finally, your proposal doesn't help with compilers which do not follow the
ANSI standard for whatever reason.
--

Steve Clamage, TauMetric Corp, steve@taumet.com

cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:

>Does the proposed standard (C or C++) have a way of identifying whose compiler
>is being used?  I know its bad form to build code specific to a compiler when
>that compiler conforms to a standard, but it seems that every compiler has its
>little quirks that are specific to it.  What I was wondering was if one could:

> #if (__COMPILER__ == "BC++ v2.02")
>  ...
> #endif

I think your suggestion needs some modification... The test shown will generate
a syntax error no matter what __COMPILER__ is defined to (an integer constant
expression is expected).

You might just compile a list of what the different vendors use for
identification.  Zortech uses __ZTC__ which expands to the version number in
hex.  For example: version 2.18 would have __ZTC__ equal to 0x218.
--
joe@proto.com

>>>>> On 7 May 91 15:51:53 GMT, steve@taumet.com (Stephen Clamage) said:

Stephen> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:

David> Does the proposed standard (C or C++) have a way of identifying whose
David> compiler is being used?

Stephen> No.

David> ... it seems that every compiler has its little quirks that are
David> specific to it.  What I was wondering was if one could:

David>  #if (__COMPILER__ == "BC++ v2.02")
David>   ...
David>  #endif

Stephen> You cannot do exactly this in C at all.  Nowhere in the C language is
Stephen> it helpful to compare literal strings with ==.  (Even the expression
Stephen> "hi" == "hi" need not result in equality.)

I guess I wasn't clear here.  I know that what I put above is not legal, it
was just an example/idea of what I was looking for.

Stephen> Trying to specify a way to do what you want in the standard opens up
Stephen> quite a can of worms.

Stephen> First, the standard deals with the definition of the language, not
Stephen> specific implementation issues.

I'm not suggesting that it deal with implementation issues, just allow the
user to determine what the specific implementation is that he is dealing with
(*iff he needs to*).

Stephen> Second, how do you specify in a standard how this is going to work?
Stephen> There has to be a central clearing house to assign or approve a
Stephen> string for each compiler.  Who supports such an organization?  Who
Stephen> runs it?  Who ensures its continued existence when the current
Stephen> operators get bored or die?  Who enforces compliance, and how?  There
Stephen> are both volunteer and government run institutions which perform
Stephen> comparable services, but no language standard could possibly address
Stephen> these issues.

The standard already has a number of "implementation defined" things in it.
There need not be a clearing house to assign strings, it could be left to the
individual vendors *provided the standard gives them enough latitude*.  For
instance, if differentiating between compilers is done on the basis of one
number, then its very likely that vendors are going to conflict.  However, if
there is a number for the vendor's name (defined by some modulo arithmetic)
plus a couple other constants (for compiler and version number), then it
becomes extremely unlikely that they will conflict.  And even if there are
conflicts, it only affects the relatively few people that use both of the
conflicting compilers.

Stephen> Third, the standard could not enumerate all possible C compilers,
Stephen> since some would come into existence between approval and
Stephen> publication, let alone after publication.  So you would have to find
Stephen> out on a compiler by compiler basis what the special strings were
Stephen> and modify your program for each new compiler.  This is just what you
Stephen> have to do now with no intervention by the standard.

Hmmm.  This is your best point.  However, given the need for differentiating
between compilers (see below), having a single (set of) constants to query for
compiler information cuts down on potential conflicts between the names of
those constants and what someone may choose for their own constant name (we
were using a VAX constant in our code before we realized VAXC is defined by
the compiler -- missed it by one letter).  It also cuts down on the
misinterpretations that occur by new users of a compiler ("hmmm, what
constants does *this* compiler define?").

Stephen> Finally, your proposal doesn't help with compilers which do not
Stephen> follow the ANSI standard for whatever reason.

Its not meant to help with the compilers, its simply to allow users to gear
their code to quirks in (possibly braindead) compilers.  In the real world,
users can't always abandon a compiler or a vendor when something they really
need doesn't work as expected with a particular compiler.  This may especially
be a problem with an evolving standard like C++ where various vendors may call
themselves ANSI-compliant (and so define __cplusplus__) and either not truly
be compliant or have the standard change on them (as in 1.2 to 2.x).
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"