> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 26, 2008 4:29 PM > To: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > > * 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.
