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

VD>Например, int принципиально изменяем в любом ИЯ. Но не во всех алгоритмах имеет смысл изменять целочисленные переменные. Декларируя переменную как неизменяемую мы можем защитить себя от ошибок связаннях с неверным применением переменных.
Вот только AndreiF хочет иметь возможность с одним и темже объектом в одном контексте работать как с изменяемым, а в другом как с не изменяемым. Те мешает мух с котлетами.

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

AF>Ты будешь смеяться, но и в этом может быть смысл. Например, если нужно выжать из системы максимум производительности — в этом случае тотальная кросс-оптимизация всех модулей будет вполне уместна.
Вот только если не делать так как ты говоришь можно и из системы выжать все и не перекомпилировать весь код.

AF>В любом случае, код, от которого зависят все остальные модули, меняется не так уж и часто.
Нет. В твоей системе придется перекомпилировать вобще все и вобще всегда. Ибо любое изменение кода может повлечь за собой невозможность оптимизации которое цепной реакцией распространиться на всю систему.

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

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

V>>Зато все явно и гибко.

AF>И там тоже явно и гибко...

Ну да, ну да, const_cast'ы рулят!

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

AF>Очень упрощенный пример (на самом деле там должна быть еще куча разных методов и пропертей)
хъ
AF>А теперь пробуем сделать очень простую вещь — заменить тип Transition.Token, вместо char сделать параметризованный тип.
Легко

    public class StateMachine<T>
    {
        public class EpsTransition
        {
            public State Target;
        }
        
        public class Transition
        {
            public T Token;
            public State Target;
        }
        
        public class State
        {
            public List<EpsTransition> EpsTransitions = new List<EpsTransition>();
            public List<Transition> Transitions = new List<Transition>();
        }
        
        public State EntryPoint;
        public List<State> States = new List<State>();
    }

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


GZ>Давай сделаем аналогию работающую на функц. языках. Допустим задача:
GZ>Есть список объектов в котором каждый второй мы должны поменять с третьей, а после этого каждый первый с четвертым.
Обшибочка. Пока писал немного изменил задачу. Поздно было. Читать каждый второй поменять с третьим местами и каждый объект меньший десяти домножить на два.

VladD2 wrote:

>> > C>Я имею в виду, что не нужны для тех целей, для которых используется
> const.
>> > Еще раз повторюсь — const в С++ используется для разных вещей. Это
>> > *перегруженное* ключевое слово.
> C>Не перегружено. Разве что для констант можно было final добавить.
> const используется для объявления констант, не изменяемых переменных и
А чем константа отличается от неизменяемой переменной в данном случае?

> пометки методов признаком неизменения состояния объекта. Спорить с этим
> глупо. Извини, но доказывать тебе очевидные прописные истины у меня
> времени нет.
Объявление константного метода, это по сути приписывание const "скрытой" переменной this. Так что в точности тоже самое.

>> > Хотя согласен, что идея помечать методы (да и классы) как неизменяемые —
>> > это хорошая идея. И надо будет ее реализовать.
>>А что это даст?
> Возможность гарантировать, что метод не изменяет объект. Плюс в будущем
> компилятор может учитывать эти атрибуты чтобы автоматически
> распараллеливать код.
Насчёт распараллеливания не уверен, но вот для оптимизации точно можно.

VladD2 wrote:
> C>Не перегружено. Разве что для констант можно было final добавить.
> const используется для объявления констант, не изменяемых переменных и
> пометки методов признаком неизменения состояния объекта.
И что? Называть это "перегруженостью" я бы не стал.

Ну замени "const" для методов на "immutable" — что от этого лучше станет?

>> > Хотя согласен, что идея помечать методы (да и классы) как неизменяемые —
>> > это хорошая идея. И надо будет ее реализовать.
>>А что это даст?
> Возможность гарантировать, что метод не изменяет объект. Плюс в будущем
> компилятор может учитывать эти атрибуты чтобы автоматически
> распараллеливать код.
Распараллелить автоматически можно (иногда) только если выполняются
одновременно два немутирующих метода. Да и то не всегда.

GlebZ wrote:

> Читать каждый
> второй поменять с третьим местами и каждый объект меньший десяти
> домножить на два.
Я честно говоря, не понял, как это отвечает на вопрос Киберакса.
Арифметика это здорово. Но реальный мир банальнее. Представь себе 2 объекта: Client/Address. Они ссылаются друг на
друга. У них есть свойства Client.Name, Client.Age, Address.House, Address.Country.
И вот на одной форме юзер подредактировал данные клиента, на другой данные адреса. Что где склонируется и почему?

GlebZ wrote:
> То есть копирование списка как такового не понадобилось.
На ленивых списках это бы еще красивее смотрелось. Ты фактически просто
строил бы функциональные виды над списком.

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

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

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

GlebZ wrote:

> kan>сорцы/документацию. Больше никак.
> kan>А если вдруг какой-нибудь метод изменили и он стал изменять
> состояние? Старый код об этом никак не узнает.
> Это не свойство ссылки как в С++. Это свойство типа. Мы же не
> возмущаемся что unsigned int кто-то может перебить как signed int,
Согласен. Однажды созданный final тип должен остаться им навечно. Просто в С++ это не проблема, если какой-то метод из
константного поменять в неконстантный, то код, который рассчитывал на константность — не скомпилится.

>> > случае очень показательны константные строки в C++. Там есть режим
> kan>Не понял что этот пример показывает... просто оптимизация, сташвая
> возможной, благодая нестрогости стандарта.
> Нет. Это эквивалентность.
Подробнее можно? Особенно как в данном случае это можно распространять на непримитивные типы, которые могут ссылаться на
другие объекты.

>> > нарушить данное правило.
> kan>Нет, идея С++ в том, что он небезопасный — можно нарушить любое правило.
> Это не идея C++. Это проблема С++. Нельзя ни в чем быть увереным, и чаще
> короткий путь — путь нарушения контракта.
Кто не понимает этой идеи, видит в этом проблему?

> kan>Как именно поддерживает? Чем эта поддержка принципиально отличается
> от C++? Можно ссылку.
> MSDN.
Спасибо, что не гугл.
Намекну по-другому. А на каком языке нельзя программировать в функциональном стиле?

> kan>Мягко говоря, не очень... скорее тут "виноваты" шаблоны, stl не при
> чём, а это исчисление типов, метапрограммирование.
> Советую проникнуться что такое функциональное программирование и что
> эмулирует функтор.
Ключевое слово "эмулирует". Иначе, благодаря наличию boost::lambda, можно С++ смело называть функциональным.

Здравствуйте, AndrewVK, Вы писали:
AVK>Т.е., по сути, ICloneable это такой аналог ISerializable.
AVK>Провернуть аналогичный финт ушами с ICloneable<T> конечно можно, но, мягко говоря, не тривиально. Поэтому, кстати, IEnumerable<T> наследуется от IEnumerable.
Совершенно верно. Поэтому имеет смысл ICloneable<T> отнаследовать от ICloneable — для работоспособности в нетипизированных сценариях, подобных приведенному тобой.
AVK>Не очень красиво, конечно. Но альтернативой, навскидку, мне видится разве что ковариантность дженерик-интерфейсу по type parameter, чтобы ICloneable<SomeObject> можно было прокастить к ICloneable<object>, но это невозможно из-за логических нестыковок (разное направление ковариантности для in и out параметров членов).

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

VD>Может для тебя это и обычно. Я вообще с object-ами не работаю. И для меня это не обычно.

Это не вопрос того, с чем ты работаешь. Это кусок кода для поддержки компонентной модели дотнета. И тип объекта там на этапе компиляции неизвестен принципиально.

VD> А вот типизированный Clone использовал часто.

Типизированный Clone это без проблем. Речь о типизированном ICloneable<T>. Вот в нем смысла не очень много, разве что в качестве контрейнта для другого дженерика.

VD>Почему не красиво? Вполне нормально. Все зависит от программиста. Не захочет он с обжектами возиться и не будет.

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

VD>Самое смешное, что коваринтности интерфейсов нет только в Шарпе. Дотнет ее поддерживает. Но в твоем случае это безтолку. Тут дизайн приложения надо менять. Обжекты выбрасывать.

Ну выброси обжекты в UITypeEditor

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

AF>Это то же самое, что и константная ссылка на объект, только вручную.

Нет, не то же самое. Главное отличие того, что предлагается в шарпе, от того, что есть в С++, это местоположение ответственности. В случае плюсового const ответственность несет вызываемая сторона, в случае immutable в шарпе — вызываемая. Говорить о том, какой вариант лучше, вот так навскидку я не берусь. На первый взгляд шарповский вариант все же пологичнее.

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

S>Совершенно верно. Поэтому имеет смысл ICloneable<T> отнаследовать от ICloneable — для работоспособности в нетипизированных сценариях, подобных приведенному тобой.

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

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

AVK>>Как раз очень правильно. Потому что утилитный метод лучше делать статическим.

AF>А почему тогда у List<T> его сделали экземплярным?

Потому что пиип.

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

GZ>А теперь оказывается что нельзя быть увереным что объект не изменяется. Нарушать это правило может как другой код, написанный другим программистом. А в случае многопоточки вообще нехорошо получается. В immutable типе размывается понятие value — reference типа при передаче в функцию. В случае если у компилятора доступна информация о том, что объект не будет изменяться он его может передавать как по ссылке, так и по значению. И вообще более часто задействовать редукцию/инлайнинг.

Давай-ка расставим всё по своим местам

Вроде говорили

Автор: kan
Дата: 10.11.06

о константности состояния объекта (константности методов, к которой имеет отношение const_cast<>). Так ведь?

И тут ты упомянул

Автор: GlebZ
Дата: 10.11.06

про "mutable/unmutable", которые, как я заметил

Автор: _FRED_
Дата: 10.11.06

, применяются не к методам, а к переменным, что имеет совсем другой смысл, как разъяснили

Автор: Андрей Хропов
Дата: 11.11.06

. Верно?

А здесь вот, вообще, говоришь об "immutable типе" И вот причём же здесь mutable/def переменные Nemerle

Как-то никакой нити логической не заметно

Cyberax wrote:

>> Возможность гарантировать, что метод не изменяет объект. Плюс в будущем
>> компилятор может учитывать эти атрибуты чтобы автоматически
>> распараллеливать код.
> Распараллелить автоматически можно (иногда) только если выполняются
> одновременно два немутирующих метода. Да и то не всегда.
Можно один, но много раз. Теоретически можно что-то типа такого:

int sum = 0
for(Iter iter = container.begin(); iter != container.end(); ++iter)
{
   sum += iter.getValue();
}

Так вот, теоретически, если методы begin/end/getValue — константные, то компилятор может предположить, что коллекцию
можно обходить в любом порядке, а значит тут можно суммирование распараллелить — для нескольких частей коллекции по
процессору.
Но, насколько я знаю, теоретические измышления по этому поводу до серьёзной практики так и не дошли...

kan wrote:
>> Распараллелить автоматически можно (иногда) только если выполняются
>> одновременно два немутирующих метода. Да и то не всегда.
> Можно один, но много раз. Теоретически можно что-то типа такого:
А если ты из константного метода используешь mutable-переменные?

> Но, насколько я знаю, теоретические измышления по этому поводу до
> серьёзной практики так и не дошли...
Дошли, в принципе в OpenMP это делается, но для массивов.

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

>> То есть копирование списка как такового не понадобилось.
C>На ленивых списках это бы еще красивее смотрелось. Ты фактически просто
C>строил бы функциональные виды над списком.
Собственно, оттуда вся идея. В случае ленивых языков переформирование производит сам компилятор.

C>Но в моем случае не пойдет — тебе нужно модифицировать не список, а
C>граф. То есть, фактически, имея набор вершин получить список дуг. Так
C>что у тебя нулевой задачей будет пронумеровать вершины в графе, что уже
C>само по себе нетривиально.
Нумерация — это просто часть задачи для списка которую я взял для простейшего примера трансформации. Доступ все-таки происходит не индексный а именно через итераторы. А через итераторы можно выразить обход графа в той же степени, как и списка. Некоторые проблемы могут возникнуть с метками прохода, но они IMHO решаемы.

C>С навигационным доступом тоже будут проблемы — так как после пары-тройки
C>изменений у тебя при каждом обращении оно будет проходить через
C>несколько списков. Кэширование поможет, но тогда уж проще будет
C>скопировать граф.
С навигационным недекларативным доступом — да.

C>Ну и мелочи — графовые алгоритмы часто и так уже сложны, так что как
C>сделать их в виде функциональных итераторов может быть задачей для
C>диссертации.
На 90 процентов алгоритмы — это итераторы прохода через граф.

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

kan>А чем константа отличается от неизменяемой переменной в данном случае?

Тем что константа получает свое значение при компиляции, а не изменяемая перепменная при инициализации (в рантайме).

kan>Объявление константного метода, это по сути приписывание const "скрытой" переменной this. Так что в точности тоже самое.

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

kan>Насчёт распараллеливания не уверен,

Это 100%.