CGAL users discussion list

[Philipp Moeller <>]

"Tomislav Maric" 
<>
 writes:

> Thank you very much for your advice! :)
>
> I have some further questions, regarding the functors. 
>
> [1] If I will later on run geometrical algorithms on top of the
> Polyhedron_3 that uses some other Point class, I will need to provide
> the functors that are required by the geometrical algorithms, right
> (e.g. convex hull of a polyhedron with my own Point type)? I have read
> about this for the triangulation class in the attached tutorial, page
> 41 (pdf), but triangulation provides a basic template for which the
> needed functors are defined, and as soon as I plug in my Point type
> there, everything fits. This is probably not possible to generalize to
> Polyhedron_3, because there are a lot of geometrical algorithms in
> CGAL runing on polyhedra....

It is a problem you bump into with Kernels a lot. While some data
structures pretend to be agnostic to the kernel and simply accept every
point type the algorithms that work upon them are not and your Point
almost always ends up being a Kernel member. So the "easiest" way is to
define your own Kernel with your own Point type.

>
> [2] I'm kind of getting lost with concepts and refinements, because
> they are intertwining (seem to be to me, I'm a complete newb), how can
> I best find out what requirements need to be satisfied for certain
> operations with types? Should I implement the requirements provided by
> the concept closest to what I need? There seem to be multiple
> solutions to the same type problems.... and I keep getting lost...

Concepts try to express what is expected from a type in terms of syntax
and semantic (sometimes also in run-time complexity). A type that
fulfills all requirements of a concept is a model of that concept. 

A function or class template requires its template arguments to be
models of a certain concept.

Refinement is somewhat like inheritance between classes in
C++. Refinement adds constraints and makes the concept "stronger".

You should try to be exactly as the concept required by the algorithms
you are going to use.

Keep in mind that if a function specifies a return type T it actually
means that the return type of your model must be implicitly convertible
to T, not exactly of type T.

Let us know where we can improve the documentation to make some issues
clearer.

>
> Thanks again! 
>
> Tomislav
>
>> ----- Original Message -----
>> From: Philipp Moeller
>> Sent: 04/24/12 10:47 AM
>> To: 
>> 
>> Subject: Re: [cgal-discuss] using a Point class from another library
>> 
>> "Tomislav Maric" 
>> <>
>>  writes:
>> 
>> > I have managed to make Polyhedron work with my Point class, but when I 
>> > want to read it from an .off file, 
>> >
>> > this function:
>> >
>> > template < class Point> inline
>> > Point&
>> > file_scan_vertex( File_scanner_OFF& scanner, Point& p) {
>> >    typedef typename Point::R R;
>> >    typedef typename R::RT    RT;
>> >    double x, y, z, w;
>> >    scanner.scan_vertex( x, y, z, w);
>> >    if ( w == 1)
>> >        p = Point( RT(x), RT(y), RT(z));
>> >    else
>> >        p = Point( RT(x), RT(y), RT(z), RT(w));
>> >    return p;
>> > }
>> >
>> > from the file "File_scanner_OFF.h" expects my point to have a 
>> > constructor with 4 arguments. For a simple 
>> > example Point class that I wrote, I have added this without a problem, 
>> > but if a Point class is coming from another 
>> > library, it is a problem. I cannot change the library Point class. What 
>> > should I do? 
>> >
>> > Option 1) Inherit from the Point class of the other library and add a 
>> > dummy constructor, counting on 
>> >          implicit casting every time i call a method on the Point to 
>> > cast it up? 
>> >       2) Change the .off File_scanner and adapt it somehow? 
>> >
>> >       ?) ?
>> 
>> The problem is a more complicated. Technically, Polyhedron shouldn't
>> make any assumptions about the concrete type of Point and use a
>> Construct_point_3 functor to construct them. This additional functor
>> would go into the traits as well.
>> 
>> As a workaround, I wouldn't change file_scan_vertex but add an overload
>> to the CGAL namespace, e.g.
>> 
>> namespace CGAL {
>> inline
>> MyPoint&
>> file_scan_vertex( File_scanner_OFF& scanner, MyPoint& p) {
>>  // do my thing here
>> }
>> }
>> 
>> to change the behavior. This should work as far as I have looked at
>> things. If not, I'd prefer method 1.
>> 
>> >
>> > I don't need homogeneous coordinate representation of points, so this 
>> > kind of constructor is not necessary.. 
>> >
>> > Working code is attached. 
>> >
>> > Thank you! 
>> >
>> > Tomislav
>> 
>> HTH,
>> Philipp Moeller
>> GeometryFactory
>> 
>> -- 
>> You are currently subscribed to cgal-discuss.
>> To unsubscribe or access the archives, go to
>> https://lists-sop.inria.fr/wws/info/cgal-discuss