A
А, вот как эта хрень, что я делаю, называется😂
ага, я тоже поржал)
Size: a a a
2020 June 16
G
Парни такой вопрос.
Есть state машина, внутри одного state дёргается changeState дважды. А внутри changeState есть move текущего стэйта в другой объект для сохранения. Функция при этом ещё выплняется на текущем объекте. Сам объект не становится null ptr-ом после move, только указатели внутри него обнуляются. С чем может быть связано?
Есть state машина, внутри одного state дёргается changeState дважды. А внутри changeState есть move текущего стэйта в другой объект для сохранения. Функция при этом ещё выплняется на текущем объекте. Сам объект не становится null ptr-ом после move, только указатели внутри него обнуляются. С чем может быть связано?
CD
А чем это отличается от raw ptr? И вообще какой смысл несёт reset в деструкторе?
Короче, оставлять объект в unspecified state перед виртуальным вызовом - категорически плохая идея
A
кста, давно вопрос висит, почему большинство юзает nlohmann/json - вместо, например rapid json?
Он даёт удобный няшный STL-like-интерфейс
A
кста, давно вопрос висит, почему большинство юзает nlohmann/json - вместо, например rapid json?
я перешёл на rapidjson, когда понял, что дикие тормоза - фича конкретно nlohman. Но интерфейс там получше, не поспоришь.
A
Так что ждём апи для аудио, 2d графики, баз данных и прочего
Ну для db по факту надо только api для odbc сделать в плюсовом стиле, мб типа odbcpp или чего-то помодернее
DS
Короче, оставлять объект в unspecified state перед виртуальным вызовом - категорически плохая идея
А, типа обнулиться и потом уж дергать удалятель... Ну обращаться с объектом класса который находится в процессе выполнения деструктора это тоже плохая идея, не только для unique_ptr. Ну и с рекурсивной зависимостью вот недавно подобный пример с leak в векторе упоминали.
CD
А, типа обнулиться и потом уж дергать удалятель... Ну обращаться с объектом класса который находится в процессе выполнения деструктора это тоже плохая идея, не только для unique_ptr. Ну и с рекурсивной зависимостью вот недавно подобный пример с leak в векторе упоминали.
А утверждать, что ты - владелец ресурса в процессе его удаления хорошая идея?
CD
Напоминает легендарный баг беты висты
if (::IsWindow(hWnd)) ::DestroyWindow(hWnd); //CRASH
if (::IsWindow(hWnd)) ::DestroyWindow(hWnd); //CRASH
CD
Давай и из reset() уберем эту логику, чего уж там :)
CD
почему крэш? В чём баг?
DestroyWindow в стеке, не пошло
DS
А утверждать, что ты - владелец ресурса в процессе его удаления хорошая идея?
Конечно, я ж UNIQUE, а все кто хранят на меня ссылки сами дураки. Мне кажется проблема с рекурсией надуманная, а вот делать лишний store в деструкторе это таки то за что мы обычно не платим :)
CD
Конечно, я ж UNIQUE, а все кто хранят на меня ссылки сами дураки. Мне кажется проблема с рекурсией надуманная, а вот делать лишний store в деструкторе это таки то за что мы обычно не платим :)
Хм... лишний STORE вместо LOAD перед кэшмиссом? :)))
CD
Конечно, я ж UNIQUE, а все кто хранят на меня ссылки сами дураки. Мне кажется проблема с рекурсией надуманная, а вот делать лишний store в деструкторе это таки то за что мы обычно не платим :)
И да, если что, я эту проблему не придумал, а нашел и был в полном ужасе от того, что я не могу её никаким образом провалидировать. Я не могу в деструкторы (в качестве defer!) писать вызовы shell функций винды
DS
Хм... лишний STORE вместо LOAD перед кэшмиссом? :)))
Ну согласись это misuse по ссылке то, точно так же можно сказать там ptr = make_unique
CD
Там создать в конструкторе временную папочку, удалить в деструкторе - катастрофа
CD
В оригинальном примере, собственно, у меня клалось во внутреннюю очередь сообщение с фабрики, фабрика хранила guard чтобы это сообщение прибить, а чтобы понимать собственное состояние обнуляла в деструкторе сообщения этот guard
CD
ну и ~factory() { guard = nullptr; } разумеется, иначе heap corruption