Please add a Float type that aliases like Integer and UInteger

Please add a Float type which will alias to Single on 32bit and Double on 64bit. This will greatly simplify declares between 32/64bit since we currently have to write two declares using compiler directives to select the correct declare based on the build type. For example with the UIColor class, we currently have to do this:

[code] #if Target32Bit
declare function initWithComponents lib UIKitLib selector “initWithRed:green:blue:alpha:” _
(obj_id as ptr, red as single, green as Single, blue as Single, alpha as Single) as ptr
#elseif Target64Bit
declare function initWithComponents lib UIKitLib selector “initWithRed:green:blue:alpha:” _
(obj_id as ptr, red as Double, green as Double, blue as Double, alpha as Double) as ptr


With a float type we would be able to simplify this to:

declare function initWithComponents lib UIKitLib selector "initWithRed:green:blue:alpha:" _ (obj_id as ptr, red as Float, green as Float, blue as Float, alpha as Float) as ptr Super.Constructor(initWithComponents(Allocate(NSClassFromString("UIColor")),red/255,green/255,blue/255,(255-alpha)/255)

which would work on both 32 and 64 bit builds.


To add to this, if you’d have to declare a Structure type with CGFloats, you cannot even use “#if” for that, so it would get really ugly to handle this without an auto-sizing float type.

It’s not that difficult, I do this all the time. Just create a Structure (preferably the “bigger” one) as standard, say NSPoint ( X As Double, Y As Double) and another structure NSPoint32Bit (X As Single, Y As Single).
Add a module with conversion methods between both and then you can go like

#if targetmacos #if Target64Bit Declare sub translateOriginToPoint lib AppKit selector "translateOriginToPoint:" (id as ptr, aPoint as NSPoint) translateOriginToPoint id, apoint #elseif Target32Bit Declare sub translateOriginToPoint lib AppKit selector "translateOriginToPoint:" (id as ptr, aPoint as NSPoint32Bit) translateOriginToPoint id, APoint.toNSPoint32 #endif #endif

Ulrich, your horrible example only helps to show why we need a separate Float type that makes this easier. I hope you’ve added your vote to the feedback case. Or are you actually proud of typing this convoluted mess all the time?

Hehe, no, I’m absolutely not and wish it would be easier. Just wanted to say “#If” is possible but never meant it would look nice. Each time I have to add such a declare I shy a bit from it first.
Adding points was a good point, Thomas: I removed one wish that isn’t relevant anymore and dedictaed the free points to the CGFloat request.

I’m still on the fence at the moment… We have a new project that’s still being designed, and I’m really trying to figure out if there is any alternative way of doing this.

I haven’t run into the need for this yet, but the reasoning seems solid.

I worked around this by creating a few bridge classes with operator convert. You can see the NSPoint, NSRect, and NSSize classes in the Foundation module of iOSKit. It’s still not as good as having a built in data type but it does simplify the code so it is more readable and easy to work with. It also means that we don’t have to declare two properties, one for each type of struct, but can I instead return those classes. Delegate methods still require two versions though for each architecture.

This came up at XDC.
One thing that was mentioned was to try & hide the structure & it’s details from yourself & the users of your code.
So don’t return NSRect (or whatever you name your equivalent 32/64 bit structures) from YOUR methods.
Take 4 doubles by ref and in the method use the 32 or 64 bit structure as needed.
Or pass in and out instances of a class you control that uses “double” and deal with the details of 32 / 64 bit in private.
Methods that return CGFloat you should return doubles which work either way.

This can only go so far and I know Joe & I have discussed a “Float” type that is 32 bit on 32 bit targets and 64 bit on 64 bit targets.
At this point that’s all I can relay.
We’ve discussed it.

The trouble without having a ‘float’ object, is that it requires much duplication and bucket loads of #if/#endif.

Creating a new application from scratch isn’t so bad as everytime you need a declare you can write the #if/#endif and create the duplicate structures.

Trouble is all our older applications, will need us to go through every function that uses a declare and make sure that it’s been properly updated. For one of our apps, this could days, possibly weeks… and this excludes any external methods…

All our CoreGraphics stuff is in external methods, so we don’t have functions where we can add #if/#endif.

From my perspective a ‘float’ type that can be used for declares, means I search and replace ‘singles’ in my declares, external functions and structures. While it will still take time, nowhere near as much time, my code should be more reliable and there’ll be no need for duplication.

As it stands, the easiest solution for me, is to stick with 32-bit until Xojo’s 64-bit is fully operational then to make the switch to 64-Bit solely.

Please seriously consider this.

Right - thats why I said

At the moment all I can definitively say is “we’ve discussed it”

for us users, that is the first big step. We know good things come after that.

Is case anyone missed it, the new CGFloat type is available in 2015r4.

The release notes say, that it will be deprecated after 32bit is gone. I think that this should be mentioned on

I agree. It is noted on the CGFloat page now.

CGFloat is the most exciting part of “R4”! converting some really old projects is so much easier and quicker.

Little change with a big effect I think. It makes using declares for OSX much more easier and you don’t
need to double declare+struct (NSRect…) for 32/64bit anymore.

I am totally happy with CGFloat. 20015R4 is one my favorites. Good work!