Boost logo

Boost :

From: Daniel Spangenberg (dsp_at_[hidden])
Date: 2003-07-10 07:50:56


Hello Popov!

popov schrieb:

> (not sure it's the right place to post this, but it seems smart_assert is
> (or will) be part of boost, and I can't get the author email addresses. The
> article is:
>
> http://www.cuj.com/documents/s=8464/cujcexp0308alexandr/)
>
> Here's an excerpt of some code:

I have some problems to see the connection between smart_assert and your
errounous code below. Can you explain?

>
>
> template< class iterator_type>
>
> inline client_ostream_type & operator<<( client_ostream_type & out, const
> printer_range_t< iterator_type> &val) {
>
> out << "Range= [" << &*(val.m_first) << "," << &*( val.m_last) << "); "
>
> << "Values= [";
>
> val.m_first and val.m_last are STL iterators.
>
> The problem is with *(val.m_last) (or *(val.m_first)): if val.m_last is the
> end iterator of a container, can we safely dereference it as it is done ?
> What the standard is saying about that one ?
>
> The code works properly with Microsoft STL, but fails using STLPort in debug
> mode: in this latter case, the program asserts and stops at:
>
> reference operator*() const {
>
> _STLP_DEBUG_CHECK(_Dereferenceable(*this))
>
> return *this->_M_iterator;
>
> }
>
> and STLPort outputs in the ouptut window: "STL assertion failure :
> _Dereferenceable(*this)"
>
> So, for STLPort, an iterator pointing to the end of a container can't be
> dereferenced. That seems judicious to me, but is it in accordance with the
> standard ?

Both implementations are right ;-) It leads to undefined behaviour, if you try
to dereference the address behind the sequence (The end iterator). The only
things you are allowed, are reading operations on this iterator, like comparisons
or iterator arithmetic with the other valid iterators of this sequence.

Hope that helps,

Daniel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk