Compiler identification macros (please comment)
As recently come up (again) in the threads "Comment regarding __GNUC__ spoofing" "[config] Patch for Intel 8.0 + Dinkum lib" boost library developers have often a need to know the exact compiler in use, but they have no straightforward and easily maintainable way do that. The issue is that they can't just rely on compiler "identification" macros, as predefined by each compiler, because those are not *unique* to each compiler. Two typical cases are __GNUC__, which is defined both by g++ and Intel for Linux, and _MSC_VER which is defined by several compilers. A test for "real" g++, for instance, would look something like #if defined(__GNUC__) && !defined(__ICL) && !defined... which is unnecessarily tedious, error prone and hard to maintain. The problem would be solved if the config system exposed a macro for each compiler that it identifies. There seems to be agreement that this should be done, so please express your opinion about the names you prefer for the macros, or tell why you don't want them. I heartedly ask for *short* names, because preprocessing lines become easily enourmous otherwise (the typical test has the form: #if defined(MACRO_NAME) && (MACRO_NAME <= xx)). Currently, there are 16 config files in boost/config/compiler/ but we don't need so much macros immediately. So I just propose the following (other ones can be added on an "as needed" basis): BOOST_BORLAND BOOST_COMEAU BOOST_GNU (1) BOOST_INTEL BOOST_MSVC (2) ---- Notes: (1) since the other macros employ the name of the producing company, rather than the name of the compiler, BOOST_GNU seems more consistent than BOOST_GCC (though, of course, GNU is not a "company") (2) this is inconsistent, but it already exists. Maybe BOOST_MICROSOFT, or BOOST_MS, could be provided as a synonym. Genny.
"Gennaro Prota" <gennaro_prota@yahoo.com> wrote in message:
Currently, there are 16 config files in boost/config/compiler/ but we don't need so much macros immediately. So I just propose the following (other ones can be added on an "as needed" basis):
BOOST_BORLAND BOOST_COMEAU BOOST_GNU (1) BOOST_INTEL BOOST_MSVC (2)
These all look good to me.
---- Notes: (1) since the other macros employ the name of the producing
company,
rather than the name of the compiler, BOOST_GNU seems more consistent than BOOST_GCC (though, of course, GNU is not a "company")
Seems fine; BOOST_GNU is closer to what is currently used.
(2) this is inconsistent, but it already exists. Maybe BOOST_MICROSOFT, or BOOST_MS, could be provided as a synonym.
BOOST_MSVC is well-established. Adding a synonym will just lead people to wonder about possible differences in meaning. Perhaps there should also be BOOST_MPW and BOOST_DIGITALMARS, because of the ambiguity of __SC__. In fact, I don't see any reason not to add macros for each supported compiler. That way library authors won't have to keep track of which compilers have boost macros, and code won't have to be revised if more spoofing arises in the future. Jonathan
Gennaro Prota <gennaro_prota@yahoo.com> writes:
BOOST_BORLAND BOOST_COMEAU BOOST_GNU (1) BOOST_INTEL BOOST_MSVC (2)
Though it has been a while, I remember running into problems where the macros were tricked into thinking it was running Borland C++, and pulled in bug workarounds for Borland. The problem was, in reality I was using Comeau C++ with Borland as the backend C compiler, and some of the nonstandard workarounds would not compile with Comeau, when they were not needed in the first place. Just something to consider if a new compiler-detector scheme is implemented. -- Chris
Gennaro Prota wrote:
Currently, there are 16 config files in boost/config/compiler/ but we don't need so much macros immediately. So I just propose the following (other ones can be added on an "as needed" basis):
BOOST_BORLAND BOOST_COMEAU BOOST_GNU (1) BOOST_INTEL BOOST_MSVC (2)
---- Notes: (1) since the other macros employ the name of the producing company, rather than the name of the compiler, BOOST_GNU seems more consistent than BOOST_GCC (though, of course, GNU is not a "company") (2) this is inconsistent, but it already exists. Maybe BOOST_MICROSOFT, or BOOST_MS, could be provided as a synonym.
Personally I would prefer that they use the compiler name rather than the developer name. This is to avoid possible future (and past) conflict for companies that have more than one compiler. (1) Not sure why you didn't consider BOOST_GNUC, as that reflects the internal symbol so people should be familiar with it. (2) For Boost.Build we are standardizing on "vc" instead of "msvc". So BOOST_VC would be an option. It has the benefit of being shorter also ;-) It doesn't seem to make sense to just do this for such a small subset though. I would think we would want to make sure we at least define this for all the compilers that we test with. So at least adding: BOOST_CW (CodeWarrior).. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
"Rene Rivera" <grafik.list@redshift-software.com> wrote in message news:405F4527.2050808@redshift-software.com...
[...] Personally I would prefer that they use the compiler name rather than the developer name. This is to avoid possible future (and past) conflict for companies that have more than one compiler. [...]
I agree that the compiler name is better. Consider BOOST_INPRISE vs. BOOST_BORLAND, for example. ;) I think most people know the compiler names well enough that they will be familiar. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.581 / Virus Database: 368 - Release Date: 2/9/2004
"David B. Held" <dheld@codelogicconsulting.com> wrote in message news:c3nitg$v3m$1@sea.gmane.org...
"Rene Rivera" <grafik.list@redshift-software.com> wrote in message news:405F4527.2050808@redshift-software.com...
[...] Personally I would prefer that they use the compiler name rather than the developer name. This is to avoid possible future (and past) conflict for companies that have more than one compiler. [...]
I agree that the compiler name is better. Consider BOOST_INPRISE vs. BOOST_BORLAND, for example. ;) I think most people know the compiler names well enough that they will be familiar.
I'm not against using compiler names instead of company names, but I don't think it solves very much. Would we use the name of the development environment, or the name of the command-line tool? If we're really worried about one company producing more than one compiler, we should use the name of the command-line tool, since both tools could conceivably be offered in one development environment. Then we'd have funny names like BOOST_ICL and BOOST_MWCPPC In either case, the names can change from version to version, e.g., C++ Builder --> C++BuilderX bcc --> bccx (While it might make sense to have different macros for Borland 5.x and Borland 6.x -- since they're completely different compilers -- I wouldn't want the difference to be expressed as the presence or absence of 'X'.) Jonathan
Gennaro Prota <gennaro_prota@yahoo.com> writes:
As recently come up (again) in the threads
"Comment regarding __GNUC__ spoofing" "[config] Patch for Intel 8.0 + Dinkum lib"
boost library developers have often a need to know the exact compiler in use, but they have no straightforward and easily maintainable way do that. The issue is that they can't just rely on compiler "identification" macros, as predefined by each compiler, because those are not *unique* to each compiler. Two typical cases are __GNUC__, which is defined both by g++ and Intel for Linux, and _MSC_VER which is defined by several compilers. A test for "real" g++, for instance, would look something like
#if defined(__GNUC__) && !defined(__ICL) && !defined...
which is unnecessarily tedious, error prone and hard to maintain. The problem would be solved if the config system exposed a macro for each compiler that it identifies.
There seems to be agreement that this should be done, so please express your opinion about the names you prefer for the macros, or tell why you don't want them. I heartedly ask for *short* names, because preprocessing lines become easily enourmous otherwise (the typical test has the form: #if defined(MACRO_NAME) && (MACRO_NAME <= xx)).
If we define these compiler-identification macros properly (all are defined, most to zero), we can use a BOOST_WORKAROUND macro to eliminate the first condition. That should reduce the pressure to come up with short names, though I see no reason to use names longer than those suggested below.
Currently, there are 16 config files in boost/config/compiler/ but we don't need so much macros immediately. So I just propose the following (other ones can be added on an "as needed" basis):
BOOST_BORLAND BOOST_COMEAU BOOST_GNU (1) BOOST_INTEL BOOST_MSVC (2)
IMO we should try to do this in a big sweep if practical. I realize we'd touch a lot of code, so it may not be, but, but I think we have too many legacy compiler checks, using different conventions, in our source.
---- Notes: (1) since the other macros employ the name of the producing company, rather than the name of the compiler, BOOST_GNU seems more consistent than BOOST_GCC (though, of course, GNU is not a "company") (2) this is inconsistent, but it already exists. Maybe BOOST_MICROSOFT, or BOOST_MS, could be provided as a synonym.
I think we should use names of compilers rather than companies. Someday we may have several C++ offerings from the same company. -- Dave Abrahams Boost Consulting www.boost-consulting.com
In article <uekrke8bn.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> wrote:
I see no reason to use names longer than those suggested below.
BOOST_BORLAND BOOST_COMEAU BOOST_GNU (1) BOOST_INTEL BOOST_MSVC (2)
I would suggest using BOOST_CC_* or BOOST_COMPILER_*, to avoid possible ambiguities. For instance, BOOST_INTEL in and of itself does not make it clear whether it denotes a compiler-specific kludge or an architecture-specific kludge. If the full name of the macro is BOOST_FOO, then the assumption is that FOO will never be ambiguous within boost. It is therefore a poor choice to make FOO contain nothing but a vendor-chosen name, IMO. meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>
<snip>
I see no reason to use names longer than those suggested below.
BOOST_BORLAND BOOST_COMEAU BOOST_GNU (1) BOOST_INTEL BOOST_MSVC (2)
I would suggest using BOOST_CC_* or BOOST_COMPILER_*, to avoid possible ambiguities. For instance, BOOST_INTEL in and of itself does not make it clear whether it denotes a compiler-specific kludge or an architecture-> > specific kludge.
Maybe BOOST_CC_INTEL, BOOST_CC_INTEL_GCC and BOOST_CC_INTEL_MSVC given its different personalities might be appropriate. $0.02, Matt Hurd.
Miro Jurisic wrote:
In article <uekrke8bn.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> wrote:
I see no reason to use names longer than those suggested below.
BOOST_BORLAND BOOST_COMEAU BOOST_GNU (1) BOOST_INTEL BOOST_MSVC (2)
I would suggest using BOOST_CC_* or BOOST_COMPILER_*, to avoid possible ambiguities. For instance, BOOST_INTEL in and of itself does not make it clear whether it denotes a compiler-specific kludge or an architecture-specific kludge.
I second this. In addition to being more consistent and eliminating possible ambiguities, it would also make it much easier to search for compiler-specific patches. Mike
On Mon, 22 Mar 2004 19:05:48 -0500, David Abrahams <dave@boost-consulting.com> wrote:
If we define these compiler-identification macros properly (all are defined, most to zero), we can use a BOOST_WORKAROUND macro to eliminate the first condition.
Yep. I didn't think of this. If we do so, it's not necessary to have 16*16 defines. We could have 16 #defines to zero in select_compiler_config.hpp, and then, in each compiler-config file: #undef BOOST_THIS_COMPILER #define BOOST_THIS_COMPILER version This reduces the number of definitions from 16*16 to 16+16. Ok, I know you already thought to this... it was just to prevent possible objections :)
IMO we should try to do this in a big sweep if practical.
Yes. Ok with me.
I think we should use names of compilers rather than companies. Someday we may have several C++ offerings from the same company.
Yes, Jonathan makes a good point too, in this regard. Genny.
participants (9)
-
Chris Uzdavinis -
David Abrahams -
David B. Held -
Gennaro Prota -
Jonathan Turkanis -
Matthew Hurd -
Michael Glassford -
Miro Jurisic -
Rene Rivera