incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Date Tue, 29 May 2007 17:38:52 GMT
Farid Zaripov wrote:
>> I wonder if it wouldn't be cleaner to move all the Intel C++ 
>> specific code out of _config-msvc.h and into _config-icc.h 
>> and make sure we #include the former only for MSVC and the 
>> latter only for Intel C++. One of the goals of separating all 
>> the compiler-specific hacks and overrides was to make it 
>> clear what's where and avoid accidentally breaking one 
>> compiler while fixing a problem in another. The way we handle 
>> MSVC and Intel C++ on Windows seems to go against the goal 
>> (even though the compilers are meant to be fully compatible).
>>
>> Thoughts?
> 
>   The Intel C++ compiler is just set of the binary tools (compiler,
> linker, .... and some
> processor optimized extension libraries (math library, integer and float
> vector class library).
> The package don't include the CRT library and uses the CRT from
> installed MSVC.
> I have the installed three versions of the MSVC: 7.0, 7.1 and 8.0. And I
> can build
> the some project using Intel C++ with any CRT which I have.
> 
>   I mean that some of the macros from _config-msvc.h is not
> compiler-specific, but CRT specific.

Right, good point. We don't make a distinction between compilers
and their runtime libraries. I don't think Intel C++ on Windows
is the only compiler that uses (parts of) another compiler's
runtime. AFAIK, IBM XLC++ on Linux works the same way (uses
gcc's runtime). I suspect there might be, or will be, others,
such as Sun C++ when Sun implements and deploys its gcc
compatibility mode. See Steve Clamage's comment in this thread:
http://forum.java.sun.com/thread.jspa?threadID=5173584

> If we want to separate the Intel and MSVC config files, we should
> copy-paste that
> macros into the _config_icc.h. Is that corresponds the goals?

Well, I guess we need to decide if it's a good idea to maintain
two sets of the same chunks of code or if it would be better to
factor the code into a common file. If the latter, we need to
decide on the mechanism we want to use to use the code with each
compiler. Here are the possibilities I see:

1. Status quo: For an Intel C++ installation on top of MSVC
_config.h #includes both _config-msvc.h and _config-icc.h,
and _config-msvc.h must be prepared to deal with it.

2. Duplicate CRT-specific macro hackery from _config-msvc.h
in _config-icc.h for Intel C++ on top of MSVC.

3. Move CRT-specific macros hackery from _config-msvc.h to
a new config header, say _config-msvcrt.h, and #include this
header from both _config-msvc.h and _config-icc.h, making
sure _config-msvc.h is #included only for MSVC and not for
Intel C++ on top of it.

Preferences? Any other possible ways to deal with this?

Martin

Mime
View raw message