kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Lorenzo,


There was a breakdown in communications.

Were you informed of my objections to LAYER_NUM?


Dick




On 04/08/2013 01:17 PM, Lorenzo Marcantonio wrote:
> 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.
>