Re: My idea of fully-portable C code
- From: Tomás Ó hÉilidhe <toe@xxxxxxxxxxx>
- Date: Tue, 13 May 2008 15:18:19 -0700 (PDT)
On May 13, 7:59 pm, Hans-Bernhard Bröker <HBBroe...@xxxxxxxxxxx>
wrote:
* Use three bits per LED. 00 = Off. 01 = Red. 10 = Unused. 11 =
Green.
The reasoning behind that choice of encoding is flawed. Putting an
unused state in the middle of a list of values will "use the least
amount of memory possible" only by luck, but never by design.
I don't know what you're getting at here, but the reason I chose to
use 00 and 11 for valid values was so that I could do SetAllBitsZero
and SetAllBitsOne.
void SetChunk(uint_fast16_t const i, uint_fast8_t const state);
Here's your first unwarranted assumption (although it's not one of
portability). You've validated your self-stated requirement:
What assumption? Please be specific.
(Of course you can set the chunk size bigger or smaller than 3 bits)
Using uint8_fast_t for the datatype disallows setting the chunk size to
more than 8 bits.
No, it doesn't. The chunk size is determined by BITS_PER_CHUNK. The
type, uint8_fast_t, can indeed store values outside the "chunk value
range" but that doesn't mean you should try to store 467 in a 2-Bit
number. If you compile the program in debug mode, there will be an
assertion failure to let you know that 467 is outside the range.
This is now different from trying to store 300 in an unsigned char.
In addition to that, 'i' should really be size_t or something at least
as large as that. As-is, you introduce yet another hardcoded limitation..
I went with uint_fast16_t because I thought 65536 bits was enough. Of
course if you want 4 million bits you can always move forward to 32-
Bit.
#define TOTAL_BITS_NEEDED (QUANTITY_CHUNKS * BITS_PER_CHUNK)
Bad macro. Parentheses missing around QUANTITY_CHUNKS and
BITS_PER_CHUNK leave the code vulnerable to funny definitions of those
constants (e.g. #define BITS_PER_CHUNK 2+3) The same problem occurs
repeatedly later on.
You're confusing things. A macro is a self-contained, self-sufficient
entity. If I have a macro called QUANTITY_CHUNKS, then it should be
able to be used on its own without parentheses. If it needs
parentheses, then it is ill-formed. That is to say, the following is
dodgy:
#define BITS_PER_CHUNK 2+3
And it should have been written as:
#define BITS_PER_CHUNK (2+3)
If this wasn't how things worked then you'd see parenthese EVERYWHERE
littered throughout code wherever a macro is used.
And it has a portability problem, too! Check out what this does for
QUANTITY_CHUNKS=60000u, BITS_PER_CHUNK=6u, on a 16-bit host platform.
You lose. Thanks for playing.
It overflows, you're right. Integer types don't have infinite range in
C. I consciously chose uint_fast16_t because I consciously chose a
limit of 65536 bits.
#define BITS_ALL_ONES(x) ((1u << (x)) - 1u)
Will fail as soon as pow(2,x) > (UINT_MAX + 1)... (e.g. x=17 on a
16-bit platform).
You won't have a 17-Bit chunk. I could use plenty of #error directives
thoughout the code to make sure it's not misused.
#define CHUNK_ALL_ONES (BITS_ALL_ONES(BITS_PER_CHUNK))
... so this fails if I set BITS_PER_CHUNK to more than the number of
bits in an unsigned int (after lifting the earlier restriction about
uint8_fast_t).
The main usage would be for BITS_PER_CHUNK <= CHAR_BIT.
I've written this post to show an example of fully-portable code, that
is, code that will behave exactly as intended on every conceivable
implementation of the C89 standard.
Well, it doesn't fulfill that promise. And that not just on some
conceivable implementation of the C89 standard, but actually on entire
*class* of systems that are in wide-spread usage.
OK so I'll add a few #error directives to protect it from espionage.
.
- Follow-Ups:
- Re: My idea of fully-portable C code
- From: Chris H
- Re: My idea of fully-portable C code
- From: Hans-Bernhard Bröker
- Re: My idea of fully-portable C code
- From: Tomás Ó hÉilidhe
- Re: My idea of fully-portable C code
- References:
- My idea of fully-portable C code
- From: Tomás Ó hÉilidhe
- Re: My idea of fully-portable C code
- From: Hans-Bernhard Bröker
- My idea of fully-portable C code
- Prev by Date: Re: Best way to get 2.5 volts from somewhere? (Vcc = 5 volts)
- Next by Date: Re: Best way to get 2.5 volts from somewhere? (Vcc = 5 volts)
- Previous by thread: Re: My idea of fully-portable C code
- Next by thread: Re: My idea of fully-portable C code
- Index(es):
Relevant Pages
|