On 10/16/2013 09:24 AM, Maciej Sumiński wrote: > On 10/16/2013 03:49 PM, Dick Hollenbeck wrote: >> On 10/16/2013 04:09 AM, Maciej Sumiński wrote: >>> It requires hashing function to be prepared (eg. using boost::hash), >>> possibly not very > >> demanding on CPU cycles. >> >> >> Sounds good. A hashtable is probably the best bet. Suggest adding it to >> hashtables.h >> which is where we've put all the hashtables. >> >> Might this work? >> >> /// hash function for RATS_ELEM type >> /// taken from: >> http://www.boost.org/doc/libs/1_53_0/libs/unordered/examples/fnv1.hpp >> struct rats_hash >> { >> std::size_t operator()( const RATS_ELEM& e ) const >> { >> std::size_t hash = 2166136261u; >> >> hash ^= e.m_x; >> hash *= 16777619; >> hash ^= e.m_y; >> hash *= 16777619; >> hash ^= e.m_layer; >> hash *= 16777619; >> hash ^= e.m_net; >> >> return hash; >> } >> }; >> >> >> It puts in the members in reverse order of importance, m_net being most >> important. >> I got this from my "const char*" hash function for which there is a URL >> reference in >> hashtables.h > > Surely, I will give it a try during tests. I was also considering using > netcodes for identification of nodes, but in the end I skipped them. Are > coordinates & layer number not enough to unambiguously determine a node?
In space, yes. Good point. No telling when you will get ahold of the BOARD however, before or after the DRC. A BOARD with two nets going to the same place (read point in space) might get missed or confused. This is a user error, but you need to be able to identify all possibilities at that point in space, no? m_net => was intended to be netcode, but it may not be needed as you suggest. > > Regards, > Orson > . > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
