[geos-devel] WKB parser templates status

[strk at refractions.net]

I've rewritten the WKB subsystem to completely avoid
templates. Standard STL istream and ostream are used
to give same flexibility as the previous implementation.

Tests welcome.

--strk;

On Sat, Sep 03, 2005 at 06:05:34PM +0200, strk at refractions.net wrote:
> Few months later ...
> I've found my default WKB io parameter class (biostringstream)
> to be not-usable in older compilers. GCC-3.3 doesn't allow
> basic_stringstream<unsigned char>, so we should provide a template
> specializzation for it.
> 
> The point is that I'm not sure we should provide adapters, but
> rather use whatever STL provides with an acceptably wider
> availability.
> 
> Do you have suggestions about what to use for binary input/output ?
> A commonly used class would be used to set interface constraints
> (currently .read and .write).
> 
> --strk;
> 
> 
> On Fri, Apr 29, 2005 at 07:34:58PM +0200, strk at refractions.net wrote:
> > The template classes for WKB parser seems to be in a usable
> > state. This is a report and a request for testing and/or
> > discussing the idea beyond them.
> > 
> > WKB parser contains the first implementation of template
> > classes into the GEOS code base. And my first implementation
> > also. For the way I get it templates provide good performance
> > w/out loosing the lack of compiler control we have in the
> > C world with macros.
> > 
> > <rant>
> > I like the idea, as we're developing
> > free software, not one of those black boxes that require
> > object-level extensibility as a mean of closing the sources
> > (isn't this a use for virtual functions?).
> > </rant>
> > 
> > Beside that template function can make code bigger, as every
> > possible parameter will result in a class implementation
> > duplication. WKB parsing was a good candidate as Martin idea
> > of 'extensibility' has potentially two uses: a streamed WKB
> > and a buffered WKB, of which only the second is actually
> > implemented.
> > 
> > In GEOS this became:
> > 	template <class T> ByteOrderDataInStreamT;
> > 	template <class T> WKBWriterT;
> > 	template <class T> WKBReaderT;
> > 
> > The parameter is something that can be .read(where, howmany)
> > from for WKBReaderT and ByteOrderDataInStreamT and something
> > that can be .write(what, howmany) to for WKBWriterT.
> > "where" and "what" are 'pointer-to-byte' types.
> > 
> > I added a typedef for 'byte' in geos/geom.h:
> > 
> > 	typedef unsigned char byte;
> > 
> > A typedef for a convenient WKB parser parameter in geos/io.h:
> > 
> > 	typedef basic_stringstream<byte> biostringstream;
> > 
> > And typedefs for "default" template class instances in
> > their respective headers (geos/WKBWriterT.h and geos/WKBReaderT.h):
> > 
> > 	typedef WKBWriterT<biostringstream> WKBWriter;
> > 	typedef WKBReaderT<biostringstream> WKBReader;
> > 
> > All defininions will be available by including the geos.h header itself.
> > 
> > doc/example.cpp contains example code, where WKBWriter and WKBReader
> > are used to double-check parser correctness by writing WKB, reading
> > it back and comparing IN and OUT using the compareTo() function.
> > 
> > There is a single question left on this regard (comparing)
> > 
> > 	1) The ::compareTo() does not consider LINEARRING and LINESTRING
> > 	   as the same thing. Should it ? There's nothing as LINEARRING
> > 	   in the WKB spec, so the OUT geometry (the one read from WKB)
> > 	   will *never* match the IN if that is a LINEARRING.
> > 	   Using ::normalize() does not help, but does probably change
> > 	   vertex orders, which somehow *invalidate* the test as WKB
> > 	   reading and writing should not change vertex order.
> > 	   Current code in doc/example.cpp uses normalize() and
> > 	   compareTo().
> > 
> > Code and documentation (doxygen) is in CVS.
> > 
> > --strk;
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel at geos.refractions.net
> > http://geos.refractions.net/mailman/listinfo/geos-devel
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel