Geometry Boost List: [ggl] spacial index construction interface

Subject: [ggl] spacial index construction interface
From: Bruno Lalande (bruno.lalande)
Date: 2011-03-09 09:51:22

Hi,

>
> The current implementation of the spatial index is, if I'm right, full of
> virtual functions and shared ptr's, which I would like to limit to the
> minimum... If possible, of course.
>

I see your point. A quick glance at the source code indeed shows a few
things that should not be there. The fact of using a shared_ptr to manage
tree elements is probably not the most efficient way to do, for instance. I
would say shared_ptr is more for high level code. At low level within a
library, performance should be the priority. Virtual functions like is_leaf
must go away as well (as discussed).

That said, we must keep in mind that such a tree cannot be obtained only by
compile-time techniques, since it is dynamic. If STL or Boost don't use much
dynamic polymorphism, it is simply because they are all about adapting some
metalibrary to a client code at compile-time. Here, we are talking about the
guts of a machine. If the guts in question take input only at run-time,
obviously they will use run-time techniques. Even a book like "C++ Template
Meta-programming", which is almost all about compile-time computations,
talks about and uses virtuality when it comes to "cross the run-time
boundary" (see "Type Erasure"). And the few Boost library which are more
about applicative tasks than library writing tools definitely use dynamic
polymorphism (e.g. Filesystem, Format, Wave, Serialization,
ProgramOptions...) and dynamic memory allocation (e.g. Iostream,
DateTime...).

So to summarize: we should avoid confusing interaction between library and
client code (which typically involves compile-time techniques), and core
guts implementation (which possibly involves a lot of runtime stuff).

Regards
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20110309/34b42e4f/attachment-0001.html