PureBasic Forums - English

Coming from VB, I always thought bytes was 0 to 255 (aka 256 bytes). While I was looking through the PB manual, it turns out, in VB, bytes in PB are, -128 to 127 ... what the... ? why is PB different? Im looking to take no more then 1 byte for data and have the number up to 255 .... how can I do this with out wasting a byte using a Word ?

programmatically, this is one way.
If your concern is storage within, say, a file. Still a long (in above eg) when in use.

Shannara:
I was confused with the same thing as well.

I wonder if both types(0 to 255, -128 to 127) can be added to PB?

-Shopro

It's just because that consequently all integer variable types are signed in PB.
Of course it would be fine to add the types unsigned byte/word/long, also (.ub, .uw, .ul) and I think it's on the ToDo-list for the paradisiac PB 4.0

Is it ?

So long the workaround:
(same as mentioned by Dare)

byte.b & $FF
word.w & $FFFF
long.l & $FFFFFFFF

Froggerprogger wrote:Is it ?

Hope so.

I know PB is pretty AR about program sizes, but this should not add much bloat.

If the info is stored in program it requires 1 bit per integer variable to signify signed or unsigned.

If there is a spare bit floating around in the internal variable control tables, great. No real cost in size.

If not, then another byte can be allocated and that allows another 7 bits for other useful variable info. Like type. One byte per variable and a procedure to handle signed/unsigned is not going to bloat out most programs.

This could also be done at compile time, although this is not quite as robust nor is it get-at-able within a program. But if the compilation process knows what it is dealing with it can generate the necessary asm code without adding anything to internal variable controls. Not much extra bloat there.

So here's hoping!

Fred already said "It will be done". I think, PB 4.0 should be true...

Some "technical" discussion took place here: viewtopic.php?t=6896&highlight=unsigned

Thats great.

how can I do this with out wasting a byte using a Word?

Only people using PureBasic think this way! 8O

Since "it will be done"

If I did the following
The above should only take 1 byte of hard disk space, right? Not 2? The reason Im asking is because it really really really pays to have very very small data files on HD, even though we have huge HDs, usually the smaller the file, the quicker it'll load.. (especially if you do expansions and such in memory).

Yes it will use only 1 Byte, but you don't need to write byte & $FF in your code.

WriteByte(155) and WriteByte(155 & $FF) results in the same bitstring.
(Because of $FF is %11111111 the bitstring is totally determinated by the bytenumber)


The $FF (or $FFFF for words) is only used to 'convert' a sigend byte (word) internally as unsigned to a signed long-value:
So you might use it for calculations, etc.
But the following will NOT work, because there's no greater type than long: You cannot convert a signed long into an unsigned long.
But though here again, WriteLong($80000000) and WriteLong($80000000 & $FFFFFFFF) result in the same Bitstring.

in many cases speed is more important than size., you'd have to do some testing, but i assume bytes, words and longs are all pretty much the same speed on modern hardware, in fact under certain conditions longs will be the fastest

instead of bothering about the variable sign and type, i use longs everywhere, only using other variables when there is an absolute need for it

in other words:

a.l = peekb(whatever) &$FF
writeb(a)

as you can see, i don't bother with a sign here, a long is certainly large enough to contain all values from 0 to 255

It's still using the same amount of numbers, but instead of 0 to 256, it's -128 to 128.

It's still using the same amount of numbers, but instead of 0 to 256, it's -128 to 128.

>>ZONK<<
....instead of 0 to 255 it's -128 to 127