kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #13661
Re: Damned the 'undefined global constructor order'
On Tue, Jun 10, 2014 at 01:49:04PM -0500, Dick Hollenbeck wrote:
> If you back out of your operator | ( LAYER_NUM ), and only use this operator with the
> masks, then we might envision a migration path to YOUR objective. The objective is "get
> rid of the layer masks". I'm saying we can do it over time.
My objecting is removing layer masks literals, not layer masks in
themselves. They are used all around for very useful things.
> A migration path by definition lets you transition between two acceptable alternatives
> over time. I do share your desire to eventually move from the masks, because only then
> could you transcend even 64 layers.
Why that? I can already use std::bitset<128> or maybe std::vector<bool>;
I don't see why you're posing the limit to 64 layers.
> a) destination: use the stock std::bitset::set() methods with LAYER_NUM.
That's what I'm doing now. The LSET aggregates an std::bitset and I have
a constructor and operators to transparently map LAYER_NUM to LSET.
Accepting an uint64_t as an explicit cast is a 'performance' trick to
avoid running all the | operators every time (but of course it only
works with the first 64 layers)... since custom user layers are not
target of special operations (like the filtering for copper layers, or
the special treatment for soldermasks) and dynamic in nature, their set
couldn't be known anyway at compile time.
> b) use the operator | ( uint64_t ) and additional operators, but only with masks until a
> full transition to stock bitset functions can be made.
What blocks that transition currently? I haven't found a single place,
for the moment.
> > The function vs variable advantage is not that important
>
> you did not ask me, so you cannot know.
You cannot state it's important because you make accessor calls even for
unchecked variables (i.e. where an accessor has absolutely no
advantage). The price of that call is the same, so there would be no
loss. Also many of these 'variable' will depend on the actual layer set,
not known at compile time or at startup.
--
Lorenzo Marcantonio
Logos Srl
References