On Fri, Mar 31, 2006 at 01:20:51AM +0200, Mateusz £oskot wrote:
> Martin Davis wrote:
> > I thought about this, but on the principal of Occam's Razor decided
> > just to use an empty GC. This has the advantage that there are fewer
> > cases to handle for both developers and clients.
>
> That's clear for me.
>
> strk:
> The only thing I'd do is to review current impl. of GEOS and see if
> there are any possible runtime bugs.
Code is FULL of assumption about the fact that geometries
are not EMTPY... just took a look at LineString.cpp, and
the CoordinateSequence pointer is dereferenced always w/out
checks.
Note that the same happens with JTS. Example:
public Coordinate[] getCoordinates() {
return points.toCoordinateArray();
}
'points' is not checked for being NULL.
In other places it is.
Now, what does this comport in Java I don't know,
but doesn't look correct to me.
BTW, still we're all learning something, what
would happen by dereferencing a NULL shared_ptr<> ?
Example:
boost::shared_ptr<Geometry> g;
g->isEmpty();
Is an exception thrown ?
--strk;
>
> strk:
> Another thing I'd consider is to check if we could check this behaviour
> to operate with types more strictly. May be it would help to get rid of
> dynamic polymorphism overhead.
>
>
> Cheers
> --
> Mateusz £oskot
> http://mateusz.loskot.net
> _______________________________________________
> geos-devel mailing list
> geos-devel@geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
--
/"\ ASCII Ribbon Campaign
\ / Respect for low technology.
X Keep e-mail messages readable by any computer system.
/ \ Keep it ASCII.
_______________________________________________
geos-devel mailing list
geos-devel@geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
