LINUX.ORG.RU

Возврат prvalue из функции со взятым мьютексом

 


1

3

Две функции одинаковые по сути

Symbol_info Data_collector::symbol_info() const
{
	Symbol_info ret;
	std::shared_lock<std::shared_mutex> lck(*this->m_mtx);
	ret = this->m_symbol_info;
	return ret;
}
Symbol_info Data_collector::symbol_info() const
{
	std::shared_lock<std::shared_mutex> lck(*this->m_mtx);
	return this->m_symbol_info;
}

Не могут ли возникнуть во втором варианте проблемы, связанные с тем, что m_symbol_info будет прочитан после освобождения мьютекса?

★★

прочитан после освобождения мьютекса?

Но он не будет прочитан после освобождения мьютекса.

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

В этом и вопрос - будет или нет. Я тебя понял, ты обычно дело говоришь. Спасибо.

pavlick ★★
() автор топика

В цпп14 прописали

The copy-initialization of the result of the function call is sequenced-before the destruction of all temporaries at the end of expression, which, in turn, is sequenced-before the destruction of local variables of the block enclosing the return statement.
	
(since C++14)
pavlick ★★
() автор топика
Ответ на: комментарий от fsb4000

А точно. Блин, это же очевидно. Полуденный тупняк у меня.

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 2)
Ответ на: комментарий от pavlick

О, прикольно. Я помню делал именно 1 вариант, потому что студийный компилятор делал наоборот.

anonymous
()
Ответ на: комментарий от rumgot
class Data_collector {
unique_ptr<shared_mutex> m_mtx;
};

Все эти объекты синхронизации не умеют копироваться, а мне надо move’ать Data_collector. Лучше было бы placement new в char buffer[sizeof(shared_mutex)], конечно, но не стал заморачиваться.

ЗЫ: хотя можно и свой deleter в unique_ptr (ну т.е. наличие unique_ptr не отменяет placement new).

pavlick ★★
() автор топика
Последнее исправление: pavlick (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.