[geos-devel] Re: [GEOS] #227: Deleting 'void*' is undefined in IntervalRTreeLeafNode class.

[GEOS]

#227: Deleting 'void*' is undefined in IntervalRTreeLeafNode class.
-------------------------+--------------------------------------------------
 Reporter:  mloskot      |        Owner:  geos-devel at lists.osgeo.org
     Type:  defect       |       Status:  new                       
 Priority:  major        |    Milestone:                            
Component:  Core         |      Version:  svn-trunk                 
 Severity:  Significant  |   Resolution:                            
 Keywords:  void         |  
-------------------------+--------------------------------------------------
Comment (by mloskot):

 A little irc discussion with Sandro about this issue from Jan 30, 2009:
 {{{
 <strk> deleting void* ?
 <mloskot> in general, it's trivial to fix - tricky part ->  as long as we
 know base type of the item
 <strk> we never know
 <mloskot> why?
 <strk> you'll have to define a base class just for that
 <strk> and have the actual items subclass it
 <strk> by either multiple-inheritance or wrapping
 <mloskot> what about inserting through a wrapper instead of plain void*?
 <strk> what I said, a wrapper (an abstract base)
 <mloskot> I'd need to think, but for now simplest is to add a thin empty
 base class.
 <strk> yeah, I'd go there
 <mloskot> perhaps we could have a common base class template to all geos
 objects and they we could specialize it with some traits
 <mloskot> like flags
 <strk> I'd rather find "local" solutions
 <strk> or you could end up walking on a looong road, and full of perils
 <mloskot> like
 <mloskot> class polygon : public geos::traits<geos::indexable>
 <mloskot> similar to boost.operators
 <mloskot> later on
 <mloskot> class envelope : public geos::traits<geos::indexable,
 geos::addable>
 <mloskot> etc.
 <strk> eh
 <strk> and bringing all contributors up in the learning curve
 <strk> to even *read* that :)
 <strk> there aren't many void pointers around atm right?
 <mloskot> you mean reading the templatized thing?
 <strk> it would change the semantic of everything, won't it?
 <strk> or, maybe not
 <strk> but the user can't just rely on those added fields to be available
 can it?
 <strk> or does the traits trick ensure a given layout in the virtual table
 ?
 <mloskot> it's only or as many as change of type(s)
 <mloskot> anyway, i don't like void* item ;-)
 <strk> me neither
 <strk> as I said, I'd take an abstract base pointer
 <strk> and move the problem elsewhere
 <strk> local-base class
 <strk> you'd then adapt, wrap or inherit for use
 <mloskot> we have everything polymorphic anyway, so one more abstract type
 wouldn't change much for the performance, or complexity
 <strk> right
 <strk> I think I used thi trick elsewhere in geos codebase (not sure
 though)
 }}}

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/227#comment:1>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).