D vs C++ , почти сурковская пропаганда: не пора ли C++ потихоньку готовиться к пенсии?

[settler]

Для тех кому не нравиться GC

Цитата

Smooth Operation
Related to real time programming is the need for a program to operate smoothly, without arbitrary pauses while the garbage collector stops everything to run a collection. An example of such a program would be an interactive shooter type game. Having the game play pause erratically, while not fatal to the program, can be annoying to the user.

There are several techniques to eliminate or mitigate the effect:

Preallocate all data needed before the part of the code that needs to be smooth is run.
Manually run a GC collection cycle at points in program execution where it is already paused. An example of such a place would be where the program has just displayed a prompt for user input and the user has not responded yet. This reduces the odds that a collection cycle will be needed during the smooth code.
Call core.memory.GC.disable() before the smooth code is run, and core.memory.GC.enable() afterwards. This will cause the GC to favor allocating more memory instead of running a collection pass.

[Qraizer]

Угу. Счас набегут RAIIшники и будут смеяться над масштабом этой проблемы.

[settler]

Цитата Qraizer @ 07.04.18, 17:30

Угу. Счас набегут RAIIшники и будут смеяться над масштабом этой проблемы.

Да тут половина постов про то какое дерьмо этот самый GC,
а тут вот вам, не хотите работайте стеком, вот и RAII, не нравиться - gc.disable,
хотите чтоб был деструктор - да ради бога , destoy() в помощь,

Причем GC тут на вскидку еще круче чем у явы, (могу и ошибаться)

А вот и всеми любимые
https://dlang.org/phobos/std_typecons.html#RefCounted.


Главное при разработке подходы не смешивать иначе - бардак.

Сообщение отредактировано: settler - 07.04.18, 21:48

[D_KEY]

Цитата settler @ 07.04.18, 21:35

а тут вот вам, не хотите работайте стеком, вот и RAII, не нравиться - gc.disable,
хотите чтоб был деструктор - да ради бога , destoy() в помощь,

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

Сообщение отредактировано: D_KEY - 07.04.18, 21:46

[settler]

Цитата D_KEY @ 07.04.18, 21:45

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

Это ты решаешь, тебе же пишут for RT systems GC can be slow,
Можешь вообще Сишный код пускать, в местах где RT, как в Яве,
Проблема в том что выбор большой?

Вот пусть applegame раскажет, как умные люди делают .

[applegame]

Цитата settler @ 07.04.18, 21:35

Причем GC тут на вскидку еще круче чем у явы, (могу и ошибаться)

Ошибаешся. Тут он намного хуже, чем у жабы.

Цитата D_KEY @ 07.04.18, 21:45

Как-то не очень себе представляю монолитную систему, где в одном месте GC используется, а в другом нет. Это же неудобно.

Не более неудобно, чем система, которая в одном месте использует shared_ptr, а в другом нет. RAII и GC ортогональные вещи.

Сообщение отредактировано: applegame - 08.04.18, 06:39

[korvin]

Цитата settler @ 07.04.18, 21:35

Причем GC тут на вскидку еще круче чем у явы, (могу и ошибаться)

Ха-ха-ха.

[Qraizer]

Цитата settler @ 07.04.18, 21:35

Да тут половина постов про то какое дерьмо этот самый GC

Он не дерьмо. Он не детерминирован, вот это плохо. Цитата, что ты привёл, рассказывает только об одной проявляющейся проблеме этой недетерминированности, но у неё много сторон, и RAII – одна из них.
Я вот честно, не вижу вообще никакой ниши для GC в C++. C++ предлагает другой, более изящный метод решения проблемы lifetime of dynamic storage objects. Он имеет ровно тот же профит, что и GC – отсутствие утечек ресурсов из-за человеческих ошибок, – он детерминирован, чем выгодно отличается от GC, дёшев в эксплуатации и реализации и при сравнении с сырыми поинтерами архитектурно практически от них не отличается. Да, я о смарт-поинтерах. Выходит, что ни сырые поинтеры, ни GC в C++ просто не нужны. Их не к чему применить.

P.S. applegame, это не моя цитата.

[settler]

Цитата Qraizer @ 07.04.18, 23:23

отсутствие утечек ресурсов из-за человеческих ошибок, – он детерминирован,

ну а если по ошибке или незнанию ты не тот тип возьмешь?
Наличие GC делает невозможным
1. создавать быстрый код,
2. Код где часто надо выделять много памяти есть новый обект , а старый GC eще не стер,
(графика например)
Я работаю вебом с 2007года , никакой проблемы c GC не вижу ,

Добавлено 08.04.18, 05:29

Цитата applegame @ 07.04.18, 22:21

Цитата Qraizer @ 07.04.18, 17:30

Причем GC тут на вскидку еще круче чем у явы, (могу и ошибаться)

Ошибаешся. Тут он намного хуже, чем у жабы.

Как ты это проверял ?

Добавлено 08.04.18, 06:04

Цитата Qraizer @ 07.04.18, 23:23

Он не детерминирован, вот это плохо.

Цитата settler @ 07.04.18, 21:35

Да тут половина постов про то какое дерьмо этот самый GC

Он не дерьмо.

Tы сам пару лет назад в другом холиваре, говорил что это не всегда
проблема.

[applegame]

Цитата Qraizer @ 07.04.18, 23:23

Я вот честно, не вижу вообще никакой ниши для GC в C++. C++ предлагает другой, более изящный метод решения проблемы lifetime of dynamic storage objects. Он имеет ровно тот же профит, что и GC – отсутствие утечек ресурсов из-за человеческих ошибок, – он детерминирован, чем выгодно отличается от GC, дёшев в эксплуатации и реализации и при сравнении с сырыми поинтерами архитектурно практически от них не отличается. Да, я о смарт-поинтерах. Выходит, что ни сырые поинтеры, ни GC в C++ просто не нужны. Их не к чему применить.

Весь этот текст довольно бессмысленный, потому что по сути смарт-поинтеры - это одна из реализаций GC.

Цитата Qraizer @ 07.04.18, 23:23

P.S. applegame, это не моя цитата.

Да, с мобильного писал, не туда нажал. Исправил

[D_KEY]

Цитата applegame @ 07.04.18, 22:21

Не более неудобно, чем система, которая в одном месте использует shared_ptr, а в другом нет.

Если там вместо shared_ptr используется какие-то другие владельцы ресурсов, то вполне удобно(и можно постепенно переводить на unique_ptr, shared_ptr+weak_ptr). Если же там вообще RAII не используется, то это немного странно, но тогда там есть пары функций выделения/освобождения, чем так же можно воспользоваться для перевода на умные указатели.
С GC же так не получится.

Цитата

RAII и GC ортогональные вещи.

Вот есть у меня объект, который сам владеет парой объектов(unique_ptr), а над несколькими объектами ещё разделяет владение(через shared_ptr).
Может ли такой объект контролироваться GC? Если да, то когда мы "отпустим" ресурсы, которыми объект владеет? Может ли такой объект быть полем объекта, который контролируется GC?

Добавлено 08.04.18, 08:00

Цитата applegame @ 08.04.18, 06:44

по сути смарт-поинтеры - это одна из реализаций GC.

Считаю, что такая классификация бессмысленна для современного состояния отрасли
Я бы RC к GC не относил.

Добавлено 08.04.18, 08:16
А будущее, как мне кажется (или хотелось бы), за статическим анализом, за чем-то вроде region inference

[applegame]

Цитата D_KEY @ 08.04.18, 07:31

Если там вместо shared_ptr используется какие-то другие владельцы ресурсов, то вполне удобно(и можно постепенно переводить на unique_ptr, shared_ptr+weak_ptr). Если же там вообще RAII не используется, то это немного странно, но тогда там есть пары функций выделения/освобождения, чем так же можно воспользоваться для перевода на умные указатели.
С GC же так не получится.

Получится, точно также. Не забываем, что умные указатели отличаются от скажем инкрементального GC только детерминированностью уничтожения объектов, а в многопоточных системах, даже с умными указателями нереально контролировать время освобождения ресурса, если одновременно несколько потоков совместно этим ресурсом владеют.
Как показывает практика, детерменированность освобождения ресурса нужна мягко говоря редко. И в этих случаях в GC-языках предусматривают соответствующие средства.

Цитата D_KEY @ 08.04.18, 07:31

Вот есть у меня объект, который сам владеет парой объектов(unique_ptr), а над несколькими объектами ещё разделяет владение(через shared_ptr).
Может ли такой объект контролироваться GC? Если да, то когда мы "отпустим" ресурсы, которыми объект владеет? Может ли такой объект быть полем объекта, который контролируется GC?

Может. Зависит от кода, ресурсы можно отпустить и вручную, если нужно. Может. Все эти uniq_ptr и shared_ptr - химеры плюсов, которые языку с GC не нужны, отлично живется без них, поверь.

Цитата D_KEY @ 08.04.18, 07:31

Считаю, что такая классификация бессмысленна для современного состояния отрасли
Я бы RC к GC не относил.

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

А GC плохо подходит для плюсов, потому что хороший и быстрый GC для подобных языков нереально сделать. Либо получается говно вроде дешного GC, либо очередной C#.
В самом D ничего не намешано. Сам язык сильно GC-ориентирован, а те ссылки, которые привел, Сирожа, это скорее для критических участков кода. Фрилисты с таким же успехом могут быть применены и в плюсах.

Цитата D_KEY @ 08.04.18, 07:31

А будущее, как мне кажется (или хотелось бы), за статическим анализом, за чем-то вроде region inference

Не знаю что это такое.

Сообщение отредактировано: applegame - 08.04.18, 09:26

[D_KEY]

Цитата applegame @ 08.04.18, 09:17

Получится, точно также. Не забываем, что умные указатели отличаются от скажем инкрементального GC только детерминированностью уничтожения объектов

Так я про это отличие и говорю
Оно весьма важно.

Цитата

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

А конкретное время и не нужно. Важно знать, что когда "последний" владелец закончит работать, объект будет удален. Ровно в этот момент. И запустит всю цепочку освобождений, связанную с объектом.

Цитата

Как показывает практика, детерменированность освобождения ресурса нужна мягко говоря редко.

Зависит от задачи. Если она нужна редко, то там C++ возможно и не нужен.

Цитата

И в этих случаях в GC-языках предусматривают соответствующие средства.

Ничего толкового, кроме менеджеров контекста/try-with-resources/using и т.п. не видел. А это только локально, внутри функции, без учёта связи объектов.

Цитата

Может

Когда будет освобожден ресурс?

Цитата

Все эти uniq_ptr и shared_ptr - химеры плюсов, которые языку с GC не нужны, отлично живется без них, поверь.

Да чему тут верить? Я ж сам пишу на языках с GC.
Тут же мы говорим о сочетании в одном языке, в одной системе.

Цитата

Ну и зря, потому что RC запросто может быть использован в некоторых реализациях GC.

Без детектора циклов это не имеет смысл. А если он есть, то это уже не совсем RC. Это реализация сборщика через RC
Сам же RC сборкой мусора не является. Вернее, в современных системах лучше эти понятия разделять.

[Qraizer]

Цитата applegame @ 08.04.18, 09:17

А GC плохо подходит для плюсов, потому что хороший и быстрый GC для подобных языков нереально сделать. Либо получается говно вроде дешного GC, либо очередной C#.

Не согласен. Даже сырые поинтеры вполне можно контролировать "под капотом" технологией, похожей на C++EH. Напомню, что реализация C++EH никак не затрагивает классы и полностью обходится внешними по отношению к охраняемым им объектам структурами данных. Так что вполне можно представить себе реализацию компилятора, который на каждый поинтер заводит счётчик, аддрефит и декрефит его при копировании, присваивании итп и следит за областями видимости этих поинтеров. Это сделает их практически неотличимыми от shared_ptr<>. В итоге получим в общем-то тот самый GC, который хороший, детерминированный и незаметный.
Только цена подобного решения будет велика. Если C++EH практически не сказывается на производительности кода, кроме собственно случаев, когда исключения выбрасываются, то такие поинтеры будут отнимать ресурсы ЦП постоянно. Т.к. принцип нулевой стоимости запрещает сие, поэтому и есть отдельные библиотечные типы, используя которые программер сознательно идёт на этот оверхед.

[negram]

А RC - это сокращение для чего?