Unsigned dword/qword

[Keya]

hello, im just wondering why in 2016 Purebasic still only supports 8bit and 16bit unsigned datatypes? I dont like to ask for many features as i appreciate that Freds list is neverending, and actually PB already supports just about everything i could ask for, but this is fundamental, and so often we see unsigned dwords especially, but as PB programmer it seems we have two options - 1) fingers crossed and hope that signed Longs with half their positive range will be sufficient, or 2) using bit hacks and custom functions to basically do what the compiler should do ... both are clearly risky business hoping the programmer will always get it all right at all referenced locations of the code (almost never going to happen), and isn't that asking the programmer to do what the compiler should be doing anyway? supporting one of the most common programming datatypes that exist (i'm not asking for support of anything exotic, just fundamental, for which cpu opcodes even exist!) thankyou very much for your time and considering

[davido]

@Keya,
This topic has come up quite a few times.
Take a look at this old thread which documents some of the reasons why it probably won't be done:
http://www.purebasic.fr/english/viewtop ... 95#p296495

[User_Russian]

Yes, there are many difficulties, due to the absence of unsigned variables. It is a pity that they are not supported.

[Lunasole]

Well, the unsigned qword/dword are not widely used types. 99% things can be done and are done with signed.

I don't think it is big problem they missing, but of course it is better if they exists for completeness ("see, we now have all valuable types in PB, like in best European languages!1") and better compatibility with some C code/libraries.
So +1 the idea. Also @Freak said about PB commands complexity to use with unsigned -- but you don't need to even allow their usage with PB commands, can just present the type to be used in user code and supported with basic operators, etc.

[User_Russian]

For comparison of IPv4 addresses, pointers, times (ElapsedMilliseconds), etc., needed unsigned variables.
Pointers must be unsigned! http://www.purebasic.fr/english/viewtop ... =3&t=54966
It is a pity that these requests are not fulfilled, as well as requests for classes...

[Lunasole]

No, unsigned is not needed to comparison of any values, it can be done anyway, but of course such workarounds are nice source of errors [if forget to add it, with me it happened years ago ^^], also it is much longer and ugly with IFs, or converting to quads, or some other trash code. But that's generally not a problem, as there are rare cases when it is needed.
But I anyway rate for unsigned, they support just "must have" at least at level I described above, also agree that pointers should be uint. I don't think this level of support requires some complex work on whole PB library.

It is a pity that these requests are not fulfilled, as well as requests for classes...

Who knows. Fred is interested in SpiderBasic a lot, which has "client-server" relationship with PB and very high compatibility with it. It is really great thing as for web allowing to write code not as web-monkey but as normal native, and to be wide-usable by "professionals" it anyway needs to be free from any kind of stupid limits or noticeable functionality lacks which user has to compensate by himself. So let see.

[Keya]

@Keya,
This topic has come up quite a few times.
Take a look at this old thread which documents some of the reasons why it probably won't be done:
http://www.purebasic.fr/english/viewtop ... 95#p296495

Interesting thread ...

PureBasic uses single characters for all its basic types. "ub" doesn't fit that. Also the decision has been made. Its not going to change now.

So one of the key reasons for no support for unsigned is because ".d" is already taken and ".ul" would require 2 characters which goes against PB variables denoted by 1 character so it'd just be inconvenient ...... MessageRequester-instead-of-Msgbox("Hrm","Ooookay!?")
I can personally handle typing two letters instead of one, no problems at all! I mean when we use pointers we have to anyway, eg. *p.Ascii ... not *p.a

We don't see much value in adding unsigned long or quad especially since all PB commands expect signed long or quad numbers as input.

You don't, but the designers of seemingly every other compiler have identified the value of unsigned datatypes.

And PB already supports unsigned 8bit and 16bit, so its support of those goes against everything you just said.

An unsigned byte or word can be cast to a signed long and passed to all these functions without problems, but passing an unsigned long to a function that expects a signed one is trouble.

Agreed. So make the compiler support unsigned ones so there is no "trouble".

Also as Fred explains in the link by luis, mixing signed and unsigned is very tricky in the implementation/performance department.

It's never been a problem for any other compilers or programmers though.

Sorry freak but with all due respect all of your "reasons" sound purely just like "it's too hard for us to do". but it's without doubt that Fred is talented enough to implement it, PB speaks for itself there!

[Danilo]

It is a pity that these requests are not fulfilled, as well as requests for classes...

Who knows.

The PB Team knows!

You just need to deeply understand and accept/respect what they are communicating:

[…] the decision has been made. Its not going to change now.

PureBasic won't be object oriented, period.

Not everybody wants OOP, and PB won't have a OOP built-in,
it's a design choice and I have made it clear a lot of time on this forum.
If you don't like it, do as Shield did, find a tool which fits your needs better.

Read it slowly, word by word and line by line, to understand it.

[Lunasole]

@Danilo, times are always changing and opinions sometime too, It is strange if you still didn't noticed such a trivial regularity. So please don't show me quotes like "Santa is real", I already knew it time ago

[Danilo]

@Danilo, times are always changing and opinions sometime too, It is strange if you still didn't noticed such a trivial regularity.

Of course, hope dies last. Have fun waiting…

[Lunasole]

Of course, hope dies last. Have fun waiting…

I don't treat any my suggestion or argument in this forum as "waiting", but if you naive enough to think so, have fun with it ^^

[freak]

@Keya,
This topic has come up quite a few times.
Take a look at this old thread which documents some of the reasons why it probably won't be done:
http://www.purebasic.fr/english/viewtop ... 95#p296495

Interesting thread ...

PureBasic uses single characters for all its basic types. "ub" doesn't fit that. Also the decision has been made. Its not going to change now.

So one of the key reasons for no support for unsigned is because ".d" is already taken and ".ul" would require 2 characters which goes against PB variables denoted by 1 character so it'd just be inconvenient ...... MessageRequester-instead-of-Msgbox("Hrm","Ooookay!?")
I can personally handle typing two letters instead of one, no problems at all! I mean when we use pointers we have to anyway, eg. *p.Ascii ... not *p.a

That remark was in response to the request that the "unsigned byte" type should be named ".ub" instead of ".a". I was not talking about long or quad at all. Please don't quote me out of context.

We don't see much value in adding unsigned long or quad especially since all PB commands expect signed long or quad numbers as input.

You don't, but the designers of seemingly every other compiler have identified the value of unsigned datatypes.

You mean designers of such other languages like Java? Why don't you take your crusade there?

And PB already supports unsigned 8bit and 16bit, so its support of those goes against everything you just said.

An unsigned byte or word can be cast to a signed long and passed to all these functions without problems, but passing an unsigned long to a function that expects a signed one is trouble.

Agreed. So make the compiler support unsigned ones so there is no "trouble".

Also as Fred explains in the link by luis, mixing signed and unsigned is very tricky in the implementation/performance department.

It's never been a problem for any other compilers or programmers though.

Sorry freak but with all due respect all of your "reasons" sound purely just like "it's too hard for us to do". but it's without doubt that Fred is talented enough to implement it, PB speaks for itself there!

I'm not even going dignify that with a response.

[davido]

@freak,
Sorry.
Thank you for setting the matter right.

[skywalk]

Unsigned long is called out in almost every C lib header and it is especially difficult to track when it is within a struct. Here you cannot use a quad just to get the number to match. That uses the wrong amount of space. And if the value goes past 2147483647, then we need worker functions to convert to unsigned.
There are 26 letters to choose from so I would suggest 'ul' = 'm'. 1 higher than 'l'.
And long double, 'ld' = 'e'. 1 higher than 'd'.
That would round out the gaps below.

Code: Select all

Structure ScanAllTypes ; #PB_Compiler_Unicode = 1 (PB v5.4+ drops Ascii compiles)
  ; Allows 1 Define for all datatypes to be scanned. Define *buf.ScanAllTypes = @somevariable or *somememory
  ; Consider as a StructureUnion. Takes no memory and overflow is not checked.
  ; Ex. *buf\d[i] ; 'i' can be incremented in a loop without compiler error.
  ;          ; Type,   Bytes,  Min,                     Max,                     C Type
  b.b[0]     ; Byte,       1, -128,                     127,                     char, bool(C++)
  a.a[0]     ; Ascii,      1,  0,                       255,                     unsigned char, UCHAR, BYTE
  c.c[0]     ; Character,  2,  0,                       65535,                   unsigned short, USHORT
  u.u[0]     ; Unicode,    2,  0,                       65535,                   unsigned short, USHORT
  w.w[0]     ; Word,       2, -32768,                   32767,                   short
  l.l[0]     ; Long,       4, -2147483648,              2147483647,              long, int
  ;;ul.ul[0] ; ULong,      4,  0,                       4294967295,              unsigned long, unsigned int, DWORD(C++)
  i.i[0]     ; Integer,    4, -2147483648,              2147483647,              long, int(x86 or 32-bit),sizeof*
  ;i.i[0]    ; Integer,    8, -9223372036854775808,     9223372036854775807,     long long(x64 or 64-bit),sizeof*
  q.q[0]     ; Quad,       8, -9223372036854775808,     9223372036854775807,     long long, unsigned long long int
  f.f[0]     ; Float,      4,           -1.175494e-38,            3.402823e+38,  float      (6 decimal places)
  d.d[0]     ; Double,     8, -2.2250738585072013e-308, 1.7976931348623157e+308, double     (15 decimal places)
  ;;ld.ld[0] ; LDouble,   10, -3.4e-4932,               1.1e+4932,               long double(19 decimal places)
  ;;s        ; String$,    2/char + 2 for chr(0),       ,                        wchar_t
  s.s{1}[0]  ; {FixedLen}, 2/char,                      ,                        char *, char var[] <-- Convert to Ascii
  ;s.s[0]    ; FAILS, -> *p\s = @x$, *p\s[1] = IMA.
EndStructure

[Keya]

I'm not even going dignify that with a response.

What did I say that was offensive??? It's a Feature Request or "constructive criticism" at worst! You still haven't given a single reason why it would be beneficial not to be implemented, which surely would be simple if such a reason existed.

Intel & AMD CPUs afterall natively support both signed and unsigned 32bit and 64bit for very good reason, yes!? (not my opinion - they just do) And Purebasic does natively support unsigned 8bit and 16bit - if there were good reasons not to support unsigned then PB wouldn't support either of those.

So please take it as a Feature Request as it is intended, or constructive criticism at "worst". Purebasic doesn't support something that many people (and the CPU itself) consider fundamental, so surely as a customer wanting the most out of my beloved Purebasic I can make requests for such things without getting crucified?

I guess however we will have to make a preprocessor to do the compilers job for us in this case? How about an "Official Guide to handling unsigned 32bit/64bit integers in Purebasic" at least so we can add the support?

I apologize for offending you nonetheless, and as always will take note of what i've learned here to try to become a better programmer no matter what the hurdles.

I will say no more, thankyou kindly for your time listening to me and considering the feature, which is literally the only important/fundamental thing on my PB Wishlist.