[geos-devel] Assertions in CoordinateArraySequence
Charlie Savage
cfis at savagexi.com
Sun Jun 25 23:57:12 EDT 2006
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osgeo.org/pipermail/geos-devel/attachments/20060625/5dde4b9a/smime.bin
More information about the geos-devel
mailing list