| Thread Previous • Date Previous • Date Next • Thread Next |
Dick Hollenbeck a écrit :Jean-Pierre,As part of the zone re-design, we should also "abstract out" the track to track "electrical continuity testing". For the time being this can be as simply as putting the existing end point match testing, which is done with == tests, into member functions. And for the time being those member functions can still use end point == testing, but can later be enhanced to test for any kind of physical overlap / electrical continuity.For example:bool TRACK::ConnectsTo( const TRACK& track ) const bool TRACK::ConnectsTo( const ZONE& zone ) const bool TRACK::ConectsTo( const SEGVIA& via ) const bool TRACK::ConnectsTo( const D_PAD& pad ) const bool SEGVIA::ConnectsTo( const ZONE& zone ) const { // bi-directional should be equivalently valid: return zone->ConnectsTo(this); } bool ZONE::ContectsTo( const SEGVIA& via ) const bool ZONE::ConectsTo( const TRACK& track ) constWith these black box functions, you could conceptualize a top-down design and defer implementation of all of these until you know exactly what is needed above, and worth investing in time-wise.The top-down design is largely done by identifying member function stubs, identifying their arguments and return values.The UI editing of zone perimeters and ratsnest functions are the bulk of the work up near the top of the design.
jean-pierre charras - INPG wrote:
I'm sure its too early, but I am hoping not to forget the idea, so consider what follows the first of a brainstorm: Maybe we should get rid of TRACK::start and TRACK::end pointers and replace them both with a singleYes.The connectivity algos (a part of ratsnest functions) are very sensible to the end point testing only, because in this case, for a given segment, handle 2 (one per end) other connected items (a pad,via or an other segment end) is sufficient. And when searching a connected item (when building the connectivity), the search is made for only unconnected ends, and is stopped when the first connected item is found. (So, for a given segment, the search is not exhausive, but all the connections are found because something like a connectivity chain is built)(search is made first with pads and after with tracks).The connectivity algorithms must be redesigned if we change this (only 2 ends are tested), so they are very near the top of the design. Problems can be in algos, in connect.cpp, so i must finish the translation of some french comments, and add more comments, to explain some problems.
vector<BOARD_ITEM*> m_ConnectsTo;Then any two connected BOARD_ITEMs would always have entries in their vectors, pointing to back to each other. Say A and B are connected. Then A.m_ConnectsTo contains and entry for B. And B.m_ConnectTo contains an entry for A. If you move B, you can see that A's vector might become obsolete if you move B too far. (And possibly other BOARD_ITEMS too.) But you know that A must be updated because it is in B.m_ConnectTo for now.
If you move an item, you know who's other m_ConnectsTo fields are subject to change as well.
Dick Hollenbeck SoftPLC Corporation http://softplc.com
| Thread Previous • Date Previous • Date Next • Thread Next |
