Dick Hollenbeck wrote:
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
compilers.
What, I am confused. Are there are C++ compilers out there that meet
these criteria:
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
<http://docs.wxwidgets.org/stable/wx_exceptionsoverview.html#exceptionsoverview>
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.
My only suggestion is to make parsers stream based for
flexibility rather than just file based.
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.
I was thinking along the lines of wxInputStream and wxOutputStream and
all the classes derived from them. See
<http://docs.wxwidgets.org/stable/wx_wxstreamoverview.html#wxstreamoverview>
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
classes.
