Code: Select all
signedLong.l = uLongToLong(ulong.l)
Code: Select all
quad.q = uLongToQuad(ulong.l) ;No problem if it's put in a quad!!
Code: Select all
signedLong.l = uLongToLong(ulong.l)
Code: Select all
quad.q = uLongToQuad(ulong.l) ;No problem if it's put in a quad!!
Code: Select all
a.w = %1001010110101101
b.l = %1001010110101101
Debug a
Debug b
c.w = -27219
d.w = 38317
Debug Bin(c,#PB_Word)
Debug Bin(d,#PB_Word)
Code: Select all
a.l = %10010101101011011001010110101101
Debug a
Debug Bin( a, #PB_Long )
b.q = a & $FFFFFFFF
Debug b
Debug Right( Bin( b, #PB_Quad ), 32 )
Code: Select all
Macro LongToULong( _LVal_ )
( ( _LVal_ ) & $FFFFFFFF )
EndMacro
The purebasic team allready decided to not include unsignt long and quad into purebasic because of performance problems in expressions. If i understood it right. So a second set of operators would be a alternativ. That would enable the programer to decide how variable are treated. The compiler would not need to decide it. Which is what the pb developer want to avoit.Kaeru Gaman wrote:two new datatypes ( uLong + uQuad ) would be easier than a new set of operators, I presume...
No. That are operators for bit shifting not for comparing.Mistrel wrote:Wouldn't "<<" and ">>" be considered viable alternative operators, which already exist?
@Kaeru Gaman: just a small note, you can display values as unsigned using StrU(value,type). This allows you to display even a quad as unsigned and allows you to do so without putting the value into a larger container.Kaeru Gaman wrote:only when you want to display it, you'll need to display the MSB as positive value not as negative,
so you should use a bigger container, quad in this case, to make it a value-bit and no longer the sign-bit.
when transferring the value, use the bit operator & to make sure this will happen.