Writing Bug-Free C/D Code

[David B. Held]

Henning Hasemann wrote:
> [...]
> Are you really sure it is a good idea to have a typedef for each purpose?
> So a point struct would look like this for you:
> 
> typedef int COORD;
> struct Point {
>   COORD x, y;
> }
> 
> right?
> [...]

Absolutely.  90% of what programmers call builtin "types" are really 
*representations*.  That is, they are classifications of bit patterns 
that have nothing to do with "types".  In fact, if it's builtin, you can 
be pretty much guaranteed it's not a type.  For instance, "int" is only 
a type when every value that an int can take on has a semantically valid 
meaning for that variable, *and* when those values can be mixed with any 
other instance of "int" in a meaningful way.  In the vast majority of 
cases, that's not true.

Of course, the reason most people don't make proper types is A) they are 
lazy, and B) it implies additional cost.  However, as programs become 
bigger and correctness becomes more difficult to prove, using proper 
types becomes more important.  It's not easy to illustrate in a 100 line 
program, but it becomes perfectly obvious in a 100,000 line codebase.

Dave