[C++11: 1.7]
talks about bytes in terms of bits:
The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to contain any member of the basic execution character set (2.3) and the eight-bit code units of the Unicode UTF-8 encoding form and is composed of a contiguous sequence of bits, the number of which is implementation-defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. The memory available to a C++ program consists of one or more sequences of contiguous bytes. Every byte has a unique address.
However, I cannot find anywhere in the standard that defines "bit".
So is it true to say that C++ does not place limitations on the number of values that may be represented by a single bit?
Does it allow, say, tri-state bits?
Among the normative references listed in [C++11: 1.2]
is "ISO/IEC 9899:1999, Programming languages — C".
In turn, this standard says:
[C99: 3.5]:
1 bit unit of data storage in the execution environment large enough to hold an object that may have one of two values
This doesn't preclude a bit being a unit of data storage that's even larger, so C++ as a language indeed could support tri-state bits.
3.9.1.7 says
Types bool, char, wchar_t, and the signed and unsigned integer types are collectively called integral types.48) A synonym for integral type is integer type. The representations of integral types shall define values by use of a pure binary numeration system.49) [ Example: this International Standard permits 2’s complement, 1’s complement and signed magnitude representations for integral types. — end example ]"
The note 49
reads
A positional representation for integers that uses the binary digits 0 and 1, in which the values represented by successive bits are additive, begin with 1, and are multiplied by successive integral power of 2, except perhaps for the bit with the highest position. (Adapted from the American National Dictionary for Information Processing Systems.)
I'm going to disagree with the accepted answer, since that is emulatable by a ternary machine, which is expressly allowed by the spec.
§ 3.9.1/4 Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2n where n is the number of bits in the value representation of that particular size of integer.
§ 1.8/5 An object of trivially copyable or standard-layout type (3.9) shall occupy contiguous bytes of storage.
§ 3.9/9 Arithmetic types (3.9.1)... are collectively called scalar types. Scalar types, ... arrays of such types... are collectively called POD types. Scalar types ..., arrays of such types... are collectively called trivially copyable types.
§ 3.8/2 For any object... of trivially copyable typeT
, whether or not the object holds a valid value of typeT
, the underlying bytes making up the object can be copied into an array ofchar
orunsigned char
. If the content of the array ofchar
orunsigned char
is copied back into the object, the object shall subsequently hold its original value.
The problem here is that at all points, the state of all trivially copiable multibyte objects must be copiable to an array of char
and back without loss. This means that a ternary machine emulating a base 2 machine (as is required by the basic arithmetic types having modulo "rollovers"), must emulate those rollovers from each emulated byte to the next in each and every unsigned multibyte arithmetic operation.
Even this is emulatable on a ternary machine, slowly, but if all primitive types are made of exactly 41 trits than all a compiler has to worry about is unsigned rollover/under, which might be viable. (Obviously, emulating ^
, |
and &
is also slow, but that's less of an issue in my mind)I think it could be done, but is amazingly impracticable to make a standard conforming C++ compiler for a ternary machine.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With