Wayne, regarding:
DRAWSEGMENT::Format(), it concerns me in two minor ways:
case S_SEGMENT: // Line
aFormatter->Print( 0, "line (pts xy(%s) xy(%s))",
FormatBIU( m_Start ).c_str(),
FormatBIU( m_End ).c_str() );
a) I don't think this is s-expression, the xy(...) should be (xy ...)
b) It may be worth considering losing one token, namely the "(draw line" might
be
"(gr_line". (Really, I am just trying to cover my ass.) I don't want to be
blamed for
the slow parsing speed later. :) Any reduction in another token that is
simple like
this is worth considering. Each token in the stream is another delay, which
cumulatively
may be noticeable. Maybe a common prefix for the graphic primitives in this
DRAWSEGMENT::Format() would allow you to omit one token.
Suggesting "gr_" or something like it prefixed to the primitive, instead of a
full token
"draw ". My concern is speed later. However, I'm guessing you are reserving
the right
to makes changes later. :)
I'm guessing it really gets important on the more common objects like tracks
and vias,
*especially tracks*, which end up being about the most common object in the
file.
ALSO:
==========
Maybe we can get the (track...) on one line as a default, this will help also,
since we're using two lines now.
Whitespace in this format is not supposed to matter, but again, I am trying to
get out of the way regarding parsing speed later.
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
