[Openmcl-devel] Detecting "Bitness" of Application

Gary Byers gb at clozure.com
Mon Sep 17 22:41:45 PDT 2007

It doesn't completely hide the problem, but the Cocoa Bridge does 
something like:

(deftype ns:cgfloat () #+32-bit-target 'single-float
                        #+64-bit-target 'double-float)


(defconstant ns:+cgfloat-zero+ #+32-bit-target 0.0f0 #+64-bit-target 0.0d0)

The latter means that you can sometimes write constants as

(float 1 ns:+cgfloat-zero+)

Some of the stuff introduced in the 070408 release and described in the
release notes is also intended to make this sort of thing easier:

(ns:with-ns-rect (&rect 0 0 Width Height)

will ensure that all of the fields of the NSRect are CGFloats.

I may be mistaken (and I'm too lazy to check at the moment) but I
think that the CG* geometry structures (CGPoint, CGRect, etc) are
entirely equivalent to their NS* counterparts.  If they aren't
literally the same foreign type (simply identical in their layout),
then it's probably true that the bridge has better support for the
NS* variants.

On Mon, 17 Sep 2007, Brent Fulgham wrote:

> In working with the 64-bit Intel OpenMCL (on Mac) I am finding lots of
> places where API calls through the FFI require explicitly declared
> double-float values in 64-bit mode.
> A good example would be something like:
>   (rlet ((&rect :<CGR>ect  :origin.x 0.0d0 :origin.y 0.0d0
>                                             :size.width (ccl::%double-
> float Width) :size.height (ccl::%double-float Height)))
>     (let* ((colorSpace (#_CGColorSpaceCreateDeviceRGB))
>            (&bitmapCtx (#_CGBitmapContextCreate toBuffer Width Height
> 8 bytes-per-row colorSpace #$kCGImageAlphaNoneSkipLast)))
> In 32-bit OpenMCL, the CGRect is perfectly happy being initialized
> with a basic "1.0" (or even "1.0s0").  However, in 64-bit mode, I am
> required to declare using the "1.0d0" notation.  This isn't such a big
> deal, but what if I want code that might compile in 32-bit mode?
> Is there a bit-width-agnostic way to make declarations such as the
> above?
> Thanks,
> -Brent
> P.S.  For people interested in what OpenMCL can do, I have some
> examples of OpenMCL do some simple OpenGL renderings using the Open
> Agent Engine logic.  Rumor has it that this stuff might even work in
> 64-bit mode...  (see http://lwat.blogspot.com/).
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list