kicad-developers team mailing list archive
Mailing list archive
Re: RS274X file format.
Wayne Stambaugh <stambaughw@...>
Fri, 01 May 2009 08:52:34 -0400
Thunderbird 126.96.36.199 (Windows/20090302)
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
> 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
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
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. I like the way streams are used by the drawing objects in the
docview sample that ships with the wxWidgets source.
> Computers have so much ram nowadays there is becoming less reason to
> have all kinds of abstract forms of input. It is trivial to read an
> entire file into ram and then walk through it. That would be the
> typical idiom in python.
I sure miss the days of trying to wedge everything in 128K of RAM.
> Yahoo! Groups Links