PureBasic Forums - English

Posted: **Tue Aug 18, 2009 11:03 pm**

blueznl:
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.

Thorium:
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. 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. So what good is an unsigned type when you can pass it to almost no function to work with the value ?

Also as Fred explains in the link by luis, mixing signed and unsigned is very tricky in the implementation/performance department. For example to compare an unsigned byte to a signed long, you just cast the unsigned byte to a long and then compare (the same that needs to be done to compare signed byte and signed long). To compare an unsigned long with a signed one is a different story. The cases where the signed one is negative or the unsigned one is over the range of a signed long have to be handled separately because a direct comparison between both is not possible. Casting both up to quad just for a comparison is also not very fast on the x86 processor family as its over the native register size.

In the end, the number of situations where there is a real need for unsigned longs is quite low in my opinion (except to interface with external libraries maybe). So in our opinion it is just not worth the hassle.

Posted: **Tue Aug 18, 2009 11:17 pm**

freak wrote: In the end, the number of situations where there is a real need for unsigned longs is quite low in my opinion (except to interface with external libraries maybe).

Yes, that's the reason why I would have liked them (external C libs often uses unsigend longs).

But if the decision is made, ok... I'll live with it.

Thank you for the explanation.

Posted: **Tue Aug 18, 2009 11:33 pm**

luis wrote: I remember this answer:

http://www.purebasic.fr/english/viewtopic.php?t=6896

Very interesting, thank you.

Posted: **Tue Aug 18, 2009 11:54 pm**

luis wrote:
Thorium wrote: Is there a technical reason for your decision to not implement unsigned types.
I remember this answer:

http://www.purebasic.fr/english/viewtopic.php?t=6896

PS: I would like unsigned me too...

Heh

I had to laugh, found myself disputing the need for unsigned types

Guess I've learned a few things since then

Posted: **Fri Aug 21, 2009 2:21 pm**

I think .a and .u is great. Even Java doesn't support unsigned bytes.

Posted: **Fri Aug 21, 2009 3:00 pm**

What I think would be a better solution:

.b = byte
.ub = unsigned byte
.w = word
.uw = unsigned word

Agreed, mostly because it is more "readable".

As for unsigned longs, that would be cool and there has actually been times where I needed it.

From: http://www.purebasic.fr/english/viewtop ... 0284#30284

In my humble opinion, is the programmer business who compare with who. All we need is the freedom to use signed, unsigned, float, etc. for our variables.

I agree with this btw. Maybe a compiler warning could be used? But let advanced users use it if they want.

Posted: **Sat Jun 12, 2010 6:25 am**

blueznl wrote: What I think would be a better solution:

.b = byte
.ub = unsigned byte
.w = word
.uw = unsigned word
.l = long
.ul = unsigned long
.q = quad
.uq = unsigned quad

thats one of the top in my personal wishlist. ok, maybe i can live without uq, but with this, it's complete. and please, change this messed a and u

Posted: **Sat Jun 12, 2010 6:40 am**

THCM wrote:As far as I remember ASCII uses only 7 bits and I also would prefer something like .ub or at least another explanation should be used as ASCII.

Yes, but anywhere on nowadays operating system you won't find the original 7-bit-ASCII anymore. It is CP1252 or Latin-1 (ISO-8859-1) which are quite similar. Well, but unsigned types aren't even needed. Just look at java.

Posted: **Sat Jun 12, 2010 10:16 am**

luis wrote:
freak wrote: In the end, the number of situations where there is a real need for unsigned longs is quite low in my opinion (except to interface with external libraries maybe).
Yes, that's the reason why I would have liked them (external C libs often uses unsigend longs).

Unsigned longs are also on my wishlist exactly for this reason.

Posted: **Sat Jun 12, 2010 11:16 am**

Unsignt longs are heavily used in various file formats. And thats the reason i wish for them. It's a pain to allways need to convert them to quad. If your forget it just one time the code works but you get strange results because of the negative values. Big bug producer for me.

Getting .a and .u was great and improved PB a lot for me. But the naming is extremly bad. I use them very often, but never for ASCII or Unicode.

Posted: **Sat Jun 12, 2010 7:48 pm**

Thorium wrote: Getting .a and .u was great and improved PB a lot for me. But the naming is extremly bad. I use them very often, but never for ASCII or Unicode.

I agree the naming it's extremely disconcerting for people coming from other languages... and using unsigned longs it's quite tedious... sigh. But.. well...we heard the reasons from the devs on this point, so better don't hold our breath !

Posted: **Sun Jun 13, 2010 3:24 pm**

The real problem is the comparison of unsigned and signed variables,
right? Do we really need them? I think, no. All what we wand is the
possibility to use unsigned values for some external functions, for
large values, where signed variables are negative. We want to calculate
with high values and pass them back to such a external function. We
does not want to compare signed with unsigned variables.

As a result, we wish to use unsigned variables with the math-library,
math-operators and a few people could use the bit-operators. If there
is a need to compare unsigned with signed variables, the solution could
be for the compiler, to interpret all unsigned variables as signed, if they
are be mixed. Other PB-Function could interpret signed variables as
unsigned or generate a compiler-error.

If someone needs to compare a unsigned with a signed variable, he could
write his own workaround like it is done today. Because then, signed and
unsigned variables would be mixed up, the compiler could interpret the
unsigned variable as signed and so it needs the "& $FF" workaround.
This solution would have no performance issues. It is also a little tricky,
but that's the same behavior today. all users who need this features
aren't beginners. And for all beginners, which doesn't get it, can ask
like they do it the whole day.

I hope you think over your decision again

MFG PMV

Posted: **Sun Jun 13, 2010 6:12 pm**

Here a example for the bad naming of .a and .u:

This procedure detects if a procedure is inline hooked.
Very easy code, no API or anything, easy to read and understand... But wait whats the .Ascii? Is there some text on the function entry?
Well of course not but i need a unsignt compare of the first byte and i hate the & $FF workaround because it's a bug producer again. You forget it one time and your code don't works as it should but you get no error message.

Code: Select all

Procedure.i IsHooked(Module.s, Function.s)
  
  Protected Lib.i
  Protected *FuncAddr.Ascii
  
  Lib = OpenLibrary(#PB_Any, Module)
  *FuncAddr = GetFunction(Lib, Function)
  CloseLibrary(Lib)
  
  If *FuncAddr <> 0
    
    If *FuncAddr\a = $E9
      ProcedureReturn #True
    Else
      ProcedureReturn #False
    EndIf
    
  EndIf
  
EndProcedure

Posted: **Sun Jun 13, 2010 7:06 pm**

Nobody forces you to use that structure. You can create your own and name it whatever you want.

Posted: **Sun Jun 13, 2010 7:16 pm**

freak wrote:Nobody forces you to use that structure. You can create your own and name it whatever you want.

It would still have a .a datatype in it.

PureBasic Forums - English

.a and .u

Re: .a and .u

Re:

Re:

Re: .a and .u

Re: .a and .u

Re: .a and .u

Re: .a and .u

Re: .a and .u

Re: .a and .u