kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

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. 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.

Wayne

> 
> 
> Dick
> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
>