Shouldn't derive from Polyhedron_3

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Shouldn't derive from Polyhedron_3

Zohar

I have a code base that uses a mesh that is derived from Polyhedron_3. The derivation was done to add methods in the mesh level such as bbox(). It appears that you shouldn't derive from Polyhedron_3, since packages such as the simplification package uses template specializations to handle the BGL interface, and these need to be reproduced in the derived class.

To correct this, one should hold an additional class for these methods. Unfortunately, it would be too much code to change. Do you have perhaps other suggestions?

It would help me if similar to the decorated items (vertex, edge, face), you'll add a general decorator for the mesh. In practice, I would provide in the Polyhedron_3 object definition a template parameter for a base class it would derive from (i.e. Polyhedron_3 would derive from my class, instead of the other way around).
Reply | Threaded
Open this post in threaded view
|

Re: Shouldn't derive from Polyhedron_3

Zohar
I think that a simple casting of the derived class to Polyhedron_3 resolves
the issue.



--
Sent from: http://cgal-discuss.949826.n4.nabble.com/

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss