[geos-devel]createEmptyGeometry()

[Mateusz Łoskot]

strk at refractions.net wrote:
> 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.


Do you mean that e.g. LineString::getCoordinates() and
getCoordinatesN(int n) do not check if points collection is not NULL or
index passed to the getCoordinatesN() is not our of range?

Yes, I think it's quite danger. First, getCoordinates() should check if
points collection is null.
Second, in case of getCoordinatesN() we could take similar approach as
used by STL's std::vector:

There are two acccesors:
vector::operator[]()
and
vector::at()

The first one is faster but less safe: if index passed to the subscript
operator is out of range then undefined behaviour occurs, no exception
is thrown.

The second - at() - accessor is safer but slower, because it checks if
index passed is in range and if it isn't then it throws exception of
type of std::out_of_range.

So, my suggestion is to follow this guideline for interface of every
random-access sequence in GEOS.

> 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.

Here, in getCoordinates(), it is not required to check for null, because
if points object is null, then NullPointerException is thrown, so no
undefined behaviour occurs and execution state can be fixed properly.

This behaviour is quite different in C++ where dereferencing null
pointer is undefined.

> BTW, still we're all learning something, what would happen by 
> dereferencing a NULL shared_ptr<> ?

Smart pointers do not make any checks here.
This makes them as fast as native pointers.

boost::shared_ptr<Foo> ptr; // default = null pointer of type of Foo
if (0 == ptr)
{
   std::cout << "I'm null! \n";
}
else
{
   std::cout << "Here, I'm cool! \n";
}

> Example: boost::shared_ptr<Geometry> g; g->isEmpty();
> 
> Is an exception thrown ?

No.
Boost Smart pointers introduce exception safety for program execution,
but they also have to perform as good (almost) as native pointers:

http://boost.org/libs/smart_ptr/smart_ptr.htm#Exception_Safety

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