kicad-developers team mailing list archive
Mailing list archive
Re: RS274X file format.
Dick Hollenbeck <dick@...>
Fri, 01 May 2009 16:43:14 -0500
Thunderbird 220.127.116.11 (X11/20090318)
Wayne Stambaugh wrote:
Dick Hollenbeck wrote:
What, I am confused. Are there are C++ compilers out there that meet
By using exceptions, it was possible to keep the "error reporting UI
code" out of the low level parser and up at a higher calling layer where
the catch resides.
I like this solution as well. I know in the past there were some issues
using exceptions with wxWidgets. I don't know if that is still the
case. I have avoided using them to prevent portability issue between
1) Don't handle exceptions
2) We want to use them
That would be an odd combination for me.
Me too. I know, we could create a new C++ standard and have twenty
different compiler interpretations of that standard. On second thought,
why bother no one would ever buy into it;) However, as Kicad uses
wxWidgets it makes sense to me to support the compilers that wxWidgets
supports by trying to avoid compiler and C++ library specific issues.
This is why I have been using wxList and wxArray instead of C++ list and
vector. This section
of the wxWidgets documentation is why I have avoided using exceptions in
wxWidgets. It may not be an issue any more but when I see something
like this I always lean towards the conservative side. I guess as long
as exceptions don't propagate up the stack into wxWidgets there should
be no problems.
Please elaborate on what you mean by "stream", by pointing to a specific
C++ class hierarchy. In my specctra import, I specifically abstracted
the input source by using a LineReader class. All that one would need
to do is provide an alternative line reader. That lexer/parser stack
needs lines of text, and it does not care where they come from. There
is no file I/O sprinkled throughout the code. A "line reader" is
perhaps another name for input abstraction, but I chose it because it
says what is needed, a full line of text. Obviously it would be trivial
to create an alternative line reader which gets its data from somewhere
else, from RAM for example.
My only suggestion is to make parsers stream based for
flexibility rather than just file based.
I was thinking along the lines of wxInputStream and wxOutputStream and
all the classes derived from them. See
for more information. wxWidgets has already provided the abstractions
for the higher level stream I/O for sockets, files, memory, etc. It may
be overkill for the specctra importer but it is still a nice set of I/O
There is minimal wxWidgets stuff in the specctra code, intentionally. I
figured somebody would want to hi-jack it for another project some day.
wxWidgets is a UI. There is no UI requirements in there, intentionally,
as mentioned. Everything that needs to be reported is bundled in an
This is my Java experience coming through, and I am comfortable with
using exceptions in this way, way under neath anything associated with
Thanks for the stream definition.