← Back to team overview

kicad-developers team mailing list archive

Re: RS274X file format.

 

Wayne Stambaugh wrote:
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.

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 exception (text).

This is my Java experience coming through, and I am comfortable with using exceptions in this way, way under neath anything associated with wxWidgets.
Thanks for the stream definition.

Dick








Follow ups

References