On Mon, Apr 08, 2013 at 03:17:16PM -0400, Wayne Stambaugh wrote: > 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.
Actually now I think I read something but it was a long time ago, sorry... > 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. Didn't knew about the MSVC deprecation... the plan was to use an enum (like for EDA_COLOR_T, which seems to work pretty well) and indeed in my branch I'm using an enum. The new standard ints will be useful for the layer mask extension: I think that 64 bits will be enough for a while before pulling in an (heavy) bitarray. The idea is that you don't need to know how big or how is done a layer id, since it can only take the 'correct' values. In java you'd have used a whole class maybe, but I think that's overkill for an integer (that's one of the reason for the class enum in C++11). I would have no issue in ripping out the whole LAYER_NUM type, it's a simple search and replace job. However I think that having a self documenting type is more useful than 6 typed keys (IIRC the argument was something like that). We have static type safety at our disposal (at a zero performance price!) and I don't see a good reason to not use it (well, having to define trivial operators like ++ *is* a little disconforting... at least Pascal has prev and succ for that...) -- 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
