А проблема тут в том, что код для обеспечения корректности работы полагается на impl Drop for SpanGuard, который убирает последний вставленный span. О чём при написании unsafe-кода всегда надо помнить — так это о том, что, вообще говоря, нет гарантии, что деструкторы будут вызваны, поэтому полагаться на них для обеспечения memory safety нельзя. Так и тут: если SpanGuard утекает (а для это достаточно просто вызвать на нём std::mem::forget), то в глобальном векторе останется ссылка с насильно расширенным временем жизни. Если функция span была вызвана с ссылкой на локальные данные, то после выхода из этой функции в SPANS остаётся висячая ссылка, что прямо декларируется как undefined behaviour в Rust.

Крафтовый борщ — это когда миллениалы изобрели советскую столовую

Го, я создал: @decltype_chat_ptr_t

#prog #rust #amazingopensource
https://github.com/dabreegster/abstreet

#video
В тему: https://www.youtube.com/watch?v=yITr127KZtQ

#prog #rust #cpp #quotes
https://twitter.com/migueldeicaza/status/1205336800862121985

#prog #algo #article
Я раньше не понимал, как работает next_permutation. Теперь, кажется, понимаю.
Next lexicographical permutation algorithm

#prog #cpp

https://wandbox.org/permlink/7sbsqzhbo0o7dOse

о, чудеса из С++ подъехали ❤️

Не понял. Почему так происходит?

потому что порядок вызова аргументов не специфицирован, {} начинает конструктор объекта, создается лок, кидается исключение, а исключения в конструкторе объектов - это плохо, деструктор для не до конца собранного объекта не вызывается. в С++ есть специальный синтаксис для отлова ислючений типа: object(lock a, int& b) : try m_lock(a) catch ... {}, но я его забыл, да и не пользовался ни разу

A::A(const B& b) try : mB(b) 
{ 
    // constructor stuff
}
catch (/* exception type */) 
{
    // handle the exception
}

вот

da