Farid Zaripov wrote:
-----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.
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.
Martin
