← Back to team overview

kicad-developers team mailing list archive

Re: Damned the 'undefined global constructor order'

 

On Tue, Jun 10, 2014 at 01:27:04PM -0500, Dick Hollenbeck wrote:
> I have voiced my concerns and offered my help.  It feels like my help is not welcome.

Not at all, as usual you misunderstood. I'm trying you suggestion for
doing an uint64_t constructor (and renamed it to LSET).  As expected it
gives some ambiguity troubles (since the layers are ints and need to be
added/subtracted as ints that constructor creeps in as a conversion and
it's undecided if the resoult will be an int or a LSET), however marking
it explicit seems to work fine. After all it's needed for the legacy
file format (which stores them as hex values).

After some thinking at least *some* of the aggregate masks could better be
done as functions however: since the layers will be dynamic not
necessarily will be known in advance what of these will be front or
back, for example. Also the 'all' mask and the number of bits could be
variable, depending on some design choice.

Given that the requisites are not fixed yet, I'd like to keep the
choices open. One of the big choices still to be done is if in a given
instance the set of available layers will be fixed or not: in other
words, there will be need of merging/realigning ids?

-- 
Lorenzo Marcantonio
Logos Srl


References