Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: STDCXX-509
Date: Wed, 17 Oct 2007 12:19:07 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA6EB@exchmail01.Blue.Roguewave.Com>
Thread-Topic: STDCXX-509
Thread-Index: AcgQ47pjPSVOxERJRRac4G8FDInE8wABcrGw
References: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA6E8@exchmail01.Blue.Roguewave.Com>
 <47159353.1030509@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA6EA@exchmail01.Blue.Roguewave.Com>
 <471646AA.5080901@roguewave.com>
From: "Travis Vitek" <tvitek@roguewave.com>
To: <stdcxx-dev@incubator.apache.org>


>Martin Sebor wrote:
>
>Travis Vitek wrote:
>> So I've been looking at the issue of the missing symbols for the
>> destructor, copy constructor and assignment operators for bad_cast,
>> bad_typeid and exceptions. Specifically, these symbols...
>
>So based on the config macros below, 4.1.3 shouldn't have had
>the definition of the exception copy assignment operator in it
>(i.e., it should have come from the runtime library), whereas
>4.2.0 should have it in it. Yet the 4.1.3 examples aren't
>finding the symbol either in the MSVC runtime (which is the
>same), or in the 4.2.0 dll?
>

Nope, you're backwards here.

As an example, the config.h for 4.1.3 does _not_ define
_RWSTD_NO_BAD_CAST_ASSIGNMENT [the define is commented out], so the
4.1.3 library will have bad_cast::operator=3D() defined. The 4.2.0 =
library
does have the macro defined, so the symbol omitted from the library.

>
>You are running the 4.1.3 examples with the 4.2.0 library,
>right? I.e., not 4.2.0 examples with the 4.1.3 library. Just
>checking.
>

Yes. As outlined in my previous e-mail, I'm running the 4.1.3
examples/tests with the 4.2.0 dll.

>Martin
>
>>=20
>> The 4.1.3 config.h header has the following defines
>>=20
>>   // #define _RWSTD_NO_BAD_CAST_ASSIGNMENT
>>   // #define _RWSTD_NO_BAD_CAST_COPY_CTOR
>>   #define _RWSTD_NO_BAD_CAST_DEFAULT_CTOR
>>   // #define _RWSTD_NO_BAD_CAST_DTOR
>>   #define _RWSTD_NO_BAD_CAST_WHAT
>>=20
>>   // #define _RWSTD_NO_BAD_TYPEID_ASSIGNMENT
>>   // #define _RWSTD_NO_BAD_TYPEID_COPY_CTOR
>>   #define _RWSTD_NO_BAD_TYPEID_DEFAULT_CTOR
>>   // #define _RWSTD_NO_BAD_TYPEID_DTOR
>>   #define _RWSTD_NO_BAD_TYPEID_WHAT
>>=20
>>   // #define _RWSTD_NO_EXCEPTION_ASSIGNMENT
>>   // #define _RWSTD_NO_EXCEPTION_COPY_CTOR
>>   // #define _RWSTD_NO_EXCEPTION_DEFAULT_CTOR
>>   // #define _RWSTD_NO_EXCEPTION_DTOR
>>   // #define _RWSTD_NO_EXCEPTION_WHAT
>>=20
>> The 4.2.0 config.h header has the following defines
>>=20
>>   #define _RWSTD_NO_BAD_CAST_ASSIGNMENT
>>   #define _RWSTD_NO_BAD_CAST_COPY_CTOR
>>   #define _RWSTD_NO_BAD_CAST_DEFAULT_CTOR
>>   #define _RWSTD_NO_BAD_CAST_DTOR
>>   #define _RWSTD_NO_BAD_CAST_WHAT
>>=20
>>   #define _RWSTD_NO_BAD_TYPEID_ASSIGNMENT
>>   #define _RWSTD_NO_BAD_TYPEID_COPY_CTOR
>>   #define _RWSTD_NO_BAD_TYPEID_DEFAULT_CTOR
>>   #define _RWSTD_NO_BAD_TYPEID_DTOR
>>   #define _RWSTD_NO_BAD_TYPEID_WHAT
>>=20
>>   #define _RWSTD_NO_EXCEPTION_ASSIGNMENT
>>   #define _RWSTD_NO_EXCEPTION_COPY_CTOR
>>   #define _RWSTD_NO_EXCEPTION_DEFAULT_CTOR
>>   #define _RWSTD_NO_EXCEPTION_DTOR
>>   #define _RWSTD_NO_EXCEPTION_WHAT
>>=20
>> This is pretty consistent with what I'm expecting. I'm=20
>looking into the
>> config tests now to see why we have a change in behavior=20
>with the same
>> configuration.
>>=20
>> Travis
>
>