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@geos.refractions.net http://geos.refractions.net/mailman/listinfo/geos-devel
