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

K>Пример в смысле работающего кода, на котором можно производительность оценить.

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

_>>У нас уже есть прямо в языке std::thread, соответственно добавив к ним шаблонные функции типа send и receive и договорившись не использовать другие способы обмена данными (типа общей памяти) между потоками, мы уже получим полноценный вариант модели акторов.
K>Спасибо, подозрения о уровне полноценности подтвердились.

И что по вашему ещё должно обязательно входить в реализацию модели акторов? )

_>>Дорисовать пару строчек в класс, чтобы было полноценное универсальное решение, а не для форума? ) Или вы сами в силах себе их представить? )
K>Вы, видимо, имеете в виду копирование массива при создании версии. Ну так какое это отношение имеет к персистентным структурам данных?

Копирование только в случае если это не последняя версия. А при расширение от последней (собственно только этот случай и происходил в той нашей задачке) никакого копирования.

K>Опять двадцать пять.

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

K>1) Для хоть сколько-нибудь нетривиальных иммутабельных структур данных вы стеком не обойдетесь.

Смотря что называть стеком. Скажем vector<Struct> лежащий в стеке (но при этом сами данные естественно где-то в динамической памяти) — это у нас как считается? )

K>2) С какой стати пул эффективнее ГЦ на сценариях использования иммутабельных объектов? Вы не сможете освободить большинство пулов, в каждом останется 5% живых объектов. Эффективность, конечно, лучше некуда.

Мы используем пул не в качестве сборщика мусара (некой универсальной штуки, работающей со всей памятью в программе), а используя знания о конкретной задаче. Т.е. используется точное "внешнее" знание о времени жизни объектов, а не отслеживание их системой. Собственно пример выше уже был, но т.к. там пул был всего один, это не было особо очевидно. Ну могу привести ещё простейший пример... Вот допустим у нас программа работает с некоторыми документами. Мы можем заводить по пулу на каждый документ, размещать в нём всё связанное с документом и соответственно убивать его при закрытие. Понятна идея? )

Но вообще говоря это всё требуется только для очень специфических задач (которые однако частенько приводят любители Java и т.п. при сравнение быстродействия с C++). А для подавляющего большинства обычный RAI в C++ является эффективнее любых сборщиков мусора.