kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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
> .
>