Address of vector question

[McGragger]

I recently have upgraded compilers and my new one enables iterator
checking. When a vector is empty, &v[0] blows up, as it should I
guess. In replacing these I have been torn in using

&*v.begin() or &v.front()

Does anyone prefer one over the other? Why?

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

I recently have upgraded compilers and my new one enables iterator
checking. When a vector is empty, &v[0] blows up, as it should I
guess. In replacing these I have been torn in using

&*v.begin() or &v.front()

Does anyone prefer one over the other? Why?

I'd use front() since you then don't create a new iterator on each
call. I hope you are aware of the fact that that &front() is no better
than &v[0] if the vector is empty, and remember the vector may
relocate after any insert.

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

I recently have upgraded compilers and my new one enables iterator
checking. When a vector is empty, &v[0] blows up, as it should I
guess. In replacing these I have been torn in using

&*v.begin() or &v.front()

Does anyone prefer one over the other? Why?

I'd use front() since you then don't create a new iterator on each
call. I hope you are aware of the fact that that &front() is no better
than &v[0] if the vector is empty, and remember the vector may
relocate after any insert.

Actually, on my platform (VS2005) front() is implemented as 'return
*begin();', so it's about as efficient as &*v.begin(). This, of
course, is implementation dependant.

 

[McGragger]

I recently have upgraded compilers and my new one enables iterator
checking. When a vector is empty, &v[0] blows up, as it should I
guess. In replacing these I have been torn in using
&*v.begin() or &v.front()
Does anyone prefer one over the other? Why?

I'd use front() since you then don't create a new iterator on each
call. I hope you are aware of the fact that that &front() is no better
than &v[0] if the vector is empty, and remember the vector may
relocate after any insert.

Actually, on my platform (VS2005) front() is implemented as 'return
*begin();', so it's about as efficient as &*v.begin(). This, of
course, is implementation dependant.

I am aware of the bigger issue here but I am simply trying to upgrade
code that has worked for a very long time. Thanks for your reply. I
think &v.front() is a little more natural.

 

[Fraser Ross]

"Erik Wikström"
< I hope you are aware of the fact that that &front() is no better
than &v[0] if the vector is empty,


There is 1 less function call parameter with front().

 

[Dizzy]

I recently have upgraded compilers and my new one enables iterator
checking. When a vector is empty, &v[0] blows up, as it should I
guess. In replacing these I have been torn in using

&*v.begin() or &v.front()

Does anyone prefer one over the other? Why?

When vector is empty v.begin() equals to v.end() and you know you should
never dereference v.end() right? (ie *v.begin() when v.empty() is UB).

v.front() has the same problem when v.empty() it's UB.

What is the correct version? Well something along the lines of:
"v.empty()?0:&v[0]" (that assuming that you want to get a 0/NULL pointer
when v is empty).

 

[Clark Cox]

I recently have upgraded compilers and my new one enables iterator
checking. When a vector is empty, &v[0] blows up, as it should I
guess.

If the vector is empty, then *all* of these invoke undefined behavior,
and should not be used.

In replacing these I have been torn in using

&*v.begin() or &v.front()

Does anyone prefer one over the other? Why?

Either check to make sure that the vector isn't empty first:
v.empty()?NULL:&v.front()
or use &v.at(0) and deal with the exception that it can throw.

 

[peter koch]

I recently have upgraded compilers and my new one enables iterator
checking. When a vector is empty, &v[0] blows up, as it should I
guess. In replacing these I have been torn in using

&*v.begin() or &v.front()

Does anyone prefer one over the other? Why?

Use what Clark Cox suggests - or use v.data() which will do the same
thing. Unfortunately, this one is only available in C++ 0x unless I'm
mistaken, so your compiler might not yet support it.

/Peter