PureBasic Forums - English

Hi,

I know this has been discussed extensively by the past and there is probably already one or several feature requests for this, but I recently stumbled on an issue directly related to the fact that PB does not have a native unsigned long type and using x64 compilation.

The issue happened when having several integers constants definition having values higher than signed long limit and by using a structure containing variables of long type (C u32int_t/PB.l to match the external library API). I believe PB internally store constant values as 64 bit integers (q). When reading the value of those variables back and comparing those values with the constants value, wrong results appeared.

When both values are internally the same (this can be verified by using StrU(value,#PB_LONG)), *comparison* fails!

For instance if you have a long variable mylongvariable.l and a constant of value higher than signed long limit, both with the same internal value:
If #SOME_CONSTANT = mylongvariable
; FAILED!!!!, code will never enter this section
EndIf

I'm not sure how others currently deal with this situation, but to me this lack of native unsigned long type in PB leads to this kind of bugs that can be extremely hard to detect.

You can use & $FFFFFFFF for comparison.

do you mean this ?
Yes, it's a gigantic annoyance and source of bugs. But we already knew it, and the painful workarounds too (truncation of quads, promotion of longs, bitwise comparison, what works in a specific case).

I don't think asking for unsigned again will change anything.

They already answered about this and said ... you know what.

DontTalkToMe wrote:../.. I don't think asking for unsigned again will change anything../..

Well, I think it is a good thing to remind this kind of issues from time to times, especially for PB newcomers.
And who knows, perhaps in a spark of illumination opinion may change..

unsigned dword is my only real wish, because I can't implement it myself. I want to get stuck on a deserted island with dwords, because i will thrive, there'll be no stopping me but the shackles are on in the meantime. I have faith it will come! there have been so many amazing features added to PB especially over recent years, so I refuse to believe it will never come glass of iced coffee half full here

I longer no believe that in PB add unsigned variable types...

I have long offered simple ways http://www.purebasic.fr/english/viewtop ... 10#p485110
http://www.purebasic.fr/english/viewtop ... =3&t=52929
http://www.purebasic.fr/english/viewtop ... 79#p414979
but appear new versions of the PB, but this functions not added, but they really need!

Was it officially stated why unsigned variable types would not be added to PB? Like is it the kid-gloves treatment? Or very difficult procedure to offer support for?

Thunder93 wrote:Was it officially stated why unsigned variable types would not be added to PB?

more or less
http://www.purebasic.fr/english/viewtop ... f=3&t=6896

there was also some mention of "Java and the fact it lacked unsigned too, so as you can see someone else think it's a good idea" or something like that

anyway there have always been a lot of people who thought it sucked
http://www.darksleep.com/player/JavaAnd ... Types.html

Java 8 finally introduced not new data types but at least ways to access the original signed data types as unsigned
http://stackoverflow.com/questions/2555 ... -in-java-8

Interesting reads DontTalkToMe, thanks.

I have never seen that 2003yr old PB topic before.

in the mean time you can try this work around
http://www.purebasic.fr/english/viewtop ... 12&t=65312

DontTalkToMe wrote:

Thunder93 wrote:Was it officially stated why unsigned variable types would not be added to PB?

more or less
http://www.purebasic.fr/english/viewtop ... f=3&t=6896

Reading that post for the first time too.

Fred kind of ironically asked for a very interesting question:
"../..Do you want casts be introduced in a basic langage ?../.."

In fact, yes! That could be a very good idea, in fact, as right know - at least on my side - with EnableExplicit and all, I'm using PureBasic like a typed language anyway, always declaring the types of the variables I'm using. Having casts introduced in PureBasic would just feel natural at that point, and if it could solves the use of unsigned integers.. Yet this could potentially lead to performance improvement.

I'm in for it : )

I would like function overloading, unsigned, casts, real constants, but the odds are the only way I'll get them is by using another language.

The sooner you recognize that, the less you are going to suffer.

grabiller wrote:Reading that post for the first time too.

Then read this too
http://www.purebasic.fr/english/viewtop ... 782#p37782

Fred wrote:... it would include casts, like in C which I don't want

I don't see much difference now with casts already existing anyways. So I'm in also to see this enhancement, extended (much needed) support.

DontTalkToMe wrote:I would like function overloading, unsigned, casts, real constants, but the odds are the only way I'll get them is by using another language.

Hah, the problem is that other languages are even worst, at least for me ^^
For example if you take FreeBasic (which has enough nice stuff, including those unsigned types), you'll encounter that it doesn't has nice IDE, nice debugger and it's STL still is very poor and making something "more or less serious" with this language is extremely painful and full with workarounds and reinvented bicycles.

If you take C/C++ which offers everything, you probably soon get tired of it's "bureaucracy" which is good maybe for large teams (or if you working only with single or very few long-term projects for many years), but not for single programmer with limited resources.

.NET/python/delphi/go/rust and any_other_known_crap also having their "fatal injuries"

So Purebasic stupid (and often unexpected) limits, bugs and such things are often annoying, but at least for now I don't know something else which would in total have less props than PB and nicely replace it ^^ It might change in year or two (just look how fast languages are creating and evolving nowadays), but currently I don't see or didn't found any better replacement. For now getting pain with any other language makes sense for me only if going to work for someone and get fixed $ for this pain (the pain from PB is much lower so it can be used to code for myself, or without any payment).

In other and shorter words, PB looks like best of worst and terrible ones, and thus best of any existing :3



PS. There was many said about UINTS/ULONGS already, I just say that this is one of things that language must have to meet modern standarts and usefulness. It was good for MS VB5/6 to not have uints in 2000x, but not for VB.NET in 2016.

btw how does VB.Net handle conversions between Long<>Dword? like does it require casting or is it automatic or..?

I have a good friend who programs in Powerbasic, i havent looked into it much because unless im missing something it seems it's for Win32 only, but I got him to send me some examples which were quite interesting because Powerbasic also compiles into asm, and allows <quote>"seamless"</quote> use of longs and dwords without any casting! Im just waiting for another .exe from him with some custom requested calculations so I can look more closely into what "auto-cast assumptions" i'm guessing it's making, and assuming i get that soon i will post back some results hopefully later today if i can get my head around them lol

ps. Purebasic is able to automatically handle conversion between signed/unsigned BYTE (.a/.b) and WORD (.w/.u), no casting required, so if it can already do such seamless conversions with 8 and 16bit i dont understand why the same approach cant be extended to 32bit