Manuel Teira wrote:
Some new info about this problem.
I was not able to exactly reproduce the issue with an stanalone and
meaninfull source, but have found a way to pass the compilation (other
than commenting everything, of course). The problem, I think, is related
with the std::lower_bound invocation, as shown before:
"/opt/SUNWspro/prod/include/CC/stlport4/stl/_algo.h", line 491:
Information: Instantiating
std::__lower_bound<qpid::Range<qpid::framing::SequenceNumber>*,
qpid::framing::SequenceNumber,
std::less<qpid::framing::SequenceNumber>,
long>
(qpid::Range<qpid::framing::SequenceNumber>*,
qpid::Range<qpid::framing::SequenceNumber>*,
const qpid::framing::SequenceNumber&,
std::less<qpid::framing::SequenceNumber>,
long*).
All the pain begins (I think) with the fact that the first template type
(the iterator) is not valid to travel through the value type. And this
is produced (I guess) by the call, in RangeSet<T>::addRange(const
Range<T> &r) :
typename Ranges::iterator i =
std::lower_bound(ranges.begin(), ranges.end(), r.begin());
That way, we are passing two valid Range<T>::iterator types and a T
value. changing that with:
typename Ranges::iterator i = std::lower_bound(ranges.begin(),
ranges.end(), r);
it passes the compilation with the Sun Studio 12.
Hum. Odd. The point of lower_bound(i,j,x) is to evaluate *i < x.
Range<T> has an operator< for T but not for Range<T> so I don't understand
how solaris is satisfying *i < x. when x is a Range<T>
I tried the same thing myself and the GNU compiler didn't choke either so there
clearly is some conversion sequence that allows the < comparison but it doesn't
give the right answer because the RangeSet unit tests fail.
HOWEVER: the simple and obvious step of adding:
bool operator<(const Range<T>& r) const { return end_ < r.begin_; }
to RangeSet makes the whole thing work beautifully so I bet it'll now build for
you - comitted in revision 660647
Perhaps the GNU compiler is able to instantiate a whole Range<T> from
the r.begin() argument? However, the Range<T>::Range(const T &t)
constructor is declared as explicit. So, I don't think that should be
the problem
As an outline, does it make sense to pass to std::lower_bound iterators
not compatible with the value argument?
Hah! No it does not. Turns out that one of the requirements on lower_bound is
that "ForwardIterator's value type is the same type as LessThanComparable."
I was under the mistaken impression that it was only required for *i < x to be a
valid expression.
So this whole thing is my goof, thanks for sticking with it.
Cheers,
Alan.
