Using std::vector<> and std::shared_ptr<> should cause error

Question

Here is my code of what I am doing :

#include <iostream>
#include <vector>
#include <memory>
using namespace std;

int main()
{
  vector<int> ar = {1};

  shared_ptr<int> sp(&ar[0]);

  cout<<*sp<<endl; // ---- [1]

  ar[0] = 10;

  cout<<*sp<<endl; // ---- [2]

  ar.clear();

  cout<<*sp<<endl; // ---- [3]



  return 0;
}

The output is coming to be :

1
10
10

Instead of cout at [3] I think, there should be any error at runtime, since the the object to be accessed is already deleted. How it is printing 10 in [3]? Or should I use any g++ flag, I am just using g++ -std=c++14 a1.cpp && ./a.out

EDIT: On running on Coliru I found out that clang++ is giving

`*** glibc detected *** ./a.out: double free or corruption (fasttop):     0x0000000002138010 ***`

But g++ is not Coliru.

@DavidRodriguez-dribeas no not even crashing, just exiting like nothing happened! — 0x6773, Jun 08 '15 at 22:52
clearing a vector doesn't mean necessarily that its allocated memory is being deleted. — 101010, Jun 08 '15 at 22:53
Very similar question, though not exactly a duplicate: http://stackoverflow.com/questions/6441218/can-a-local-variables-memory-be-accessed-outside-its-scope — Fabio says Reinstate Monica, Jun 08 '15 at 23:00
This is undefined behaviour, and undefined behaviour is undefined. It may crash, or it may not. All you are doing is accessing memory you shouldn't, its not supposed to be done, but its not necessarily fatal. — Havenard, Jun 08 '15 at 23:00
Where do people get this idea that writing bad C++ code means you are guaranteed to get a crash? — Jonathan Wakely, Jun 08 '15 at 23:12
@JonathanWakely When asked what an invalid access causes, many people answer just by "it'll crash". Because they fear the "oh, if it just does nothing it's fine then" reaction. — Quentin, Jun 08 '15 at 23:16

Jerry Coffin · Accepted Answer · 2015-06-08T23:06:22.490

You're pretty much bypassing anything that would guarantee a run-time error when you try to access outside the current bounds of the vector.

If you want the bounds checked, you might consider something like this instead:

std::vector<int> ar { 1 };

std::cout << ar.at(0); // no problem

ar.clear();

std::cout << ar.at(0); // guaranteed to throw an exception

A shared_ptr is for shared ownership of an object, so the object will be deleted only when there's nothing left to own it. By contrast, a std::vector assumes sole ownership of all the objects it contains, so trying to refer to one of them with a shared_ptr leads only to problems.

On the other hand, the fact that with gcc this manages to exit without a (visible) sign of the problem doesn't technically qualify as a bug in the compiler. At the end of the scope, the shared_ptr and the std::vector will both attempt to free the int to which the shared_ptr refers--but there's no requirement that doing so leads to an error message (officially that's a quality of implementation issue, though I'd certainly agree that showing the message is better than not).

Steephen · Answer 2 · 2015-06-09T00:44:07.727

1

It is an undefined behavior. It may or may not print 10.

std::vector::clear() deleted the object and reallocation is not guaranteed. So system may not reuse that memory, so you may get old value as result if you access the same memory location.

There is an interesting observation, if you check std::shared_ptr::use_cout() after std::vector::clear() operation, you could see answer 1.

  vector<int> ar = {1};

  shared_ptr<int> sp(&ar[0]);

  cout<<*sp<<"\n"; // ---- [1]

  ar[0] = 10;

  cout<<*sp<<"\n"; // ---- [2]

  ar.clear();
  cout<< sp.use_count()<<"\n";

  cout<<*sp<<endl; // ---- [3]

Output

edited Jun 09 '15 at 00:44

answered Jun 08 '15 at 22:54

Steephen

14,645
7
40
47

2

`std::vector<>::clear()` does not deallocate, it is still memory managed by the vector. Still, it is undefined behavior as the object is *not there* anymore. – David Rodríguez - dribeas Jun 08 '15 at 22:57

score 1 · Answer 3 · answered Jun 08 '15 at 22:56

There are a couple of things wrong in your code. The most obvious one is that you are creating a shared_ptr to manage an object that is already managed by the vector and will most probably get a double delete at the end of main.

The other problem is that you have a pointer to an object and use it after the object has been removed, since std::vector<int>::clear does not deallocate the memory you are hitting memory that is still managed by the vector and that's why it does not explode, but the object is not there any more, and you should not be accessing it. If instead of a int it had been a std::string the program may have crashed (it may also not have crashed, that is the nature of undefined behavior)

Yeah, my program `crashed` with `std::string`. :) – 0x6773 Jun 08 '15 at 23:04 — 0x6773, Jun 08 '15 at 23:04

Using std::vector<> and std::shared_ptr<> should cause error

3 Answers3