I'm actually not sure about this one: Does the standard guarantee
that if there's at least one element in the data container, then
"--container.end()" will work and give an iterator to the last
element in the container?
Or is there a cleaner way of getting an iterator to the last
element?
16  6035 
Hi!
No, the STL does not guarantees that.
If you call operator-- on an empty container, you get some kind
of junk address (which will probably cause a SIGSEGV).
It is completely upon you to check for the existence of elements
in the container... but if there is any, operator-- will do its
job well.
Remember, if you have an empty data container, the last iterator
is the same as the first (on the GNU STL you have both them set
to 0, if I remember well).
You might so want to check for this condition: x.begin() != x.end()
or x.size() 0 ...
[If you do prefer for some reason accessing the last or the first
element directly (without passing through an iterator) you might
also use front() and back() on some containers (eg: vector).
They return trash if the container is empty anyway].
Bye!
Claudio A. Andreoni
Juha Nieminen wrote:
I'm actually not sure about this one: Does the standard guarantee
that if there's at least one element in the data container, then
"--container.end()" will work and give an iterator to the last
element in the container?
Or is there a cleaner way of getting an iterator to the last
element?
Juha Nieminen wrote:
I'm actually not sure about this one: Does the standard guarantee
that if there's at least one element in the data container, then
"--container.end()" will work and give an iterator to the last
element in the container?
Or is there a cleaner way of getting an iterator to the last
element?
rbegin(), assuming the container supports reverse iterators.
--
Ian Collins.
Claudio A. Andreoni wrote:
If you call operator-- on an empty container
Notice that I said this:
Juha Nieminen wrote:
>if there's at least one element in the data container
Ian Collins wrote:
rbegin(), assuming the container supports reverse iterators.
But if I need an iterator, not a reverse iterator?
std::list<int>::iterator iter = l.rbegin();
error: conversion from
`std::reverse_iterator<std::_List_iterator<int, int&, int*'
to non-scalar type
`std::_List_iterator<int, int&, int*>' requested
On 2007-06-17 13:19, Juha Nieminen wrote:
Ian Collins wrote:
>rbegin(), assuming the container supports reverse iterators.
But if I need an iterator, not a reverse iterator?
std::list<int>::iterator iter = l.rbegin();
error: conversion from
`std::reverse_iterator<std::_List_iterator<int, int&, int*'
to non-scalar type
`std::_List_iterator<int, int&, int*>' requested
You can use the base() method to get a normal iterator from a reverse
iterator, notice however that if you can base() on l.rbegin() you get
r.end() so you either have to increment the reverse iterator before
calling base(), or decrement the iterator returned by base() to get an
iterator to the last element.
All of this is quite a lot of extra work however, since --l.end() will
give you an iterator to the last element as long as l.size != 0.
Another thing to notice is that all of this (both using --l.end() and
the reverse-iterator) requires that the container supports bidirectional
iterators (though I'm not aware of any containers that don't).
--
Erik Wikström
In article <46**********************@news.song.fi>, no****@thanks.invalid says...
I'm actually not sure about this one: Does the standard guarantee
that if there's at least one element in the data container, then
"--container.end()" will work and give an iterator to the last
element in the container?
Or is there a cleaner way of getting an iterator to the last
element?
container.rbegin() would be one obvious possibility.
--
Later,
Jerry.
The universe is a figment of its own imagination.
On Jun 17, 11:01 am, Juha Nieminen <nos...@thanks.invalidwrote:
I'm actually not sure about this one: Does the standard guarantee
that if there's at least one element in the data container, then
"--container.end()" will work and give an iterator to the last
element in the container?
No. Depending on how the iterator is implemented, it may or may
not be legal. (Obviously, it's never legal if the iterator
isn't at least bi-directional.)
Or is there a cleaner way of getting an iterator to the last
element?
The only sure way is:
C::iterator it = container.end() ;
-- it ;
For containers with random access iterators, container.end() - 1
also works.
--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze wrote:
The only sure way is:
C::iterator it = container.end() ;
-- it ;
Isn't that exactly what I suggested in my question?
On 18 Jun, 11:08, Juha Nieminen <nos...@thanks.invalidwrote:
James Kanze wrote:
The only sure way is:
C::iterator it = container.end() ;
-- it ;
Isn't that exactly what I suggested in my question?
No. You suggested --container.end() which modifies a temporary - which
is not always legal. The usual example I've seen where your code won't
work is if the iterator is simply a raw pointer.
Gavin Deane
Gavin Deane wrote:
On 18 Jun, 11:08, Juha Nieminen <nos...@thanks.invalidwrote:
>James Kanze wrote:
>>The only sure way is:
C::iterator it = container.end() ;
-- it ;
Isn't that exactly what I suggested in my question?
No. You suggested --container.end() which modifies a temporary - which
is not always legal. The usual example I've seen where your code won't
work is if the iterator is simply a raw pointer.
Why would your version make any difference?
Juha Nieminen wrote:
Gavin Deane wrote:
>On 18 Jun, 11:08, Juha Nieminen <nos...@thanks.invalidwrote:
>>James Kanze wrote:
The only sure way is:
C::iterator it = container.end() ;
-- it ;
Isn't that exactly what I suggested in my question?
No. You suggested --container.end() which modifies a temporary - which
is not always legal. The usual example I've seen where your code won't
work is if the iterator is simply a raw pointer.
Why would your version make any difference?
Consider:
#include <cstddef>
#include <cassert>
template < typename T, std::size_t N >
class array {
T the_data [N];
public:
typedef T* iterator;
array ( T const & value ) {
for ( std::size_t i = 0; i < N; ++i ) {
the_data[i] = value;
}
}
T & operator[] ( std::size_t i ) {
assert( i < N );
return ( the_data[i] );
}
T const & operator[] ( std::size_t i ) const {
assert( i < N );
return ( the_data[i] );
}
std::size_t size ( void ) const {
return ( N );
}
iterator begin ( void ) {
return ( the_data );
}
iterator end ( void ) {
return ( the_data + N );
}
}; // array
typedef array< double, 3 point3d;
int main ( void ) {
point3d P (0.1);
{
// compile time error:
point3d::iterator before_end = -- P.end();
}
{
// fine:
point3d::iterator before_end = P.end();
-- before_end;
}
}
If you had an implementation of std::vector<that uses pointers to
implement iterators, you would run into similar problems.
Best
Kai-Uwe Bux
Kai-Uwe Bux a écrit :
Juha Nieminen wrote:
>Gavin Deane wrote:
>>On 18 Jun, 11:08, Juha Nieminen <nos...@thanks.invalidwrote:
James Kanze wrote:
The only sure way is:
C::iterator it = container.end() ;
-- it ;
Isn't that exactly what I suggested in my question?
No. You suggested --container.end() which modifies a temporary - which
is not always legal. The usual example I've seen where your code won't
work is if the iterator is simply a raw pointer.
Why would your version make any difference?
[snip] code
If you had an implementation of std::vector<that uses pointers to
implement iterators, you would run into similar problems.
I agree with you, this is buggy behavior.
Just not to be misleading about iterator being pointer, such an
implementation would lack iterator traits.
A minimal Input iterator would be:
struct iterator
{
//traits
typedef T value_type;
typedef ptrdiff_t distance_type;
//etc
//actual pointer
T* pointer;
//constructor
iterator(T* def=NULL):pointer(def){}
//assignment operator
iterator operator=(const iterator& it)
{
this->pointer=it.pointer;
return *this;
}
//equality/inequality operator
bool operator==(const iterator& it){return this->pointer==it.pointer;}
bool operator!=(const iterator& it){return this->pointer!=it.pointer;}
//dereference operator
T operator*(){return *(this->pointer);}
//pre/post increment operator
iterator operator++(){++this->pointer;return *this;}
iterator operator++(int){iterator
old(this->pointer);++this->pointer;return old;}
iterator operator--(){--this->pointer;return *this;}
iterator operator--(int){iterator
old(this->pointer);--this->pointer;return old;}
};
And in this case, the example you gave do compile.
Michael.
Michael DOUBEZ wrote:
Kai-Uwe Bux a écrit :
>Juha Nieminen wrote:
>>Gavin Deane wrote:
On 18 Jun, 11:08, Juha Nieminen <nos...@thanks.invalidwrote:
James Kanze wrote:
>The only sure way is:
> C::iterator it = container.end() ;
> -- it ;
Isn't that exactly what I suggested in my question?
No. You suggested --container.end() which modifies a temporary - which
is not always legal. The usual example I've seen where your code won't
work is if the iterator is simply a raw pointer.
Why would your version make any difference?
[snip] code
>If you had an implementation of std::vector<that uses pointers to
implement iterators, you would run into similar problems.
I agree with you, this is buggy behavior.
Well, buggy in the sense that the user's code is incorrect. Pointers are
valid iterators.
Just not to be misleading about iterator being pointer, such an
implementation would lack iterator traits.
No, you get iterator traits from the iterator_traits<Itertemplate
instantiation, not directly from the iterator.
--
-- Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." ( www.petebecker.com/tr1book)
Michael DOUBEZ wrote:
Kai-Uwe Bux a écrit :
>Juha Nieminen wrote:
>>Gavin Deane wrote:
On 18 Jun, 11:08, Juha Nieminen <nos...@thanks.invalidwrote:
James Kanze wrote:
>The only sure way is:
> C::iterator it = container.end() ;
> -- it ;
Isn't that exactly what I suggested in my question?
No. You suggested --container.end() which modifies a temporary - which
is not always legal. The usual example I've seen where your code won't
work is if the iterator is simply a raw pointer.
Why would your version make any difference?
[snip] code
>If you had an implementation of std::vector<that uses pointers to
implement iterators, you would run into similar problems.
I agree with you, this is buggy behavior.
Buggy as in "not standard compliant" or buggy as in "I don't like it"?
Just not to be misleading about iterator being pointer, such an
implementation would lack iterator traits.
[snip]
Huh? By [24.3.1/2], std::iterator_traits<is specialized for any pointer
type T* as:
template<class T>
struct iterator_traits<T*{
typedef ptrdiff_t difference_type;
typedef T value_type;
typedef T* pointer;
typedef T& reference;
typedef random_access_iterator_tag iterator_category;
};
and for T const * as:
template<class Tstruct iterator_traits<const T*{
typedef ptrdiff_t difference_type;
typedef T value_type;
typedef const T* pointer;
typedef const T& reference;
typedef random_access_iterator_tag iterator_category;
};
I thought, a standard conforming implementation of std::vector<Tcould use
T* as iterator and T const * as const_iterator. What is it that I am
missing?
Best
Kai-Uwe Bux
Kai-Uwe Bux a écrit :
Michael DOUBEZ wrote:
>Kai-Uwe Bux a écrit :
>>Juha Nieminen wrote:
Gavin Deane wrote:
On 18 Jun, 11:08, Juha Nieminen <nos...@thanks.invalidwrote:
>James Kanze wrote:
>>The only sure way is:
>> C::iterator it = container.end() ;
>> -- it ;
> Isn't that exactly what I suggested in my question?
No. You suggested --container.end() which modifies a temporary - which
is not always legal. The usual example I've seen where your code won't
work is if the iterator is simply a raw pointer.
Why would your version make any difference?
[snip] code
If you had an implementation of std::vector<that uses pointers to
implement iterators, you would run into similar problems.
I agree with you, this is buggy behavior.
Buggy as in "not standard compliant" or buggy as in "I don't like it"?
>Just not to be misleading about iterator being pointer, such an
implementation would lack iterator traits.
[snip]
Huh? By [24.3.1/2], std::iterator_traits<is specialized for any pointer
type T* as:
I thought, a standard conforming implementation of std::vector<Tcould use
T* as iterator and T const * as const_iterator. What is it that I am
missing?
Nothing. I missed the point.
Michael
On Jun 19, 11:02 am, Juha Nieminen <nos...@thanks.invalidwrote:
Gavin Deane wrote:
On 18 Jun, 11:08, Juha Nieminen <nos...@thanks.invalidwrote:
James Kanze wrote:
The only sure way is:
C::iterator it = container.end() ;
-- it ;
Isn't that exactly what I suggested in my question?
No. You suggested --container.end() which modifies a temporary - which
is not always legal. The usual example I've seen where your code won't
work is if the iterator is simply a raw pointer.
Why would your version make any difference?
The variable it isn't a temporary.
The version I proposed is guaranteed to work with any
bi-directional iterator. The version you proposed isn't.
That's the difference.
--
James Kanze (GABI Software, from CAI) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: kazio |
last post by:
Hello,
So, I need to have double linked, circular list (last element point to the
first one and first one points to the last one). I thought maybe I could
use list container from STL, but...
|
by: matthurne |
last post by:
I am working through exercise 8-2 in Accelerated C++...I am
implementing the function equal(b, e, b2) where b is an iterator for
the first element in a container, e is an iterator pointing to one...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
