[Gpsbabel-code] Re: [Gpsbabel-misc] Clarification of the duplicate filter

[Robert L. <rob...@us...>]

[ moved from -misc ] 

> We'd still need to deal with swapping between "-i s_and_t ... -i arc
> ... -i csv... -o ozi..."

What if we had a back-channel that let xcsv_{rd,wr}_[de]init see which
svec we were working with?   Just squirrelling svec->style_buf in a global
in vecs.c and moving the xcsv_{read,destroy}_internal_style in xcsv_.*_init
might get us where we need to be.

Yeah, it kind of breaks my pretty poor-man's OO model to smuggle things
around like this, but welcome to adulthood.  I think our xcsv/style
model is worth some compromises here.

> Of course, simply removing the calls to xcsv_destroy_style() is a
> viable interim solution.  But in the case of the 2 million style
> sheets, we'd alloc up a whole lot of memory really quick.

I was trying to pick absurd examples.  We do know of people passing two
million waypoints through GPSBabel in a single invocation.  (Yeah, I'll
admit I was impressed. :-) While being conservative with memory in style
sheets is a good thing, we just plain won't have that many.

I resolve to leave the project when we support one million file formats
since I'll likely be in a rubber room by then...

> I wonder if the proper solution is to simply maintain an array of
> xcsv_file structs.  We load 'em up when we need to and keep 'em

Well, we never really need more than one at a time anyway, so I don't
understand how that directly helps.  We just have schizophrenia on when
they're created and torn down, right?

RJL