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

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

Пример работающего кода, запощенный сюда, с микробенчмарком и всей информацией необходимой для воспроизведения результата.

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

Что бы там по-моему не должно было быть, все вами будет, конечно, отметено как ненужное.

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

_>Копирование только в случае если это не последняя версия.

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

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

А если еще и не расширять — вообще ничего делать не нужно. Вот это да! Пока структуру данных не трогаешь — любая по-вашему иммутабельная, даже та, что еще не написана.

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

Спор в интернете не такая простая вещь как вы думаете. К примеру, если вы приводите неработающий пример — я вовсе не обязан считать его неопровержимым аргументом, как вы от меня сейчас ожидаете.

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

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

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

Так в этом и проблема. В общем случае, в высокоуровневом коде знания о времени жизни нет.

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

А если 90% данных между документами разделяются? Вот иммутабельная структура данных — это набор таких документов. Понятна идея?

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

Это естественно, потому что то, что могут позволить себе программисты на более-менее высокоуровневом языке — программисты на низкоуровневом позволить себе не могут. Разумеется, все что позволить себе нельзя объявляется ненужным и вообще "специфическим" — сегодня в колбасе потребности нет. Программисты на Java могут позволить себе работу с иммутабельными структурами, программисты на D — не могут. Ну и под "поддержкой иммутабельности" вы всю дорогу понимаете осознанную необходимость иммутабельность не использовать.