CGAL users discussion list

"Philipp Moeller" 
<>
 writes:
> 
>  writes:
> 
> > Philipp Moeller writes:
> >> Guillaume Damiand  writes:
> >> 
> >> > Hi,
> >> >
> >> >
> >> > Le 25/10/2012 13:15, Pawe? P. a écrit :
> >> >> Hi!,
> >> >>
> >> >> I am taking part in the development of project focused on creating 
> >> >> high
> >> >> performance data processing environment in C++ / C++11 right now on 
> >> >> linux (but
> >> >> we are planning to add other platforms in the future). Right now me 
> >> >> and my
> >> >> team are doing research in field of 3D graphics data structures.
> >> >>
> >> >> As one of our options we are concidering CGAL as library, on which we 
> >> >> will
> >> >> base.
> >> >>
> >> >> During the research we came across a big problem with allocating
> >> >> CGAL::Polyhedron_3 on shared memory. We have searched the web for 
> >> >> answer,
> >> >> asked several questions mainly on stackoverflow, but so far, we've 
> >> >> got no real
> >> >> solution.
> >> >>
> >> >> As short overwiew – we want to implement a mechanism allowing for 
> >> >> sharing 3D
> >> >> data structures between applications. Of course it is possible to 
> >> >> stream
> >> >> geometry to OFF format to shared memory from source application and 
> >> >> then
> >> >> stream it back in target application (like in
> >> >> http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Polyhedron/Chapter_main.html#Subsection_25.3.6),
> >> >> but it is to slow for our purpose (double conversion) and we want to 
> >> >> be able
> >> >> to operate on CGAL's geometry inside shared memory, in such way, that
> >> >> independend applications could use it as is.
> >> >>
> >> >> Please take a look at these questions:
> >> >> http://stackoverflow.com/questions/12657030/share-cgals-geometry-between-processes-in-c
> >> >> http://stackoverflow.com/questions/12807616/how-to-allocate-cgals-halfedge-struture-in-shared-memory
> >> >>
> >> >> We know, that according to the CGAL's documentation
> >> >> (http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Polyhedron_ref/Class_Polyhedron_3.html#Cross_link_anchor_1110)
> >> >> the allocators should be as follow:
> >> >>
> >> >> “The fourth parameter Alloc requires a standard allocator for STL 
> >> >> container
> >> >> classes.”.
> >> >>
> >> >> The problem is that it is impossible to use std::allocator on shared 
> >> >> memory.
> >> >>
> >> >> We were trying to use boost::interprocess::allocator as Polyhedron_3
> >> >> allocator, but we have found out that we need stateless allocator like
> >> >> std::allocator (becouse during initialization of Polyhedron_3 there 
> >> >> is no way
> >> >> to pass arguments to constructor of custom, non stateless allocator). 
> >> >> We have
> >> >> also implemented very simple class extending 
> >> >> boost::interprocess::allocator to
> >> >> make it stateless (code sample: http://pastebin.com/uJYG6AP4) The 
> >> >> problem is
> >> >> that it's working with other objects like vector but not with 
> >> >> Polyhedron_3 (it
> >> >> gives some complex compilation errors).
> >> >>
> >> >> We would be very gratefull for any tips/solutions in this matter.
> >> >
> >> > I think you need to modify your MyBoostAllocator class to satisfy all
> >> > the requirements of the std::allocator concept.
> >> >
> >> > I tested your code using another allocator (cf [1]) and it works.
> >> 
> >> The allocator looks (minus the lacking rebind), conforming. From the
> >> errors it seems that In_place_list is at fault
> >> here. In_place_list_iterator has a converting constructor from T* (where
> >> T is the stored type), this won't work when the allocator defines
> >> pointer to by some smart-pointer type, which is the case for
> >> interprocess allocators. I have no idea if this is the only error, but
> >> there are likely to be more.
> >
> > Thank you for all responses.
> > Could you please provide more info or any ideas how to make it working?
> 
> One approach would be to replace the containers internally used by
> Polyhedron_3 with std conforming equivalents or to make the used
> containers conformant with allocator traits.
> 
> > Maybe we could use something else than boost::interprocess::allocator 
> > which will be suitable in case of shared memory usage?
> 
> If you can come up with a shared memory allocator that uses naked
> pointers it should work. No idea if such a thing is feasible.

Thank you, but it seems like a lot of work here.
Does really nobody use CGAL on shared memory?