W dniu 2010-08-16 10:04, Barend Gehrels napisal(a):
hi Adam,
Le 15/08/2010 11:07, Adam Wulkiewicz a écrit :
It strongly depends on used algorithm if you need it or not. If you use some kind of internal, temporary objects you need it. See e.g. http://www.cgg.cvut.cz/members/havran/ARTICLES/ingo06rtKdtree.pdf or http://kesen.realtimerendering.com/Intel-EG07.pdf=
I may be missing something here, but I don't see why the temporary objects in question cannot be stored on the execution stack.
Implementing dynamic memory allocation on the stack could be quite tricky.
Thanks for the links.
In Boost.Geometry we do not allocate dynamic memory ourselves; all polygons, rings, lines, multi-polygons etc are stored as an std:: container, which can be selected at compile-time by the library user (as a template-template-parameter). Besides that it is not part of the concept so library users might select another solution.
Don't know if this is possible in this case, but if it is possible, I would prefer that approach.
Regards, Barend
I move this discusion to the ggl list. Regards, Adam