kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

Wayne Stambaugh:

> Vladimir,
> 
> I think your concept and logic are sound.  I like the idea that you have
> given thought to incrementally replacing lengths and coordinates without
> breaking anything rather than one huge commit that has the potential to

You're looking directly to the core. :)

> break a lot of things.  I just took a look at your initial commit and it
> seems reasonable.  I have two minor issues.  The LENGTH_XY class name is a
> bit confusing.  An X, Y coordinate pair does not imply length.  A better
> name for this class might be COORDINATE_XY() or simply XY().  The other

Name it is a matter of style, compiler does not matter which name we give. 
LENGTH_XY is just named because that there are LENGTH units. Say, somewhere 
would be like PIXEL_XY for screen coords, or GRID_XY for sch units (as it 
become unitless in SWEET).

Currently I look towards boost library, and 'polygon' there so I think we 
really should use that templates instead.

> potential issue is the performance penalty by using an object instead of a
> standard C type.  In EESchema this is unlikely to be an issue since the
> number of drawable objects is relatively small.  Performance in PCBNew
> might be a different issue.

While playing with compilers and speaking with programmers i found that class 
(with no virtuals) like class foo {int bar; } really is (for modern compiler 
and reasonable oprimisation level) as efficient as just int. There would be some 
pitfalls (like with foo& and inline) but these are wholely rely on programmer. 
As you see, all methods I've done inline, so they should be optimized to plain 
int operations inside calling function.

I've really missed SWEET discussion (haven't read list that period), but 
unitless sch would be really great.

> Wayne

-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61