Re: UB issue -- include order?
Re: UB issue -- include order?
- Subject: Re: UB issue -- include order?
- From: Mark Stultz <email@hidden>
- Date: Mon, 20 Mar 2006 14:16:47 -0600
Yes, thank you George. Always coming through, aren't you?
After you pointed out the real issue, these two URLs helped out:
Paul Carnine's "Re: Carbon, gcc 4.0.1, override new/delete - SOLVED" message
on the Carbon-dev mailing list, as well as Apple's article, "C++ Runtime
Environment Programming Guide":
http://lists.apple.com/archives/carbon-dev/2006/Jan/msg00707.html
http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntim
eEnv/index.html
I'm posting these URL's to the list in case anyone Googles (or
worse--searches via lists.apple.com) for this specific issue. What *is* the
issue with lists.apple.com being painfully slow more often than not (or so
it seems)?
Best,
Mark
On 3/20/06 11:51 AM, "Andrew Satori" <email@hidden> wrote:
> Thanks for the reminder George, I just bumped into the same
> issue :-) talk about your timely topics.
>
> Andy
>
> On Mar 20, 2006, at 11:21 AM, George Warner wrote:
>
>> On Sat, 18 Mar 2006 13:46:09 -0800, Eric Albert
>> <email@hidden> wrote:
>>> On Mar 18, 2006, at 12:42 PM, Brad Oliver wrote:
>>>> On Mar 18, 2006, at 3:28 AM, email@hidden
>>>> wrote:
>>>>> For some reason it is hitting our memory manager inside a clean
>>>>> up of
>>>>> an
>>>>> Apple Event? I'm not sure why it would hit our own memory manger.
>>>>> I'm not
>>>>> sure if this is with include path order or what is the cause.
>>>>> We are
>>>>> redefining new and delete and the such, but I did not think this
>>>>> could
>>>>> affect Apple's API. I have not encountered this on the PPC. Any
>>>>> suggestions would be great.
>>>>
>>>> The only explanation I can think of is that Apple's routine calls
>>>> operator delete - but only on x86. Since you've overridden that
>>>> exact
>>>> prototype, the linker chooses yours and they get called for all
>>>> code...? I could be way off though. ;-)
>>>
>>> I think it's more that libstdc++ is a dynamic library as of gcc 4 and
>>> 10.4, so when targeting 10.4 or later with gcc 4 if you override
>>> operator new and operator delete in the global namespace your
>>> versions
>>> of them will be used for all calls to those functions. That's
>>> true on
>>> both Intel and PowerPC.
>>>
>>> I think there are ways to get your operator new/operator delete used
>>> only for your code, but I'm afraid I don't know enough about C++ to
>>> suggest them. Hopefully Howard Hinnant or one of the other C++
>>> experts
>>> around here can chime in with the right solution (and whether
>>> there's a
>>> way to do it at all).
>>
>> We had several developers hit this early in the DTK cycle. IIRC the
>> solution
>> was to make sure that two-level namespaces were enabled... and used.
>> --
>> Enjoy,
>> George Warner,
>> Schizophrenic Optimization Scientist
>> Apple Developer Technical Support (DTS)
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden