incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farid Zaripov" <Farid_Zari...@epam.com>
Subject RE: svn commit: r641324 - /stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp
Date Wed, 26 Mar 2008 14:57:02 GMT
> -----Original Message-----
> From: faridz@apache.org [mailto:faridz@apache.org] 
> Sent: Wednesday, March 26, 2008 4:29 PM
> To: commits@stdcxx.apache.org
> 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: http://svn.apache.org/viewvc?rev=641324&view=rev
> Log:
> 2008-03-26  Farid Zaripov  <farid_zaripov@epam.com>
> 
> 	* 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
_RWSTD_NO_REPLACEABLE_NEW_DELETE
macro is defined in <rw/_config-msvcrt> for all versions and I think
it's not correct.

  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.
In libcxxx.lib the methods of bad_alloc class are located in 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.

  So the question is why we are define the methods of bad_alloc class as
not inline?
I think we can safely define them as inline (they all are simple enough
to inline). 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?

Farid.

Mime
View raw message