On 4/8/2013 3:06 PM, Dick Hollenbeck wrote: > Lorenzo, > > > There was a breakdown in communications. > > Were you informed of my objections to LAYER_NUM? > > > Dick
Dick, I thought I did pass on your comments to Lorenzo but it's been awhile so it may have fallen thru the cracks. If that is the case, I apologize for the mental lapse. Lorenzo, If your going to use typedefs for integer types, my preference is to use the ones defined stdint.h. I know what a unint32_t is without having to look up it's typedef. I don't know what a LAYER_NUM is without grepping the code. Now that we have officially kicked MSVC to the curb, it is safe to use stdint.h. Wayne > > > > > On 04/08/2013 01:17 PM, Lorenzo Marcantonio wrote: >> On Mon, Apr 08, 2013 at 12:22:03PM -0500, Dick Hollenbeck wrote: >>> We don't need a special type for each usageof an integer. >> It's here exactly for type safety. Even pointer are integers, in fact >> BCPL (the progenitor of C) used ints as pointer. Still some toolkit >> force you to fit pointer into ints (which isn't even legal in C!) >> But a layer id is *only* a layer id, you can't do math with it and so >> on. In fact in my private branch LAYER_NUM is an enum just like >> LAYER_MSK. In the past I fixed bugs (and comments, and variable names) >> where reading from the code a mask would be passed when in fact it was >> a layer id. C++11 has added features to inhibit the enum to integer >> default promotion, just to say how much the technique is useful... would >> you use only void* for pointers? >> >> Read here: >> http://www.cprogramming.com/c++11/c++11-nullptr-strongly-typed-enum-class.html >> >> enums also can't take "invalid" values unless casted; that avoid checks >> everywhere for their correctness. I have a LayerToInt for the (rare) >> cases where such cast is needed (actually only in I/O and for user >> interface indexed). Oh and, by the way, that made me found the evil >> encoding of a layer pair for vias... I still have to fix it, I need to >> study the code better for that. That's one of the reason for not >> committing the whole LAYER_NUM modification (the other one is that I'm >> still not happy with the enum representation). >> >> In some project they go to the extreme to typedef even different >> coordinates system, i.e. logical coords are a type and physical coords >> are another; in that way you *can't* use the wrong reference system. In >> ADA even if you typedef to an int you get a whole different type >> *incompatible* to an int (that's a really static type system...) >> >> It's more useful anyway than encapsulating a variable with public getter >> and setter that don't do nothing special. >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
