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

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

Я сравнивал С++17 не с С, а с C++98.

_>Сборку мусора (во всяком случае эффективную, например как в JVM) невозможно просто опциональной прикрутить к системному языку — потребуется его весь переделывать. И именно, потребуется полностью изменить подход в размещение объектов в памяти — появятся ненужные скрытые поля. Из-за которых язык получит те самые тормоза и пожирание памяти, характерные для управляемых языков. Правда как бонус появится рантаймовая интроспекция (рефлексия), но это совсем не то, что требуется для языка, нацеливающегося на нашу C++.

В управляемых языках пожирание памяти не только из-за скрытых полей и сборки мусора, так что некоторое увеличение потребления памяти в C++ роли не играет. А для realtime сборку мусора можно сделать глобально отключаемой, ну или использовать умные указатели как опцию.

_>Семантика перемещения нужна в первую очередь совсем не для оптимизации (в конце концов в текущем коде она редко срабатывает автоматически, т.к. чаще перед ней срабатывает RVO), а как раз для возможности создания автоматического управления памятью (ну и кстати не только памятью, но и любыми другими ресурсами).
Ну тут многие move из-за оптимизации применяют, и даже что-то сравнивали по скорости с move и без. Когда при этом лепят мувы всего вподряд, это совсем абсурд.

_> Потому что без семантики перемещения ты просто физически не сможешь написать безопасный unique_ptr. Т.к. или у тебя будет разрешён оператор копирования (но тогда о каком "владение" можно будет говорить?) или же ты почти ничего не сможешь делать с таким указателем (ни в контейнер положить, ни в лямбду передать, вообще ничего). И кстати по тому же принципу работает множество сущностей стандартной библиотеки (потоки, мьютексы и т.п.), которые заявляют владение и соответственно не могут быть скопированы.

На копирование мьютексов я сам когда-то попал, так что в курсе этой проблемы. А unique_ptr не столь необходим, в подсчете ссылок в том же Objective-C его вроде как не было.
По-моему у тебя и у других любителей последних стандартов просто иррациональное желание усложнять код на ровном месте, отсюда все эти weak_ptr/std::move T&&/template<A,<B,<T>>>. Чем сложнее код, тем сильнее программист?. Наоборот же всегда было.

Насчет того примера что ты приводил с шаблонами, я не против простых шаблонов, какие были в C++98. Хотя и их можно заменить полиморфизмом, и делая это я бы не страдал из-за потерь быстродействия. Оптимизировать нужно только отдельные участки редкого софта вроде кодеков видео, и там (даже без оптимизации самого алгоритма)simd даст выигрыш на порядок выше всей этой вашей возни с шаблонами.

lpd>>вместо неявного освобождения unique_ptr<>, лично я предпочту вручную явно вызвать delete. Хотя да, это вопрос вкуса, спорить наверное бесполезно.

_>Это не вопрос вкуса, а вопрос безопасности. Потому как человек ошибиться может, а машина (компилятор) нет.
Оно в теории да, на практике в большинстве случаев, когда подсчет ссылок вообще нужен, объекты живут не только в одном блоке {}.

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

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

Я сравнивал С++17 не с С, а с C++98.

_>Сборку мусора (во всяком случае эффективную, например как в JVM) невозможно просто опциональной прикрутить к системному языку — потребуется его весь переделывать. И именно, потребуется полностью изменить подход в размещение объектов в памяти — появятся ненужные скрытые поля. Из-за которых язык получит те самые тормоза и пожирание памяти, характерные для управляемых языков. Правда как бонус появится рантаймовая интроспекция (рефлексия), но это совсем не то, что требуется для языка, нацеливающегося на нашу C++.

В управляемых языках пожирание памяти не только из-за скрытых полей и сборки мусора, так что некоторое увеличение потребления памяти в C++ роли не играет. А для realtime сборку мусора можно сделать глобально отключаемой, ну или использовать умные указатели как опцию.

_>Семантика перемещения нужна в первую очередь совсем не для оптимизации (в конце концов в текущем коде она редко срабатывает автоматически, т.к. чаще перед ней срабатывает RVO), а как раз для возможности создания автоматического управления памятью (ну и кстати не только памятью, но и любыми другими ресурсами).
Ну тут многие move из-за оптимизации применяют, и даже что-то сравнивали по скорости с move и без. Когда при этом лепят мувы всего вподряд, это совсем абсурд.

_> Потому что без семантики перемещения ты просто физически не сможешь написать безопасный unique_ptr. Т.к. или у тебя будет разрешён оператор копирования (но тогда о каком "владение" можно будет говорить?) или же ты почти ничего не сможешь делать с таким указателем (ни в контейнер положить, ни в лямбду передать, вообще ничего). И кстати по тому же принципу работает множество сущностей стандартной библиотеки (потоки, мьютексы и т.п.), которые заявляют владение и соответственно не могут быть скопированы.

На копирование мьютексов я сам когда-то попал, так что в курсе этой проблемы. А unique_ptr не столь необходим, в подсчете ссылок в том же Objective-C его вроде как не было.
По-моему у тебя и у других любителей последних стандартов просто иррациональное желание усложнять код на ровном месте, отсюда все эти weak_ptr/std::move T&&/template<A,<B,<T>>>. Чем сложнее код, тем сильнее программист?. Наоборот же всегда было.

Насчет того примера что ты приводил с шаблонами, я не против простых шаблонов, какие были в C++98. Хотя и их можно заменить полиморфизмом, и делая это я бы не страдал из-за потерь быстродействия. Оптимизировать нужно только отдельные участки редкого софта вроде кодеков видео, и там (даже без оптимизации самого алгоритма)simd даст выигрыш на порядок выше всей этой вашей возни с шаблонами.