Subject: Re: [std-proposals] Restrict possible values of CHAR_BIT
From: Tom Honermann (tom_at_[hidden])
Date: 2019-10-28 08:46:30
On 10/24/19 4:52 PM, Arthur O'Dwyer via Std-Proposals wrote:
> On Thu, Oct 24, 2019 at 4:10 PM Tjernstrom, Staffan via Std-Proposals
> <mailto:std-proposals_at_[hidden]>> wrote:
> Looking at interactions with (and by extension, programming on)
> FPGAs, where everything is bit-based, it's common to find things
> like 14-bit values. We have 14-bit types in our internal type system.
> Yes, but "a 14-bit type exists" is not the same thing as
> "CHAR_BIT==14".Â I would be as surprised as Lyberta (and perhaps more
> so) if any C++ compiler in the world supported "CHAR_BIT==14".
> However, I agree with Tom that this proposal is not motivated.
> Personally I think it'd be just as silly to have CHAR_BIT==16 or
> CHAR_BIT==32 as to have CHAR_BIT==9 or CHAR_BIT==24. If we're trying
> to get C++ to fall in line with what "everybody knows," then the way
> to do that is to mandate CHAR_BIT==8, not to keep the current
> situation of "CHAR_BIT==I don't know, ask your vendor" but also put
> odd restrictions on the vendor's choice.
> Lyberta, did your survey turn up any C++ implementations where
> CHAR_BIT != 8?Â If so, what version of C++ were they -- C++03, 11, 14, 17?
Coverity supports a number of compilers where byte size is not 8.Â I'm
not very familiar with these compilers and I don't know which ones (if
any) are being maintained.Â Ones I know of are for targeting the
following DSPs.Â The Analog Devices ones have a 32-bit char, the rest
- Analog Devices:
Â Â - 21XX
Â Â - TigerSHARC
Â Â - TeakLite 4
- Texas Instruments:
Â Â - C2000
Â Â - C54XX
Â Â - C5500
Additionally, there are apparently people working on LLVM targeting an
architecture with a 257 bit byte (that is not a typo).
Please don't underestimate the potential for C++ to be used for unusual
architectures.Â It is hard to predict what might become mainstream one day.
As an example provided to me by another committee member recently,
consider some possibilities of a 48-bit processor. 32-bits is often less
than is needed for memory use or floating point precision.Â But 64-bits
is often more than is needed.Â A 48-bit processor could hit a sweet
spot.Â That could in turn lead to a desire for a UTF-12 encoding and a
12-bit char size that would more efficiently encode text (in some cases)
than UTF-8 does today.Â I'm not stating this would be a good idea, but
it is an example that can be defended in principle.
> my $.02,
STD-PROPOSALS list run by firstname.lastname@example.org
Standard Proposals Archives on Google Groups