CGAL users discussion list

[Philipp Moeller <>]

 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.