Re: using long double math functions like sinl() with Cocoa
Re: using long double math functions like sinl() with Cocoa
- Subject: Re: using long double math functions like sinl() with Cocoa
- From: "Dr. Rolf Jansen" <email@hidden>
- Date: Thu, 4 Jan 2007 17:29:51 +0100 (CET)
- Importance: Normal
Eric and Tomas,
many thanks for your replies:
On Jan 4, 2007, at 3:59 AM, E. Wing wrote:
> So playing with your example, if I change your Cocoa program to a
> pure Objective-C program (just remove the #import <Cocoa/Cocoa.h>
> and NSApplicationMain, but still compile as Objective-C),
> the program produces the correct results.
I found this out too, and I came to the same conclusion, that there
is some redefinition in one of the Cocoa headers.
> Anyway, I tried wrapping the sinl calls into a separate pure-C
> dynamic library and then had an Objective-C program call my custom
> wrapper function from my dynamic library. This seemed to produce
> the correct results. So this might be a potential workaround. I
> would be curious to know the cause of this and if there is a
> better workaround.
It came also to my idea to wrap the required long double function
into a seperate library, however I did not came this far up to now.
Anyway it is nice to hear that this will work, so Eric, thank you
very much for sharing the results of your investigations.
On Thu, 04 Jan 2007 14:10:54 +0100 Tomas Hurka wrote:
> On Jan 4, 2007, at 3:59 AM, E. Wing wrote:
>>
>> So I'm speculating that there is something in the Foundation
>> headers that causes sinl to be mapped to sin (perhaps some
>> kind of #define).
>>
> Right, check
> /System/Library/Frameworks/CoreServices.framework/Versions/A/
> Frameworks/CarbonCore.framework/Versions/A/Headers/fp.h
> for #define sinl(x)
> and
> /System/Library/Frameworks/CoreServices.framework/Versions/A/
> Frameworks/CarbonCore.framework/Versions/A/Headers/ConditionalMacros.h
> for #define TYPE_LONGDOUBLE_IS_DOUBLE
Tomas, are you sure about this, that Cocoa utilizes the Carbon
<fp.h> math and not the Standard C <math.h> math functions?
> It looks to me like a bug.
Carbon math does not know anything about 128bit long doubles. It
still knows to convert 80/96bit extended floats besides providing
the standard 64/32bit arithmetic and trancendental math.
So, if Cocoa uses Carbon math, then it is not exactly a bug,
but a design flaw. Anyway, a compile time warning would
have been nice.
Please, can somebody confirm, that Cocoa is built on Carbon math?
In this case there would be no choice, other than to wrap the 128bit
math into a separate pure C library, as Eric lined out.
Best regards
Rolf Jansen
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden