ну яВася УткинА иначе сборщик мусора удалит str раньше окончания code-scope, или кто?
В С++ нет сборщика мусора, в нем компилятор вызывает деструкторы, когда объект либо выходит из области видимости либо когда компилятор видит что он не нужен, но со вторым вариантом ситуация неоднозначна, на усмотрение компилятора. А использованная им память может быть потерта внутренними служебными операциями или другими объектами, или кем-то из других потоков.
В принципе, возможен код, который корректно работает но при очередной сборке взял и перестал:
{
TLockObject lock(resource)
операции с лоченым ресурсом
}
где конструктор ставит и деструктор снимает блокировку.
Тут компилятор может как удержать объект lock до конца блока {} так и убить перед первым же оператором после объявления TLockObject lock.
В общем, критерий всех тестеров "а у меня работает" еще не критерий корректности для программистов, оно может и перестать работать при очередной компиляции ))))
Т.е. в C++11 объекты RAII-блокировок std::unique_lock и std::lock_guard не гарантируют, что они будут существовать до конца code-scope, т.е. могут в любой момент быть уничтожены и следующий код не гарантирует потоко-безопасность и правильную работу?
Вы пробовали связаться с комитетом по стандартизации C++ и объяснить Страуструпу, что предлагаемый им принцип RAII-в общем не работает?
http://en.cppreference.com/w/cpp/thread/lock_guard
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
#include <thread>
#include <mutex>
#include <iostream>
int g_i = 0;
std::mutex g_i_mutex; // protects g_i
void safe_increment()
{
std::lock_guard<std::mutex> lock(g_i_mutex);
++g_i;
std::cout << std::this_thread::get_id() << ": " << g_i << '\n';
// g_i_mutex is automatically released when lock
// goes out of scope
}
int main()
{
std::cout << __func__ << ": " << g_i << '\n';
std::thread t1(safe_increment);
std::thread t2(safe_increment);
t1.join();
t2.join();
std::cout << __func__ << ": " << g_i << '\n';
}
