.a and .u
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.
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.
quidquid Latine dictum sit altum videtur
Yes, that's the reason why I would have liked them (external C libs often uses unsigend longs).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).
But if the decision is made, ok... I'll live with it.
Thank you for the explanation.
Heh I had to laugh, found myself disputing the need for unsigned types Guess I've learned a few things since thenluis wrote:I remember this answer:Thorium wrote: Is there a technical reason for your decision to not implement unsigned types.
http://www.purebasic.fr/english/viewtopic.php?t=6896
PS: I would like unsigned me too...
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
- Joakim Christiansen
- Addict
- Posts: 2452
- Joined: Wed Dec 22, 2004 4:12 pm
- Location: Norway
- Contact:
Agreed, mostly because it is more "readable".What I think would be a better solution:
.b = byte
.ub = unsigned byte
.w = word
.uw = unsigned word
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
I agree with this btw. Maybe a compiler warning could be used? But let advanced users use it if they want.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 like logic, hence I dislike humans but love computers.
Re: .a and .u
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 ublueznl 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
sorry for my bad english
-
- Addict
- Posts: 2228
- Joined: Mon Jun 02, 2003 9:16 am
- Location: Germany
- Contact:
Re:
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.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.
bye,
Daniel
Daniel
Re:
Unsigned longs are also on my wishlist exactly for this reason.luis wrote:Yes, that's the reason why I would have liked them (external C libs often uses unsigend longs).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).
If any of you native English speakers have any suggestions for the above text, please let me know (via PM). Thanks!
Re: .a and .u
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.
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.
Re: .a and .u
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 !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.
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
Re: .a and .u
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
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
Re: .a and .u
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.
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
Re: .a and .u
Nobody forces you to use that structure. You can create your own and name it whatever you want.
quidquid Latine dictum sit altum videtur
Re: .a and .u
It would still have a .a datatype in it.freak wrote:Nobody forces you to use that structure. You can create your own and name it whatever you want.