Difficult handling of structures with 64 bit builds

General
1

I am running into some rather painful coding issues with making some code 64 bit compatible.

It’s about a library (zlib) I link to. I starts with the problem that I need to declare two separate structures for 32 and 64 bit. Due to that need, I also cannot declare a single variable for accessing the structure any more, either. This all leads to lots of duplicated code because there’s also no way to alias names (as it’s possible with “#define” in C, for instance). This is all a huge pain in the rear, and I get the impression this whole 64 bit thing is still pretty much in a beta state and rushed.

I wonder if there will even be an improvement with structures in the future? I already learned that Xojo doesn’t think it’s necessary to have a 64 bit friendly CGFloat type (even though there are other OS specific types such as OSType and CFStringRef, for instance).

2

64-bit is officially considered beta right now. Not being able to run/debug adds to the rushed feeling.

3

You can define the structure twice with the same name and then make one only available in 32bit and the other only available in 64bit. I haven’t converted iOSKit to using this because of backwards compatibility concerns but quick tests during beta showed it worked fine.

4

or have on version which uses data types like integer and ptr which auto size depending on bit depth.

5

Jason, when someone directed me to the Attribute “StructureAlignment” in another thread, I noticed that there are now the options to specify a struct for either 64 or 32 bit. Whew! Now, that’s what I had been looking for (why are there two tabs that one has to switch between instead of showing it all in one where it would all fit?!?).

Anyway, much better now.

6

You still cant define two different structures with the same name even though you might have one available in 32 bit and the other only 64 bit

I’d use

#if Target32Bit
    dim whatever as my32bitstructure
#else
    dim whatever as my64bitstructure
#endif

now all code refers to “whatever”

7

Norman, I cannot do that with a property declaration, though, and that’s what my issue was.

8

[quote=232714:@Norman Palardy]I’d use

#if Target32Bit
dim whatever as my32bitstructure
#else
dim whatever as my64bitstructure
#endif
now all code refers to “whatever”[/quote]

It seems like autocomplete ignores anything declared in an #if block, will that be fixed or is it just the way it is?

9

IT has no idea if the block will be the 32 or 64 bit block that is compiled so I dont see that it will be fixed

10

Makes sense. Could it be made to assume one or the other? Or maybe look at the build settings for the current platform? Not a huge deal, but it’d help reduce typos…

11

Then its wrong half the time
Current platform may be wrong just as frequently since if you working on code for Windows & the structure for current platform is mac specific …
Or if its set for this computer as 32 bit and you’re writing 64 bit code

A project, when being edited, has no notion of what it will be built for
What happens if you unselect ALL the build options ?

Loads of fun

12

How about adding a ‘float’ datatype? Avoid this ruckus? Then users can simply declare a structure with ‘float’ types and be done with it?

13

Not my call to make

14

Please add support for <https://xojo.com/issue/39802>
It would allow you to define a float/double type and things like an index type who’s underlying type is platform dependent.

15

I know Joe & I discussed the chameleon float type and I forget the details about it but I think its in the “unlikely to occur” pile for technical reasons (but I dont recall what they are)

IMHO - the “index type” I have my doubts about
Far too much obtuse code has been written C’s typedef and that seems a lot like it - just not called typedef

16

Then it should just put both into the autocorrect :wink: That will never be wrong as we can just pick the right thing. Of course that adds more stuff to the autocorrect list to go through.

17

[quote=233075:@Norman Palardy]IMHO - the “index type” I have my doubts about
Far too much obtuse code has been written C’s typedef and that seems a lot like it - just not called typedef[/quote]

Think of it from this perspective. You open a project you haven’t looked at in a few months and it doesn’t run. You suspect one or more of 20 declares to be the issue. You haven’t looked at the API’s in months. You go through each declare one by one and dig through the API docs and finally after many hours of digging find that one declare had a type of int32 where it should be integer (CFIndex). If you could have created a type (CFIndex) in your project, then the declare would have looked like something representing the docs that it came from and been a breeze to find and fix. Not to mention the ability to fix the CFIndex definition and not have to look through every declare in the project and check to see if any other int32’s are actually CFIndex’s…

The fact that Apple,Microsoft, and every Linux library I’ve looked at have typedefs all over them just means that adding them to Xojo would make code more readable. Using integer where the parameter is defined as CFIndex, makes it harder to cross reference and harder for another developer who is familiar with the framework/.dll/.so to read. It’s all semantics…

I don’t see where it would become a problem, since there would really be no need for it outside of declares, but a huge plus for declare readability (IMHO)

18

+1000

19

Also related in helping this would be <https://xojo.com/issue/38261>

20

Also, we already have structures which are a typedef of sorts and I don’t think anyone would argue that having structures has led to less readable code than the old way of manually constructing memoryblocks field by field… :stuck_out_tongue:

I’d much rather see the ability to alias types over just adding a CGFloat. It just makes more sense to me… CGFloat would be an addition to the language that only serves a purpose until 32bit is obsolete. While type aliases would solve the CGFloat issue and add value to the language for years to come…