kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Mon, Apr 08, 2013 at 12:22:03PM -0500, Dick Hollenbeck wrote:
> We don't need a special type for each usageof an integer.

It's here exactly for type safety. Even pointer are integers, in fact
BCPL (the progenitor of C) used ints as pointer. Still some toolkit
force you to fit pointer into ints (which isn't even legal in C!)
But a layer id is *only* a layer id, you can't do math with it and so
on. In fact in my private branch LAYER_NUM is an enum just like
LAYER_MSK. In the past I fixed bugs (and comments, and variable names)
where reading from the code a mask would be passed when in fact it was
a layer id. C++11 has added features to inhibit the enum to integer
default promotion, just to say how much the technique is useful... would
you use only void* for pointers?

Read here:
http://www.cprogramming.com/c++11/c++11-nullptr-strongly-typed-enum-class.html

enums also can't take "invalid" values unless casted; that avoid checks
everywhere for their correctness. I have a LayerToInt for the (rare)
cases where such cast is needed (actually only in I/O and for user
interface indexed). Oh and, by the way, that made me found the evil
encoding of a layer pair for vias... I still have to fix it, I need to
study the code better for that. That's one of the reason for not
committing the whole LAYER_NUM modification (the other one is that I'm
still not happy with the enum representation).

In some project they go to the extreme to typedef even different
coordinates system, i.e. logical coords are a type and physical coords
are another; in that way you *can't* use the wrong reference system. In
ADA even if you typedef to an int you get a whole different type
*incompatible* to an int (that's a really static type system...)

It's more useful anyway than encapsulating a variable with public getter
and setter that don't do nothing special.

-- 
Lorenzo Marcantonio
Logos Srl