Re: [guppi-list] egcs and AsciiImport

["Asger Alstrup Nielsen" <alstrup diku dk>]

> While poking around in the AsciiImport class, I noticed that (as far
> as I can tell) most of the code does not depend on the template-ness
> of the class.  The template args specify the input type (and the gui
> output type... but I'll ignore that for now.  Everything I say about
> input should carry over to output), but all of the functions (as far
> as I can tell) just get their data via the readline() function.

Yes, I designed it like this on purpose.

> So rather than have all of that code in a massive header, why not:
> 
> * Create a new non-template class, say AsciiImport_Base, that contains
>   all of the code that is now in AsciiImport but defined readline() to
>   be a pure virtual function.
> 
> * Then create a new AsciiImport<Input,Gui> template that derives from
>   AsciiImport_Base and defines readline() appropriately.

(It should also redefine the reset() method (or is it called restart?), because
readline() and reset() are sisters.)

> Now there may be some good reason why this won't work... but if we
> could do something like this to avoid having to deal with huge
> templates (which always seem to be problematic <grumble>), I think
> that it might be worth it.

It would work.  The main reason I didn't do any of this yet, is that the design
was not fixed.  Now, it is rather fixed (since it works ;-), and it's ready for
the next design iteration.  I agree that splitting it up into two parts makes
sense:  A communications bit that should be generic, but small, and the
importing bit that does the hard work, but does so with the help of the
communications bit.  

I wanted to do this, and I'll do this soon.

Also of good news is that I think I have found a solution to the for-scoping
problems with the VC++ compiler:

#define for if(0);else for

I'll use this in config.h, and we don't have to worry about that anymore.

--

Any comments on my type/value-system proposal?  The goal is to design a
frame-work such that we can define containers for different kinds of types. 
For these containers, we will define an interface similar to DataSet with a
bunch of statistical operations that makes sense on them.
For instance, on a container composed of dates, we would have methods to get
the earliest and the latest date.  Similarly, for a container composed of
enumeration types, we would have a method for getting histogram information. 
You get the idea.

The design goal is to implement this in a way such that each container is
self-contained.  We don't want to use inheritance to do this, because that's
too slow (we want to avoid the extra indirection).  On the other hand, we want
to be able to fill the containers in a uniform way (such that for instance the
ASCII import will be able to handle different types without any code-bloat in
the importing engine).  The type/value-system in the tree is a proposal for the
start of such a framework.
It's an early design, but the overall idea is there.

Greets,

Asger