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

[Qraizer]

Цитата applegame @ 13.11.15, 13:41

Ну а что есть в C++ для каруселей?

Твоя фантазия. Ну сам посуди, какая логика владения должна быть, скажем, у двусвязного списка?

[applegame]

Цитата Qraizer @ 13.11.15, 18:08

Ну сам посуди, какая логика владения должна быть, скажем, у двусвязного списка?

GC? Которого нет в C++, хотя вполне может быть.

Сообщение отредактировано: applegame - 13.11.15, 18:55

[D_KEY]

Цитата applegame @ 13.11.15, 18:55

Цитата Qraizer @ 13.11.15, 18:08

Ну сам посуди, какая логика владения должна быть, скажем, у двусвязного списка?

GC? Которого нет в C++, хотя вполне может быть.

У D же C/C++'ый GC

[applegame]

Цитата D_KEY @ 13.11.15, 19:11

У D же C/C++'ый GC

Именно, и вроде даже был пропосал на GC.

[D_KEY]

Цитата applegame @ 13.11.15, 17:52

Цитата D_KEY @ 13.11.15, 17:32

Для обмена объектами достаточно unique_ptr и передачи владения.

К сожалению, зачастую недостаточно. Точнее, зачастую невозможно передать владение.

А ты мог бы привести какой-нибудь интересный пример? Задачку может какую.

[korvin]

А почему бы вместо указателя на (большие)данные не передавать указатель на функцию обработки в обратном направлении? Т.е. построить протокол взаимодействия потоков таким образом, чтобы обмен происходил исключительно маленькими порциями сообщений, которые можно тупо копировать и не париться ни над счётчиком ссылок, ни над потокобезопасностью (данные же иимутабельны в нашем обсуждении).

Да, чревато callback-hell, но ведь можно сделать это нормально.

Сообщение отредактировано: korvin - 13.11.15, 20:46

[applegame]

Цитата D_KEY @ 13.11.15, 19:46

А ты мог бы привести какой-нибудь интересный пример? Задачку может какую.

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

Цитата korvin @ 13.11.15, 20:44

А почему бы вместо указателя на (большие)данные не передавать указатель на функцию обработки в обратном направлении? Т.е. построить протокол взаимодействия потоков таким образом, чтобы обмен происходил исключительно маленькими порциями сообщений, которые можно тупо копировать и не париться ни над счётчиком ссылок, ни над потокобезопасностью (данные же иимутабельны в нашем обсуждении).

Ну а указатель на иммутабельные данные разве не есть исключительно малая порция сообщений, которые можно тупо копировать и не париться ни над счётчиком ссылок, ни над потокобезопасностью? Кроме того у меня только несколько постоянно работающих потоков. Для обработки порций данных запускаются отдельные потоки. Они обрабатывают свой кусок и завершаются. Так как я использую D + vibe.d, то вместо потоков я применяю сущности очень похожие на goroutines.

Первая версия была написана на Ruby + Celluloid, но из-за кривой архитектуры надо было все это переписать. От Ruby я отказался из-за динамической типизации.

Сообщение отредактировано: applegame - 14.11.15, 08:51

[D_KEY]

Цитата applegame @ 14.11.15, 08:07

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

А зачем ты передаешь один и тот же элемент в разные потоки?

Цитата

то тут либо голые указатели, либо shared_ptr.

Вообще, в этом примере скорее всего есть тот, кто собирает результат обработчиков и/или ждет их завершения. Вот он и является владельцем. Т.е. сначала владельцем является тот, кто инициирует обработку, а потом он передает владение тому, кто эту обработку ожидает/объединяет результаты и пр.

[applegame]

Цитата D_KEY @ 14.11.15, 08:55

А зачем ты передаешь один и тот же элемент в разные потоки?

Ну а как иначе, если у меня есть скажем сто внешних наблюдателей, которые через RPC-интерфейс желают в любой момент времени прочитать состояние каких-то элементов массива?

Цитата D_KEY @ 14.11.15, 08:55

Вообще, в этом примере скорее всего есть тот, кто собирает результат обработчиков и/или ждет их завершения. Вот он и является владельцем. Т.е. сначала владельцем является тот, кто инициирует обработку, а потом он передает владение тому, кто эту обработку ожидает/объединяет результаты и пр.

Владельцем является по сути массив данных. У никому передать владение он не может. Нет, unique_ptr тут явно не подходит.

[D_KEY]

Цитата applegame @ 14.11.15, 09:14

Ну а как иначе, если у меня есть скажем сто внешних наблюдателей, которые через RPC-интерфейс желают в любой момент времени прочитать состояние каких-то элементов массива?

Но в таком случае и GC не должен собрать этот массив, ведь в любой момент кто-то может запросить его по RPC.

[applegame]

Цитата D_KEY @ 14.11.15, 09:25

Но в таком случае и GC не должен собрать этот массив, ведь в любой момент кто-то может запросить его по RPC.

Сам массив нет, а вот элементы да (точнее не сами элементы, а объекты на которые эти элементы ссылаются).
Массив меняется: какие-то элементы удаляются, новые добавляются. Скажем отдал я несколько элементов в поток обрабатывающий RPC-запрос. Пока запрос обрабатывается эти элементы были удалены из массива. Никаких сбоев не будет. Как только RPC-поток отработает ставшие ненужными элементы будут удалены GC.

Сообщение отредактировано: applegame - 14.11.15, 10:57

[D_KEY]

Цитата applegame @ 14.11.15, 10:49

Сам массив нет, а вот элементы да (точнее не сами элементы, а объекты на которые эти элементы ссылаются).

А я подумал, что данные прямо в массиве лежат. Ок.

Цитата

Массив меняется: какие-то элементы удаляются, новые добавляются.

Кем?

Цитата

Скажем отдал я несколько элементов в поток обрабатывающий RPC-запрос. Пока запрос обрабатывается эти элементы были удалены из массива. Никаких сбоев не будет.

Ну shared_ptr вполне справится Или ты думаешь, что затраты на копирование shared_ptr будут существенными?

[applegame]

Цитата D_KEY @ 14.11.15, 11:03

Кем?

Потоками-обработчиками. Операции чтения/записи в массив приходится синхронизировать мьютексом. Но они достаточно дешевые, так как копируются не сами объекты а только ссылки на них. И массив на самом деле не массив в смысле непрерывной области памяти. Там набор хэш-таблиц.

Цитата D_KEY @ 14.11.15, 11:03

Ну shared_ptr вполне справится Или ты думаешь, что затраты на копирование shared_ptr будут существенными?

Зависит от нагрузки. Лично я в своем проекте ориентировался не на существенность оверхеда shared_ptr, даже если бы прибавилось скажем 10% я бы не переживал особо. Для меня было гораздо важнее удобство использования и безопасность. Хоть ты и сказал, что удобство - это субъективный параметр, но в данном случае он вполне объективный. Простое при прочих равных объективно удобнее сложного.

Сообщение отредактировано: applegame - 14.11.15, 12:02

[D_KEY]

Цитата applegame @ 14.11.15, 11:57

Операции чтения/записи в массив приходится синхронизировать мьютексом.

Но при этом ты беспокоишься о копировании shared_ptr

Цитата

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

Безопасность чего?

Цитата

Простое при прочих равных объективно удобнее сложного.

Ты так говоришь, как будто "простое" и "сложное" - это объективные вещи
Я вот не помню, чтобы shared_ptr мне когда-либо казался сложным. GC сам по себе гораздо сложнее, как и возможные случаи утечек при его использовании.

[Qraizer]

Мне кажется, applegame, ты смешал иммутабельность данных, подлежащих обработке, с иммутабельностью контейнера, их содержащего.