← Back to team overview

kicad-developers team mailing list archive

Re: Damned the 'undefined global constructor order'

 

On Tue, Jun 10, 2014 at 02:22:41PM -0500, Dick Hollenbeck wrote:
> So if we keep it simple, I think the masks can go now in favor of pre-built single bit LSETs.

A LAYER_NUM can be implicitly converted to a LSET, so that the idea.

> Have you tried putting all the static constructors in one file?  I had the idea that they
> would be constructed in order of appearance then.

Yes, there is a rule for that, it's guaranteed.

> Start by defining each layer individually, and build up from there, always building
> another std::bitset in constructors.

Yes, this will do *if* every global using them is defined there after
it. So pieces from the router and from the layer setup dialog and maybe
some other piece around. Not exactly manageable but doable. Also there
is a gcc-specific attribute to give priority to the constructor table at
link time.

> Forget any new operators, I don't see where need them.

Operators make ::GetLayerMask go away. Otherwise instead of having

mask = LAYER_1 | LAYER_2;

you'll have to use

mask = GetMask(LAYER_1) | GetMask(LAYER_2);

Also there is the possibility that masks/layer will need to be referred
to a given layer configuration object or whatever, so I want to be ready
to add a reference or something aside of the mask (something like
container iterators: conceptually they are pointers but they are
associated to their container); in that (pretty complicated!) case,
LAYER_NUM maybe couldn't even be simple integers: the worst case in the
layer discussion calls for a variable number of copper layers (or maybe
a limit of 32 would be reasonable) and a variable number of custom
paired and unpaired layer, where board and library have disjoint sets of
layers to be merged (or even board-to-board if we consider something
like copy and paste). Of course if possible I'd like to avoid such
a complicated implementation...

The last 'feature' I found very useful is to actually *forbid*
conversion from a generic int to a LSET to catch misuse at compile time
(I've smoked most of them a lot of time ago but a few cases popped up).
The explicit modifier seems to let me keep the possibility to predeclare
common mask with standard layers (they must be known at compile time of
course).
Sadly in C++ you can't remove or add methods to classes after their
definition, an alternative would have been to inherit from
std::bitset. But then the interface to std::vector<bool> is *completely*
different... these are the reason for making a new class instead of
a naked std::bitset

-- 
Lorenzo Marcantonio
Logos Srl


References