[geos-devel] boost

[Mateusz Łoskot]

strk at refractions.net wrote:
> On Wed, Mar 01, 2006 at 12:38:06PM +0100, Stefan Zschocke wrote:
> 
>>Well I am a newcomer, thus my opinion should not count much, anyway here it
>>comes:
>>I think the source-folder should only contain the core files needed to build
>>the geos-library.
>>Then another folder should take the testing stuff and also the examples,
>>which currently are inside the source-folder tree.


Please, don't get me wrong, but I'd just like to share my comments:

> This has changed in the HEAD branch.
> If you want to help here is a summary of what's going on:
> 
> 	- GEOS is known to be slow

Yes, it is. That's why Java source code should not be projected to C++ 
directly. Java to C++ transition must involve *redesign* because, C++ 
provides quite various paradigms of programming (shortly, combination of 
OOP and functional), so not everything has to be object, second dynamic 
polymorphism, common bread in Java, should be avoided in C++. I mean, 
dynamic polymorphism may cause all C++ robustness will be lost.

> 	- GEOS is known to be complex (probably unnecessarily)

Yup, I'd say there is a need of some UML.

> 	- GEOS ABI was too weak, thus we provided 
> 	  a C-API interface to keep binary compatibility
> 	  in the long term

Unfortunately, I can not get the idea of keeping
double APIs: C and C++ :-)))

If something is written in C++, why to bother with C?

>>If the testing code has depencies on boot - fine - as long as the core files
>>for the library (or dll on Windows) don't have them.
> 
> 
> This will likely be the first step. The configure script will
> check for boost availability and skip unit tests build.

Yes, that's a good idea.

> Anyway, given the premises above, having boost as a requirement
> for the core library might help in reducing complexity (of
> tracking allocations, mostly) and possibly improving performance.

Just as I said. If GEOS Team will find something nice in Boost and will 
want to use it, then Boost should be involved as a core dependency, just 
as STL or CRT.

Cheers
-- 
Mateusz Łoskot
http://mateusz.loskot.net