← Back to team overview

kicad-developers team mailing list archive

Re: Damned the 'undefined global constructor order'

 

On Mon, Jun 09, 2014 at 04:25:48PM -0500, Dick Hollenbeck wrote:
> That is attached, the #else now uses a *macro* LMSK() and I'm sure only results in one
> call to the static construction logic.

I fear that getting it to take an uint64_t would create an ambiguity,
since ATM LAYER_NUM is an enum and an enum is implicitly castable to an
int. Even if the overloading worked I'd like to smoke out the few place
where an int is still used as layer id, and that wouldn't catch the
problem (even worse, it would take the int layer and treat it as
a bitmask!)

In the same spirit my current LAYER_MSK has an operator bool() (to check
if at least a bit is set) and an operator int() declared but not
defined, in order to have link errors and catch the wrong usage.

So if I write

if (msk & SILKSCREEN_FRONT_LAYER)

a bool conversion is requested (since an 'if' context calls for a bool)

while if I write

int mask = msk; // also unsigned and more, given promotion rules

an int conversion is requested (and link fails, giving the mistake point :D)

A side effect is that you can't write

if ((msk & SILKSCREEN_FRONT_LAYER) != 0)

since in this way you first call for an int cast (to apply
operator!=(int,int)) and then an implicit int=>bool cast (inherited from
C rules for truth)

OK. The type system in C++ is *really* awful to work with. Haskell as
an even worse one, in some cases at least:P

-- 
Lorenzo Marcantonio
Logos Srl


References