PureBasic Forums - English

Sorry if that was discussed already before (did not found a thread) - but I'm just wondering regarding the difference of long and int compared to 32bit and 64bit cause it seems it's vice versa to C++.

C++: sizeof(int) <= sizeof(long)
PB: sizeof(long) <= sizeof(int)

So for example:

PB 32bit:
int = 4bytes
long = 4bytes

PB 64bit:
int = 8bytes
long = 4bytes

C++ 32bit:
int = 4bytes
long = 4bytes

C++ 64bit:
int = 4bytes
long = 8bytes

Where it's not fully true regarding C++ but at least it should follow that order:
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)

Isn't that little bit confusing?


Greetings,
auser

long is always 32 bit in PB, while integer is dependent from the CPU. In C++, "long" size isn't specified which is way more confusing:
- long in VC++ in 64 bit is still 32 bits
- long in GCC in 64 bits is 64 bits

Hello Fred,

But even what you wrote regarding the unspecified size follows the order "sizeof(int) <= sizeof(long)". And what you wrote regarding "long" in PB should be true compared to typical use of "int" in C++ as well. It's not the fact that type sizes may change that confused me but that int may be bigger then long in PB while it's vice versa in C++ (where as far I know it would typically stay on 32bit while long could increase on 64bit depending on the compiler). So I like the idea in general that one typesize stay on 32bit... but it's different compared to C++ that it's long and not int which shows that behaviour (while it's good in PB that it's always true and not that written in stone at other compilers).


Greetings,
auser

Well yes, it's somewhat reversed, but historically a long was 32 bit, opposed to a short which was 16 bit. Integer has been introduced very late in PB, when it started to support 64 bit.

besides - we're all used to it now

I'm old. A long is 4 bytes. A word is 2 bytes. A byte is one byte. A bit is 1/8th byte. A nibble is half a byte.

An int is an integer, regardless of length. It's C(++) that got it all wrong!

If a byte is half a word, why isn't it called wo?

Genesis 1
v1. In the beginning, there was nulls and voids. And the Programmer saw this and created the Bit. And the Programmer saw that the Bit was Good.
v2. Then Bits started to get strewn across the chaos, and they cried out to the Programmer.
v3. Carefully gathering his Bits, he grouped them together and bound them with delicateness and formed the Byte. And the Programmer saw that the Byte was Good.
v4. Nulls and voids saw this and called upon the Registers to try and split up the Bytes.
v5. The Registers spoke to the Bytes in shifting tones and Bits were lost to the left and right to the nulls and voids.
v6. The Bytes called out to the Programmer again, who grouped his precious Bytes, and formed different sized groups, some he called Words and others he called Longs.
v7. The Words and Longs overran the Registers who turned on the nulls and voids causing them pain and anguish.
v8. The Programmer saw that the Words and Longs were Good.

MS describes a long as as "A 32-bit signed integer. The range is –2147483648 through 2147483647 decimal."
MS describes an int as "A 32-bit signed integer. The range is -2147483648 through 2147483647 decimal."

I don't do anything for 64 bit specifically, so I have this tendancy to use PB's .i a lot (somevar.i) when I convert something from C++ to PureBasic'ese, and when it calls for an int in the C++ code I automatically associate the C++ int type with .i in PureBasic. This does cause a little confusion for me at times in 32 bit because it assumes that int and long are both equal (and on 32 bit they are in the sense they are both 4 bytes with the same range on 32 bit). Its still a minor problem because if someone picks up my code and tries to use it on 64 bit it doesn't always work because of the use of the int which is 8 bytes on 64 bit but 4 bytes on 32 bit and the structure items should have stayed at 4 bytes, just recently ran into this problem again in something I posted in the tips and tricks section where the structures called for int in the C++ code and thats what I used (PB .i), it didn't work properly on 64 bit until the int's were changed out to longs.

So, how do you determine when an int called for in C++ , when converting to PB, is really supposed to be an int or a long in PB ?

SFSxOI wrote: MS describes a long as as "A 32-bit signed integer. The range is –2147483648 through 2147483647 decimal."
MS describes an int as "A 32-bit signed integer. The range is -2147483648 through 2147483647 decimal."

Even with the above comparision "sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)" is true. Fred already showed an example with VC++ and GCC where the size of long differs when using 64bit.

I don't do anything for 64 bit specifically, so I have this tendancy to use PB's .i a lot (somevar.i) when I convert something from C++ to PureBasic'ese, and when it calls for an int in the C++ code I automatically associate the C++ int type with .i in PureBasic. This does cause a little confusion for me at times in 32 bit because it assumes that int and long are both equal (and on 32 bit they are in the sense they are both 4 bytes with the same range on 32 bit).

I think it should be ok in many cases. But I'm not sure what would happen if a DLL-function needs some parameter by reference to some 4byte content but you would feed it with a "@64bit_integer.i" when your PB compiles for 64bit.

blueznl wrote:I'm old. A long is 4 bytes. A word is 2 bytes. A byte is one byte. A bit is 1/8th byte. A nibble is half a byte.

There is no universal standard for that.
For example on ARM a word is 4 bytes and a double word is 8 bytes. And there is actualy a half word, which is 2 bytes. ^^

Thorium wrote:

blueznl wrote:I'm old. A long is 4 bytes. A word is 2 bytes. A byte is one byte. A bit is 1/8th byte. A nibble is half a byte.

There is no universal standard for that.
For example on ARM a word is 4 bytes and a double word is 8 bytes. And there is actualy a half word, which is 2 bytes. ^^

Talk 6502 and we have a deal...