-1

Why do I get the front element value after I clear the vector? Am I missing some obvious thing? I tried using the erase function too and got the same result. What is the expected result here? size of vector shows 0 too after clearing but vect.front () shows a value. My code is as follows:

#include<iostream>
#include<vector>
using namespace std;
int main()
{
        vector <int> vect;
        vector <int>::iterator it;
        vect.push_back(10);
        vect.push_back(3);
        vect.push_back(5);
        for( int i=0;i<vect.size();i++)
        {
                cout<<vect[i]<<endl;
        }
        vect.clear();
        cout<<"front element "<<vect.front()<<endl;
        cout<<"last element "<<vect.back()<<endl;
        if(vect.empty())
                cout<<"empty"<<endl;
        return 0;
}

output is:

nm@nm:~$ g++ vectortest2.cpp
nm@nm:~$ ./a.out
10
3
5
front element 10
last element 0
empty
nm@nm:~$ 
Nirmalya Misra
  • 95
  • 1
  • 1
  • 10
  • you are not supposed to call `front()` on an empty vector – 463035818_is_not_an_ai Aug 07 '18 at 21:25
  • 1
    Trying to call `front()` on an empty vector produces [*undefined behavior*](https://en.cppreference.com/w/cpp/language/ub). This means that the standard doesn't specify the behavior of your program if you do this, therefore literally anything could happen. This includes a crash, your computer exploding, or simply getting some garbage value. – eesiraed Aug 07 '18 at 21:26
  • Accessing the front element of an empty vector is UB. Simple as that. – Jesper Juhl Aug 07 '18 at 21:26

1 Answers1

3

Calling front() or back() on an empty vector (or any container) is undefined behavior, so anything can happen.

It just so happens that when you clear() the std::vector, you are "erasing" elements from it, in that the size() is decremented, but the physical memory for the internal array is still allocated, leaving the capacity() untouched.

So, in the case of front(), it is likely to return a valid reference to the front of the allocated memory, but you would be outputting old data that still exists at that memory location but is technically stale and invalid. However, in the case of back(), it cannot return a reference to any valid memory, so the data you output from it is indeterminate.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • "You are simply outputting old data that still exists " - *maybe* still exists. – Jesper Juhl Aug 07 '18 at 21:28
  • For an vector of ints, clearing the vector doesn't overwrite the old array content, it just decrements the `size()`, leaving the old values behind in memory, even though they are not being referenced anymore. The vector will not overwrite the old array slots that are no longer being used, but they will still be allocated – Remy Lebeau Aug 07 '18 at 21:30
  • from a standards point of view it destroys the objects. Reading them again could do anything. – Jesper Juhl Aug 07 '18 at 21:32
  • 1
    Perhaps, but from a practical standpoint, few if any implementations will actually waste CPU cycles "destroying" the individual elements when their data type is trivial. But either way, this is undefined behavior and implementation-specific, and so should not be relied on – Remy Lebeau Aug 07 '18 at 21:34
  • 1
    that may be so, but a compiler may well exploit the fact that the elements were destroyed, so any access to them invokes UB unless it's a write. And compilers *love* exploiting UB. – Jesper Juhl Aug 07 '18 at 21:37