Opened 10 years ago

Closed 10 years ago

#2009 closed Feature Requests (wontfix)

suggested resiliency/ease-of-use

Reported by: Dave Abrahams Owned by: Thorsten Ottosen
Milestone: Boost 1.36.0 Component: range
Version: Boost 1.35.0 Severity: Problem
Keywords: Cc: Eric Niebler

Description

If I define a range type X and define only

X::iterator range_begin(X const&);

assuming that it should be picked up for const or non-const X, generic code will break when passed a non-const X when it tries to do boost::begin(x) and that expression reaches inside X looking for a begin() member.

It's possible to make the library resilient against this issue as shown by the enclosed example

Attachments (1)

x.cpp (2.3 KB) - added by Dave Abrahams 10 years ago.

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by Dave Abrahams

Attachment: x.cpp added

comment:1 Changed 10 years ago by anonymous

I could "fix" the code for range2 by adding one typedef:

struct range2 {

range2() {}

typedef char* iterator; typedef iterator const_iterator; this one added char* begin() const { return 0; }

};

Is that good enough, or do you still think it is a big problem that two versions of range_begin() needs to be defined?

-Thorsten

comment:2 Changed 10 years ago by Dave Abrahams

The problem is what happens with range1 with today's library. I put range2 in there just to prove that my solution doesn't break the other cases.

comment:3 Changed 10 years ago by nesotto@…

Ok, I wondering if we could make it a bit simpler by only disabling begin( T& ) if the two iterator types are the same? Or do you want it to work if only one of the iterator types is defined?

-Thorsten

comment:4 Changed 10 years ago by Dave Abrahams

Cc: Eric Niebler added

Oh, well, I suppose it's preferable to work with only one of the iterator types defined as well. On the other hand, I realize this whole thing is really only an issue for a person who is adapting an existing type to the Range concept, since the rest of us can use member functions and nested typedefs, which is sufficiently economical. You might consider whether it is important enough to do anything about.

comment:5 Changed 10 years ago by Thorsten Ottosen

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.