Thoughts on C++ integer types

Quote:

---

Originally Posted by Bssldr

The current C++ standard says that the size of a char is guaranteed to be 1 byte.

---

Too bad the standard doesn't define what the size of a byte is though! :lol:

I've worked on a machine where a byte was 16 bits. I know for a fact that there are machines out there that define byte as being 64 bits longs.

Quote:

---

Originally Posted by laserlight

Consider: how likely is it for CHAR_BIT != 8? If you can write the code to depend on CHAR_BIT, well and good, but if you must assume CHAR_BIT == 8, then write a static_assert to document this assumption.

---

yeah, that's the point Bssldr seems missing; the standard doesn't force you writing 100% portable code; you have the right of choosing how much portable your code should be: you can write code working for a specific hardware or even OS or compiler, or you can write code supposedly working with the full range of hardware supporting a C++ compiler, including esotic ones. Both extremes have their advantages and costs; as always, it's up to you making a profit balance and taking the right choice. This is freedom and it's a d a m n good thing :) ( EDIT: apparently, we cannot write d-a-m-n without spaces ... oh my ... )

as other said, this choice does not necessarily mean making your code less robust, as there are many ways of ensuring correctness both at run time ( through testing, that should be performed in any case ) and compile time, through static asserts, generic programming techniques ( generic code can detect type properties choosing the correct algorithm for a specific (range of) implementation, for example ) or even the old style preprocessor based conditional compilation techniques.

Quote:

---

Originally Posted by Bssldr

I hope 128 bit doesn't come too soon.

---

Unlikely. 64-bit machines can theoretically address up to 16 exobytes of RAM. That's over a billion gigabytes. Limitations in the OS (either incidental or, in the case of some Windows versions, intentional) have capped it much lower for most platforms, but the point is that we won't need more than 64-bit addressing for many, many years. Probably.

Quote:

---

Originally Posted by Bssldr

The current C++ standard says that the size of a char is guaranteed to be 1 byte.

---

Actually, I think it says that sizeof(char) == 1. As monarch_dodra stated, it just doesn't specify what it is 'one' of.

I too have worked on a 16bit DSP where a 'char' was 16 bit. I've got a feeling that 'short' and 'int' were 16 bit too.

Quote:

---

Originally Posted by JohnW@Wessex

Actually, I think it says that sizeof(char) == 1. As monarch_dodra stated, it just doesn't specify what it is 'one' of.

---

It does, e.g.,

Quote:

---

Originally Posted by C++11 Clause 5.3.3 Paragraph 1a

The sizeof operator yields the number of bytes in the object representation of its operand.

---

The catch is that the number of bits in a byte is required to be at least 8, so it could be 16 bits in a byte, etc.

How do you write networking code when one device has 8-bit bytes and the other one has 10-bit bytes? Doesn't this cause all kinds of problems? Or do the lower layers only extract 8 bits from your 'byte'?

If I'm on a machine with 16-bit bytes and write 10 bytes(which all have been checked to be between 0 and 255) to the hard disk, am I going to consume 20 'standard' bytes? Assuming that the bytes of storage devices are 8-bits long.

Quote:

---

Originally Posted by Bssldr

How do you write networking code when one device has 8-bit bytes and the other one has 10-bit bytes? Doesn't this cause all kinds of problems? Or do the lower layers only extract 8 bits from your 'byte'?

If I'm on a machine with 16-bit bytes and write 10 bytes(which all have been checked to be between 0 and 255) to the hard disk, am I going to consume 20 'standard' bytes? Assuming that the bytes of storage devices are 8-bits long.

---

Those are very some very good questions. And it could be (it is) even worse than that: Some machine use big endian, wereas others use small endian. Fact: That DOES cause all kinds of problems. However, you have to keep in mind the source of the problem: The hardware. No amount of abstraction layers can really change that.

C++'s, is your chance of a solution. How could you ever hope to write code on a 10 bit machine, when you are using a language that defines that byte MUST be 8 bits?

I'm not saying it's easy. I'm just saying it is a necessary evil.

----

PS: A "standard byte" is called an "octet" - defined as "8 bits"
A byte, on the other hand, is more abstractly defined as "a unit of digital information".

Quote:

---

Originally Posted by Bssldr

How do you write networking code when one device has 8-bit bytes and the other one has 10-bit bytes? Doesn't this cause all kinds of problems? Or do the lower layers only extract 8 bits from your 'byte'?

If I'm on a machine with 16-bit bytes and write 10 bytes(which all have been checked to be between 0 and 255) to the hard disk, am I going to consume 20 'standard' bytes? Assuming that the bytes of storage devices are 8-bits long.

---

This is indeed a problem, one that's usually solved by the networking libraries. For instance, when programming with Unix sockets, there are functions to convert numbers to a standard network format, and then functions to convert it back to machine specific format. This way, a 10 bit byte little endian machine can communicate with an 8 bit byte big endian machine, and neither will ever be aware of the difference.

But a lot of this stuff isn't really THAT big of a deal today. If you're running Windows, 99% chance you're running an x86 processor with 8-bit bytes and a 32-bit processor (or a 64-bit processor that's compatible with 32-bit).

99% if your in the states or an english speaking nation. otherwise you will need unicode/multibyte chars.

Quote:

---

Originally Posted by Access_Denied

This is indeed a problem, one that's usually solved by the networking libraries. For instance, when programming with Unix sockets, there are functions to convert numbers to a standard network format, and then functions to convert it back to machine specific format. This way, a 10 bit byte little endian machine can communicate with an 8 bit byte big endian machine, and neither will ever be aware of the difference.

But a lot of this stuff isn't really THAT big of a deal today. If you're running Windows, 99% chance you're running an x86 processor with 8-bit bytes and a 32-bit processor (or a 64-bit processor that's compatible with 32-bit).

---

Seems like you might be turning the corner from this stance.

Quote:

---

Originally Posted by Bssldr

Think of a situation like this: you need to use an 8 byte integer and if it's smaller your code doesn't work as expected. I'd rather see the compiler tell me that the target system doesn't support an 8 byte integer than have a smaller one that makes my program function incorrectly.

To overcome the problem of the target architecture not having a type of required size the compiler could output code that emulates the type by using multiple smaller types.



What do you think how long this kind of thing can continue without introducing new types? One day there'll be 512 bit processors - this means that there'll be additional types of sizes 128, 256, 512 bits. Where are you going to put them? Are you just going to take the current int, long, long long and say their sizes are 128, 256, 512 bits? How are people going to use 32 and 64 bit types then? C++ should have fixed size types and new types should be introduced as the processors evolve.

---