[geos-devel]createEmptyGeometry()

[strk at refractions.net]

Sorry for the confusion.
I checked again and LineString *refuses* to construct
w/out a CoordinateSequence pointer.
If arg is NULL it creates an EMPTY CoordinateSequence.
So there's no problem in the missing checks.

About general plan. I'm adding assertion checking
for Out-Of-Bounds condition in the random 
access operators. The idea is to abort on developers
errors and throw exceptions on malformed input or
when we can do something about it (like TopologyException 
case).
Note that I'm not proceeding with full code scan, but
adding assertions whenever I review a single file for
some other reason.

Thanks for info on shared_ptr.

--strk;

On Sun, Apr 02, 2006 at 04:58:51AM +0200, Mateusz Å?oskot wrote:
> 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
> _______________________________________________
> geos-devel mailing list
> geos-devel at 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.