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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
