Just a single data point, but I am a full time developer and in the last 15 years using Xojo, I have never used a UInt-anything.
Nope it’s not rare, we use it alot in protocols. I bet many more protocol implementations exist in xojo.
We had a crash in EasyTCPSocket that may be because of this, i’m not sure but it give a light .
How to reproduce perhaps.
It used to be Integer, not it’s int32 since a while. This was changed by Xojo…
I most commonly use UInt64 for bit masking. That gives me 64 booleans I can pack into a single variable.
There are places in the framework this comparison bug can bite. It’s a stretch of course, but URLConnection.ReceivingProgressed uses Int64 for its parameters, which means it was designed to handle very large payloads. First of all, those should be UInt64 parameters because they should never logically be less than zero, so that would double the upper bound. But second of all, trying to determine if bytesReceived is greater than zero in a 32-bit app, with a total that is greater than an Int64 can hold, then the comparison will fail. Like I said, this scenario is WAY out there, so I don’t really expect this to sway any opinions. My point however is that comparing integers is faulty even when using the framework.
And @DerkJ is right, unsigned values are common in protocols and also when dealing with binary data.
I’ve also yet to see any examples of how fixing integer comparisons would negatively impact existing code. To be fair though, that may not happen until after Xojo’s morning meeting, if at all.
sorry, this is not a serious answer.
the tale of the citizen developers has tired us all.
@Geoff_Perlman you already explained why Xojo Inc. does not feel good about changing this compiler behaviour. I hope the following Feature Request may be a solution Xojo is willing to at last try with Xojo Testers: feedback://showreport?report_id=61921
Thank you for listening.
The current behaviour is non intuitive. IMHO, it should have been considered when tackling other non intuitive aspects of the eco-system as renaming APIs (v2).
Also, I do no think the problem is limited to Uint vs Int. What’s about currency vs doubles for ex.
Having to CType so often is cumbersome for these simple cases where the compiler could do a better job. Ctype does not help with speed also.
I must say I was bitten several times with this (apps running specialized serial and net prototocols, accounting, etc.). I am more confident in the behaviour of old Fortran 77 compilers than Xojo in this respect, which is a bit disappointing.
Uint all the time when bit masking, handling serial communications, porting Java code…
Just also chiming in to say that I also use Unsigned integers, not only in my code, but also when working with Apple’s API.
Take the NSArray object for instance, it’s count function returns a Unsigned integer.
Can you show one piece of code, that depends on the current behavior?
I rather expect that code usually works and randomly fails unexpectedly if the number is bigger/smaller and the wrong result comes.
Thanks for quoting me in the Feedback case.
If you think feedback://showreport?report_id=61921 would help, maybe put a few Points onto it?
I added it to my top cases.
I wouldn’t get your hopes up though. One of my top cases has been in Feedback for 12 years and hasn’t been implemented: feedback://showreport?report_id=30
That one may be really tricky as you need to have metadata about all the expressions, e.g. which variable to query on which object and then do the query. I think to find from mouse position the text line is easy, but that metadata to know what variable to query at debug time may be tricky.
I have no doubt that it’s hard but the debugger in Xojo could really use some love. Many other IDEs and development environments offer this feature (as well as cooler things like like code injection, etc).
It may show up when you check 64-bit UInt64 field in structure or memoryblock for flags:
// let's say you have some memoryblock Dim m As New MemoryBlock(16) // we just fill it with some random value including setting top flag m.Int64Value(0) = -1 // now let'S say you grab a 64-bit UInt64 flags field from a structure used in a declare Dim flags As UInt64 = m.UInt64Value(0) If flags > 0 Then // is at least one flag set? // never comes here Break Else // this happens Break End If
if flags<>0 Then
be more appropriate?
Well, for an UInt64, the compare for > 0 and <> 0 should result in same result.
Wow! Your comment reads as patronizing, dismissive and utterly insulting to citizen developers. Perhaps you want to rephrase it?
For the record, citizen developers have just as much potential as professional developers to create complex and competent code. Citizen developers just don’t earn a living wtith that code (yet for some).
Perhaps, but I’d avoid a comparison that hints that I consider the variable possibly has a numeric value in it. Compare to zero/non-zero or mask and compare to zero/non-zero.
I follow this discipline to assist me when I look at the code next time and can’t remember what it’s for