Skip to Content.
Sympa Menu

cgal-discuss - [cgal-discuss] compute_outer_frame_margin() uses < on iterators - change to != ?

Subject: CGAL users discussion list

List archive

[cgal-discuss] compute_outer_frame_margin() uses < on iterators - change to != ?


Chronological Thread 
  • From: Jann Poppinga <>
  • To: "" <>
  • Subject: [cgal-discuss] compute_outer_frame_margin() uses < on iterators - change to != ?
  • Date: Fri, 12 Jun 2009 16:32:21 +0200

Hi all,

I am working with the last example given on http://www.cgal.org/Manual/3.4/doc_html/cgal_manual/Straight_skeleton_2/Chapter_main.html - growing a polygon. I could compile it neither with a list nor with a set as a container, because of the function compute_outer_frame_margin() in file CGAL/computer_outer_frame_margin.h. This function is templated on a iterator type and takes a pair of them. It then iterates over them using (line 60)

for( ForwardPointIterator lCurr = aBegin ; lCurr < aEnd ; ++lCurr )

,i.e. using < instead of the usual !=. Wouldn't it be possible to use != here? I had to write this ridiculous adaptor class to use the function - and it worked:

template<class Iterator>
class PointIteratorAdaptor {
public:
typedef typename Iterator::iterator_category iterator_category;
typedef typename Iterator::value_type value_type;
typedef typename Iterator::difference_type difference_type;
// typedef int differency_type;
typedef typename Iterator::pointer pointer;
typedef typename Iterator::reference reference;


PointIteratorAdaptor( Iterator pIt ) : aIt(pIt ) {};
const SkeletonKernel::Point_2& operator*() const { return *aIt; }
bool operator<( const PointIteratorAdaptor& that ) const {
return aIt!=that.aIt; }
bool operator==( const PointIteratorAdaptor& that ) const {
return aIt==that.aIt; }
PointIteratorAdaptor operator++( ) { ++aIt; return *this; }
PointIteratorAdaptor operator--( ) { --aIt; return *this ; }
private:
Iterator aIt;
};


Please note again this function:
bool operator<( const PointIteratorAdaptor& that ) const {
return aIt!=that.aIt; }


From looking at the code I could find no reason for using <, so IMHO it only limits the usability of the function.

Kind regards,
Jann



Archive powered by MHonArc 2.6.16.

Top of Page