Здравствуйте, lpd, Вы писали:


lpd>Я понимаю, вот совпало, что переменные на стеке компилятор когда-нибудь удаляет, и решили приспособить это дело под освобождение памяти. Это решение явно притянуто за уши, этим мне и не нравится.

он не когда-нибудь удаляет, он их удаляет в порядке обратном их созданию, это называется deterministic destruction и прописано в стандарте явным образом

lpd>Точно также освобождение памяти или ресурсов, искусственно привязанных к переменной, в ее деструкторе — это хак чистой воды, лишенный всякой логики. Если ты этого не видишь, то мои аргументы будут бесполезны.

то что мы можем писать свой код в деструкторе, это тоже так совпало и хак чистой воды? если следовать твоей логике, то писать деинициализацию в деструкторе — хак чистой воды, поэтому класс MyFile должен иметь метод destroy, который нужно явно вызывать перед тем как объект будет удален, а в деструкторе ничего делать не надо, не так ли?

lpd>Я это видел, вариант с прямой проверкой результата вызова оператора new или malloc() кашей не считаю. То, что запись auto x = std::make_unique<X>(); более короткая, не значит что она лучше.

дело не в длине записи, вариант с new не возвращает nullptr, он бросает исключение, проверять его придется так:

try {
    x = new X();
    y = new Y();
catch (bad_alloc const&) {
    // что писать здесь?
}

lpd>Если массовые объекты будут удалены вручную, то stop of the world будет быстрее, о чем я и пишу. В тех редких случаях когда этого недостаточно, можно использовать другие способы управления памятью.

во время stop the world фазы объекты не удаляются (то бишь финализаторы не вызываются и память не освобождается), вместо этого GC всего лишь ходит по указателям и находит живые объекты, представь что у тебя массив на миллиард указателей на объекты, GC пройдет по каждому указателю на объект, заглянет в каждый объект и если там есть указатели, пройдет по ним тоже

и чтобы это работало нормально, компилятор в GC языках вставляет барьер после каждой записи в переменную ссылочного типа, что тоже так себе

lpd>Ну вот десятки лет пока умные указатели не встроили в С++, все (в том числе программисты получше Страуструпа и других С++ников) знали про умные указатели, и почти никто ими не пользовался, кроме как когда они реально были нужны для учета ссылок. А как только Майерс с фанатиками начали пропагандировать unique_ptr<>/shared_ptr<>, сразу выяснилось, что обычный free() code smell.

free это code smell потому что если тебе нужен кусок памяти, то есть std::vector<char> например, если нужно создать объект, то зачем тебе кусок неинициализированной памяти и почему бы не воспользоваться new, если дошло до new, то возникает вопрос, зачем там голый указатель, а не unique_ptr.