Comments on: Efficient C Tips #1 – Choosing the correct integer size

By: Anonymous

Anonymous — Thu, 10 Jun 2010 10:42:16 +0000

The engineer who modified the hard coded constant should have been checking for side affects… however.

The original cautions engineer probably would have written in the first place:

// In some header file…
#define MY_VALUE 3000 // It was 100. But i need more!

…

int main()
{
uint_fast8_t i;

// Pre condition
#if MY_VALUE > UINT_FAST8_MAX
#error “Houston, we have a problem.”
#endif

for (i = 0; i < MY_VALUE; ++i) {
…
}
return 0;
}

By: Kevin Granade

Kevin Granade — Wed, 02 Jun 2010 16:34:36 +0000

One problem with this is that if you are targeting multiple platforms, it may compile on some and not on others at that point. You’ve asked for “at least 8 bits”, will it generate a warning or error on a given architecture even if uint_fast8_t is actually 16 bits? I’m pretty sure it wouldn’t, as the definition of uint_fast8_t on my system is “typedef unsigned char uint_fast8_t;”. If it happened to be a 16 bit variable instead, it would do bounds checking against a 16 bit variable, so could miss the constraint violation.

Regardless, with gcc the following code did not generate an error or warning, and performed as expected, infinite loop:

#include

int main()
{
uint_fast8_t i;

for(i = 0; i < 3000; ++i)
{
;
}
return 0;
}

By: Charles

Charles — Sun, 11 Apr 2010 01:52:53 +0000

With 256 bytes, I’d go back to assembly
Like Nigel, I started with assembly and very little memory available and it was great fun; now our processors have evolved and our code base supports 3 (cached!) architectures, I find it ugly!
What I found more difficult when writing assembly was very often we were hitting non documented bugs of the processor and had to resort to NOP insertion after lengthy discussion with architecture team (“it’s the software!”, “it’s the hardware!”)

By: Charles

Charles — Sun, 11 Apr 2010 01:45:26 +0000

I would think the compiler should be able to generate a warning:
we would be testing a variable of 8bit width against an out of bound constant
shouldn’t it?

By: Nigel Jones

Nigel Jones — Wed, 24 Feb 2010 19:29:26 +0000

I couldn't agree more. Not withstanding the issues you've raised, IMHO not using the optimizer leaves you vulnerable to not finding mistakes such as failing to declare appropriate variables as volatile, failure to notice that certain code is useless etc.

By: Greg Nelson

Greg Nelson — Wed, 24 Feb 2010 19:14:07 +0000

Steve Karg said (basically): "Extreme Programming teaches you 'don't optimize.'"In my opinion, this simply proves that Extreme Programming is for C# programmers on 64-bit 3GHz windows boxes with infinite swap space.In one of my most recent programs, I had to build my own version of "printf("%02d")" because the call to printf made my application no longer fit into the 256 bytes of available RAM. "Don't optimize" under these circumstances equates to "don't get the job done." Not an option.

By: Steve Karg

Steve Karg — Wed, 03 Feb 2010 17:40:54 +0000

ashleigh: for my portable code using C99 standard integers, I try not to litter my code with #if's, but instead just have a ports/xx directory that includes a stdint.h for the compiler that is lacking C99 support for standard integers.Nigel: as for using fast/least standard integers in a project, I have I have two rules about optimizing that I learned while studying Extreme Programming:Rule 1: Don't do it.Rule 2: (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution.

By: Anonymous

Anonymous — Thu, 28 Jan 2010 16:21:10 +0000

"Indeed they do. The sooner that everyone starts using the C99 syntax the better IMHO.1/25/2010 2:33 PM"Nigel, I understand your enthusiasm, but C99 was adopted in 2000, your comment is about 10 years later – perhaps it's time to think of why everyone hasn't started using it and get back to coding.JW

By: Nigel Jones

Nigel Jones — Thu, 28 Jan 2010 11:52:46 +0000

Mike – I like your observation. It is indeed a weakness of these C99 data types that I had not previously considered.

By: Anonymous

Anonymous — Tue, 26 Jan 2010 09:03:33 +0000

One thing overlooked in this enthusiasm for C99 is code validation: Let's say the compiler uses a two byte native operand for the "fast" type in the example. And lets say someone comes back and creates a bug by extended the loop limit to 300. Maybe the compiler notices this and generates a warning based on the compare, but probably it doesn't. And the code tests great. So now we think the code is solid. But, of course, it breaks as soon as we port it to "fast is 8 bits"–possibly in a non-obvious way.Mike Layton