[postgis-users] GEOS / Predicates Update

[David Blasby]

 >  - Try the very latest gcc, glibc, and libstdc++ libraries and see if 
 > the problem has been resolved.

I'd also like to ensure that the up-to-date linux libraries and 
compilers solve the problem.  I'd also like to know what happens on a 
cygwin/win32 system.


>   - Re-write some chunks of GEOS to not throw exceptions. This is bad 
> for two reasons.  It is a large amount of work, and it also is bad 
> design.  The exceptions are there for a reason, and replacing them with 
> large chains of null handling will be unpleasant.  There are some 
> "exception emulation" libraries for C which could make the process less 
> unpleasant, but it will still not be nice at all.

I'm voting for this option because I think the compiler-and-library 
version problem will solve itself over time (click your feet and say 
"there's no place like home").

There are remarkably few THROWs in GEOS - only about 63.  There are
only about 20 CATCHes.

The simpliest way to do the conversion would be to have the functions
return, say, NULL if an error occurred.  The calling function would have 
to check to see if the result is NULL - if it is it could propogate the 
error up.
For functions that have NULL as a valid result, you could return a 
simple object like this (excuse my java pseudo-code):
{
	boolean errorOccurred;
	Object result;
}
The calling function would check to see if result.errorOccurred is true. 
   This could be auto-matically handled using macros.  There are already 
existing exceptions-for-C open source projects that do something like this.

There are two problems with this:
1. I'm not sure how the code is layed out - there could be a large 
number of functions to check and modify.  It could also get ugly.
2. Libraries and things like templates may throw-errors-behind your back.


>   - Re-write GEOS entirely, and again, in C. This at least would be a 
> clean implementation of the algorithms, but it is even more work, and 
> would constitute yet another port of JTS which would have to be kept 
> synchronous with the JTS R&D over time.

I dont think this would be wise idea - its way too much work for too 
little gain.  Any C implementation would be uglier than C++ without
exceptions.


dave