[geos-devel] WKB parser templates status

[strk at refractions.net]

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;