CGAL users discussion list

[Philipp Moeller <>]

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.