Re: Assertions in CoordinateArraySequence

> Better idea is to provide two accessors: safe and unsafe, just as at()
> and operator[] member functions in std::vector.

Yes, this would be ok.

> IMO, no profiling is needed because this is well-known issue.
> Consider, why C++ Standard Committee introduced std::vector members I
> named above. Single if clause when called hundreds or thousands times
> will introduce significant overhead for sure.
> Exceptions are even worst, because RTTI comes to the game.

Um, well, it would be nice to see proof of this.  I have a hard time 
imagining an if statement is going to make such a big difference. 
Exceptions would of course be raised very rarely so that should have no 
impact on performance.

> IMHO, the most reasonable solution is to follow C++ STL design and take
> the same decisions to provide optimal performance with guaranteed degree
> of safety. So, all GEOS collections should provide similar API, doubled,
> save and unsafe at the same time like at() and operator[] in std::vector.

Yes, I'd be happy with that.  I think a scripting language should use 
the "safe" version because its much more forgiving and if performance is 
 really such a big deal then you wouldn't be using Ruby or Python - 
instead you'd write a C/C++ client against GEOS.

Strk - what do you think of adding a "safe" version of these calls to 
the C API?

Also, it seems natural that from Ruby or Python you'd create a 
vector/array/list of points and send them off the GEOS.  I can do the 
translation in the wrapper code from array like structures to 
GEOSCoordSeq_setX, GEOSCoordSeq_setY.  However, should the the C API 
have an array getter/setter method also?  The client passes in an array 
and its size, and the C API munges it into the coordinate sequence.

Charlie





Charlie

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
geos-devel mailing list
geos-devel@xxxxxxxxxxxxxxxxxxxx
http://geos.refractions.net/mailman/listinfo/geos-devel