davidm@uunet.UU.NET (David S. Masterson) (05/06/91)
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!"
steve@taumet.com (Stephen Clamage) (05/07/91)
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
joe@proto.com (Joe Huffman) (05/07/91)
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
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/08/91)
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!! / \***************************************************************************/
davidm@uunet.UU.NET (David S. Masterson) (05/09/91)
>>>>> 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!"