On 10/24/2012 11:09 AM, Wayne Stambaugh wrote: > On 10/24/2012 10:28 AM, Dick Hollenbeck wrote: >> On 10/23/2012 03:53 PM, Wayne Stambaugh wrote: >>> On 10/23/2012 9:44 AM, Dick Hollenbeck wrote: >>>> On 10/22/2012 08:44 PM, Wayne Stambaugh wrote: >>>>> Dick, >>>>> >>>>> I figured out what the problem is. To be honest, I'm not sure how the >>>>> library cache loader didn't fail. When a NULL BOARD item is passed to >>>>> the PCB_PARSER constructor, no layer look up table is created. When you >>>>> attempt to parse the module input, the layer checking algorithm >>>>> complains that the layer is indeed not there. The solution is to >>>>> populate the layer look up table with the default layer values using >>>>> BOARD::GetDefaultLayerName(). >>>> That sounds exactly like what I had in mind. Then after that constructor, >>>> if a board is >>>> present it could overwrite entries in that same hashtable I guess. >>> I was actually thinking about using a static member hash table to store >>> the default table. >> Why? >> >> It's the same amount of code, yet is requires more memory space and reduces >> program >> startup time. >> >> I don't see the advantage. Plus this won't cover the case where there is a >> roque yet >> valid layername in a board. >> >> I'd go with the constructor approach, then only have to do straight line >> hashtable lookups. >> > The memory use should be fairly minimal as the hash table is nothing > more than a wxString used to look up a LAYER object where the maximum > number of layer objects is currently 32. No start up penalty would be > incurred. The default layer look up table would be populated at run > time the first time is needed. Since the default layer table is fixed > (unlike the board layer table which can have user defined names), it > only needs to be populated once. My thinking on this was not have to > recreate the exact same layer look up table for every new instance of > PCB_PARSER which when loading the new footprint library would occur for > each footprint file in the library. If you think the memory hit is more > detrimental than the performance hit for recreating the table for every > instance of PCB_PARSER, I'm wouldn't be opposed to populating the > current look up table with the default layers in the constructor of > PCB_PARSER.
No mention was made of my concern for rogue layernames, but I think I understand your concerns fully now. Its going to be easier for me to just fix this. Thanks for your pointers. The conversation is taking longer than the coding would. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
