You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@stdcxx.apache.org by fa...@apache.org on 2008/03/26 15:29:27 UTC
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 <fa...@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.
Modified:
stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp
Modified: stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp
URL: http://svn.apache.org/viewvc/stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp?rev=641324&r1=641323&r2=641324&view=diff
==============================================================================
--- stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp (original)
+++ stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp Wed Mar 26 07:29:17 2008
@@ -33,6 +33,9 @@
#include <new>
#include <string>
+#ifndef _RWSTD_NO_REPLACEABLE_NEW_DELETE
+ // disabled for compilers that can't reliably replace the operators
+
void* operator new (std::size_t n) throw (std::bad_alloc)
{
void* const ptr = std::malloc (n + sizeof n);
@@ -48,6 +51,8 @@
std::free ((std::size_t*)ptr - 1);
}
}
+
+#endif // _RWSTD_NO_REPLACEABLE_NEW_DELETE
struct InputIterator: std::iterator<std::input_iterator_tag, char>
{
RE: svn commit: r641324 - /stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Wednesday, March 26, 2008 5:53 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r641324 -
> /stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp
>
> > _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?
Damn, I forgot about this feature of dynamic libraries on Windows.
Sure, we can't use the replacement new/delete operators in shared builds
on MSVC and ICC/Windows.
Farid.
Re: svn commit: r641324 - /stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----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 <fa...@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.
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
RE: svn commit: r641324 - /stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp
Posted by Farid Zaripov <Fa...@epam.com>.
> -----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 <fa...@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.