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

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

lpd>>Вообще идея связывать время жизни переменной и какие-то операции по освобождению ресурсов довольно сомнительная. Время жизни переменной — это исключительно синтаксическая вещь, а освобождение ресурсов — императивная операция. И писать обертки над функциями только чтобы создать временную переменную, рассчитывая что где-то компилятор ее удалит, это удалять зубы через нос.

CK>как раз наоборот, компилятор не забудет удалить, а вот кое кто предпочитает писать код с утечками, потому что так "проще"

Я понимаю, вот совпало, что переменные на стеке компилятор когда-нибудь удаляет, и решили приспособить это дело под освобождение памяти. Это решение явно притянуто за уши, этим мне и не нравится. Ботинок тоже всегда под рукой, и из него вода не выльется. Но чай-то мы пьем из специальных чашек, а не из обуви. Хотя что будет, если авторитетные киноактеры завтра начнут пить из обуви, я не берусь предсказать.

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

CK>ну вот чуть выше я предложил пример:
CK>Если ты попробуешь переписать код так, чтобы этого избежать, то получится жуткая каша, с unique_ptr такой проблемы нет

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

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

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

CK>- free/delete в современных плюсах, как я уже писал, это code smell, попробуй найди хоть одну причину для их использования, кроме личных предпочтений — ничего не получится, т.к. для любого кейса найдется более подходящий и безопасный вариант нежели new/delete или же malloc/free

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

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

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

lpd>>Вообще идея связывать время жизни переменной и какие-то операции по освобождению ресурсов довольно сомнительная. Время жизни переменной — это исключительно синтаксическая вещь, а освобождение ресурсов — императивная операция. И писать обертки над функциями только чтобы создать временную переменную, рассчитывая что где-то компилятор ее удалит, это удалять зубы через нос.

CK>как раз наоборот, компилятор не забудет удалить, а вот кое кто предпочитает писать код с утечками, потому что так "проще"

Я понимаю, вот совпало, что переменные на стеке компилятор когда-нибудь удаляет, и решили приспособить это дело под освобождение памяти. Это решение явно притянуто за уши, этим мне и не нравится. Ботинок тоже всегда под рукой, и из него вода не выльется. Но чай-то мы пьем из специальных чашек, а не из обуви. Хотя что будет, если авторитетные киноактеры завтра начнут пить из обуви, я не берусь предсказать.

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

CK>ну вот чуть выше я предложил пример:
CK>Если ты попробуешь переписать код так, чтобы этого избежать, то получится жуткая каша, с unique_ptr такой проблемы нет

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

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

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

CK>- free/delete в современных плюсах, как я уже писал, это code smell, попробуй найди хоть одну причину для их использования, кроме личных предпочтений — ничего не получится, т.к. для любого кейса найдется более подходящий и безопасный вариант нежели new/delete или же malloc/free

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