kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

I see the commits. Could have be useful to know before since both me
and the cern people were already working on that.

Some things I don't get and other observations:

Why keep LAYER_NUM around if LAYER_ID is there? the 'incrementable'
property can be easily added to an enum (just define the operators
correctly); is that left as transition until LSEQ/LSET is in place?

More than LSEQ I'd see the usefulness for an iteration interface in
LSET, like 'for each selected layer'. I think that kind of access would
be more frequent (also a 'for each selected' on a mask is a superset of
that operation). Or maybe I've interpreted the comments wrong and LSEQ
is an ordered list of layers (not a range?). Yep it seems so. Delete
that sentence please:D

The operator set for that class seems strange... whatever, if it works.
I would have liked a more idiomatic C++ iterator, but who cares.

Also the ... construction is only feasible with POD types, it will fail
if LAYER_ID becomes a proper object. Maybe some other construction will
be useful for that (like the proposed .set().set().set())

BTW the unsigned char specialization for the enum will most probably
*reduce* performance since structs/classes are unpacked by default but
that declaration would force trimming the value each time. In practice
it will most probably take 4 bytes anyway (if not 8, I don't know
alignment rules for x86_64)

As for the switch vs if optimization... well, we already talked about
it. Should work but I don't expect miracles from that. Compilers usually
knows better anyway:P

... and now I got an uncountable number of conflicts to resolve :(((

-- 
Lorenzo Marcantonio
Logos Srl