kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Mon, Apr 08, 2013 at 03:17:16PM -0400, Wayne Stambaugh wrote:
> I thought I did pass on your comments to Lorenzo but it's been awhile so
> it may have fallen thru the cracks.  If that is the case, I apologize
> for the mental lapse.

Actually now I think I read something but it was a long time ago,
sorry...

> If your going to use typedefs for integer types, my preference is to use
> the ones defined stdint.h.  I know what a unint32_t is without having to
> look up it's typedef.  I don't know what a LAYER_NUM is without grepping
> the code.  Now that we have officially kicked MSVC to the curb, it is
> safe to use stdint.h.

Didn't knew about the MSVC deprecation... the plan was to use an enum
(like for EDA_COLOR_T, which seems to work pretty well) and indeed in my
branch I'm using an enum. The new standard ints will be useful for the
layer mask extension: I think that 64 bits will be enough for a while
before pulling in an (heavy) bitarray.

The idea is that you don't need to know how big or how is done a layer
id, since it can only take the 'correct' values. In java you'd have used
a whole class maybe, but I think that's overkill for an integer (that's
one of the reason for the class enum in C++11).

I would have no issue in ripping out the whole LAYER_NUM type, it's
a simple search and replace job. However I think that having a self
documenting type is more useful than 6 typed keys (IIRC the argument was
something like that). We have static type safety at our disposal (at
a zero performance price!) and I don't see a good reason to not use it
(well, having to define trivial operators like ++ *is* a little
disconforting... at least Pascal has prev and succ for that...)

-- 
Lorenzo Marcantonio
Logos Srl