CGAL users discussion list

["Sebastien Loriot (GeometryFactory)" <>]

Did you define a copy constructor and forget to copy the object?
I think in your case, you should use a boost::Variant as the number of
possible types is only 2.



Costas Tsirogiannis wrote:
> Here's scraps of code that are indicative of the situation:
>
> * In the augmented halfedge class I store a CGAL::Object that contains
> * a handle, it could be either a face handle or an edge stored in it:
>
> Object  _corresponding_triangulation_object;
>
> * And the member functions that make use of it are:
>
>  bool overlaps_with_triangulation_edge(void)
>  { bool temp = _corresponding_triangulation_object.template 
> is<Triangulation_face_handle>();
>    return !temp; }
>  
>  void set_corresponding_triangulation_object( Object &obj )
>  { _corresponding_triangulation_object = obj; }
>
>  template< typename Triangulation_item >
>  void set_corresponding_triangulation_object( Triangulation_item &t_item )
>  { _corresponding_triangulation_object = Construct_object()(t_item); }
>
>  Object& corresponding_triangulation_object(void)
>  { return _corresponding_triangulation_object; }  
>
>
> * So let's say that at some point some function "A"  is called where it 
> does this:
>
> Halfedge_handle current_ph;
>
> **** do something with current_ph ****
>
>  Halfedge_handle   target_ph, old_ph;
>
> target_ph = fnwk.surface_polyhedron().split_edge( current_ph );
> target_ph->vertex()->point() = p;
>
>  old_ph = target_ph->next();
>  target_ph->set_corresponding_triangulation_object(current_ph->corresponding_triangulation_object());           
>
>  CGAL_assertion(target_ph->overlaps_with_triangulation_edge());
>  
> target_ph->opposite()->set_corresponding_triangulation_object(current_ph->opposite()->corresponding_triangulation_object());
>  CGAL_assertion(target_ph->opposite()->overlaps_with_triangulation_edge());
>  
> old_ph->opposite()->set_corresponding_triangulation_object(current_ph->opposite()->corresponding_triangulation_object());
>
> * Up to here everything is executed ok. But in the following code, after 
> the execution
> *of "A" is done, when I traverse the polyhedron face that contains the 
> above halfedges I get *segmentation faults  either in the std::cout line 
> or in the line where *->overlaps_with_triangulation_edge() is called.
>
>
> Halfedge_handle other_ph = ..... ;
> Triangulation_edge entry_te = ..... ;
> Triangulation_edge current_te = entry_te;
>
> while( !(other_ph->overlaps_with_triangulation_edge()) || current_te == 
> entry_te )
>   {
>      std::cout << " other_ph->vertex : "<<  other_ph->vertex()->point() 
> << std::endl;
>
>     other_ph = other_ph->next();
>
>     if(other_ph->overlaps_with_triangulation_edge())
>       CGAL::assign(current_te, 
> other_ph->corresponding_triangulation_object() );
>   }
>
>  I think there is no problem with accessing the vertex point, the memory 
> error
> has to do with the triangulation handles stored as objects in the halfedges.
>
> thanks
>
> Constantinos
>
>
>
>
> On Tue, Jul 6, 2010 at 7:48 AM, Sebastien Loriot (GeometryFactory) 
> <sloriot.ml <http://sloriot.ml>@gmail.com <http://gmail.com>> wrote:
>
>     Costas Tsirogiannis wrote:
>
>         Greetings,
>
>         I have a problem with run-time errors coming from an unorthodox
>         use of handles:
>
>          I make use of a triangulation and of an augmented polyhedron_3
>         object. This augmented polyhedron
>         is a refinement of the surface represented by the triangulation
>         : as some algorithm goes on, new edges
>         are added on what used to be the triangular faces. It is
>         important that the halfedges,faces and vertices
>         on the polyhedron that originate from features of the
>         triangulation should point to the corresponding triangulation
>         features.  Thus each feature stores a handle of the original
>         triangulation object: a polyhedron vertex stores a handle
>         to the original triangulation vertex of the same coordinates, a
>         halfedge stores a handle to the triangulation edge or
>         face on which it lies etc.
>          When a feature is refined eg a halfedge is split, these stored
>         handles of triangulation features are copied to
>         the newly created features. And then segmentation faults appear.
>
>     What do you use to split halfedges ? (the underlying question being how
>     your handles are set)
>
>
>         Specifically, things go wrong when there is an attempt
>         to access the handle member object of the new feature outside of
>         the function that created the feature (and copied the
>         handle object to it).  Any ideas for what could fix this?
>
>         thanks
>
>         Constantinos
>
>
>
>     -- 
>     You are currently subscribed to cgal-discuss.
>     To unsubscribe or access the archives, go to
>     https://lists-sop.inria.fr/wws/info/cgal-discuss