incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: svn commit: r641324 - /stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp
Date Wed, 26 Mar 2008 15:52:46 GMT
Farid Zaripov wrote:
>> -----Original Message-----
>> From: [] 
>> Sent: Wednesday, March 26, 2008 4:29 PM
>> To:
>> Subject: svn commit: r641324 - 
>> /stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp
>> Author: faridz
>> Date: Wed Mar 26 07:29:17 2008
>> New Revision: 641324
>> URL:
>> Log:
>> 2008-03-26  Farid Zaripov  <>
>> 	* tests/regress/21.string.append.stdcxx-438.cpp: Don't 
>> define the replacement
>> 	operators new and delete on compilers, that can't 
>> reliably replace the operators.
>   The 21.string.append.stdcxx-438.cpp regression test failed to link on
> MSVC 8.0 and
> later and on ICC/Windows, that using the MSVC 8.0 and later CRT's. This
> patch is a
> temporary solution.
>   I tried to find the problem why on MSVC definition of the replacement
> operators new
> and delete causing to multiple definition symbol linker error. Actually
> this problem
> appears in static builds only, and also MSVC 7.1 doesn't have the any
> problems with
> replacement new/delete operators in any builds. But
> macro is defined in <rw/_config-msvcrt> for all versions and I think
> it's not correct.

IIRC, on Windows replacing operator new in one executable (.exe
or .dll) doesn't replace it in the other executables (.exe's or
.dll's) that the first one links with. That's probably why the
macro's #defined, no?

>   The some digging shows that problem appears when the compiled program
> uses std::bad_alloc
> class and the methods of this class is found in our libstdxx.lib and in
> libcxxx.lib at the same time.

What are libstdxx.lib and libcxxx.lib? Are they MSVC's libs or
is one of the ours?

> In libcxxx.lib the methods of bad_alloc class are located in new.obj

You mean in our rwtest's new.obj?

> along with new and delete
> operators. But in MSVC headers the methods of bad_alloc class are
> defined as inline. I don't
> know why the are also present in libcxxx.lib with external linkage.
> Maybe due to some special
> compiler switches or using another header files while the libcxxx.lib
> being built. If we define the
> all methods of bad_alloc as inline the new.obj is not used in link
> process and the program with
> replacement new/delete operators links successfully.

That could be the problem. Our config tests look for the member
functions of these classes in the C++ runtime library. If they
don't find them there, we define the out of line in our library.
But if they're defined inline in the compiler's own headers, that
may not be the right thing to do.

>   So the question is why we are define the methods of bad_alloc class as
> not inline?

I think one reason why I did it that way is to keep as much of
the implementation detail (ugly preprocessor conditionals and
the actual definitions of the functions) out of our headers.

The other reason might have been that defining some of them
inline might cause their vtables to be generated in every
object file that uses the class. That tends to lead to code
bloat and might cause problems when throwing exceptions
across shared library boundaries on some platforms (I don't
know this for sure, I'm just speculating here).

> I think we can safely define them as inline (they all are simple enough
> to inline).

We could do that for compilers like MSVC 8 where we know we
have a problem and we know that doing it is safe. I wouldn't
recommend doing it for all compilers.

> An another
> option is write config test to check if they are inline in compiler
> headers, then define them
> inline in out headers. In another case define them as they are defined
> at the moment.
>   Any thoughts?

This is a very tricky area of the library. I recommend caution
and lots of testing when making any changes.


View raw message