Здравствуйте, prVovik, Вы писали:
V>Вот именно, я об этом и говорю. Но чем этот подход будет отличаться от const_cast'a? Ну да, чисто с эстетической точки зрения красивее, но суть таже.
Вообще-то const_cast тут вообще ни с какого боку не уперся. Более того, он позволяет нарушить данный контракт. А это уже нарушение принципов типобезопасности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Нет возможности использовать константные ссылки
Здравствуйте, WolfHound, Вы писали:
WH>Вот только AndreiF хочет иметь возможность с одним и темже объектом в одном контексте работать как с изменяемым, а в другом как с не изменяемым. Те мешает мух с котлетами.
Может ты его не так понял? Или он не точно выразился?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Нет возможности использовать константные ссылки
Здравствуйте, VladD2, Вы писали:
WH>>Вот только AndreiF хочет иметь возможность с одним и темже объектом в одном контексте работать как с изменяемым, а в другом как с не изменяемым. Те мешает мух с котлетами. VD>Может ты его не так понял? Или он не точно выразился?
А по моему он явно говорит о плюсовых const те объект в одном месте может быть изменяемым, а в другом (по константной ссылке) не изменяемым.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Нет возможности использовать константные ссылки
GlebZ wrote: > C>Но в моем случае не пойдет — тебе нужно модифицировать не список, а > C>граф. То есть, фактически, имея набор вершин получить список дуг. Так > C>что у тебя нулевой задачей будет пронумеровать вершины в графе, что уже > C>само по себе нетривиально. > Нумерация — это просто часть задачи для списка которую я взял для > простейшего примера трансформации. Доступ все-таки происходит не > индексный а именно через итераторы. А через итераторы можно выразить > обход графа в той же степени, как и списка. Некоторые проблемы могут > возникнуть с метками прохода, но они IMHO решаемы.
Обход графа — это абсолютный мизер. Граф еще надо и модифицировать при
проходе. Я даже не представляю как это в функциональном стиле сделать
(точнее представляю, но с гигантским оверхедом).
> C>С навигационным доступом тоже будут проблемы — так как после пары-тройки > C>изменений у тебя при каждом обращении оно будет проходить через > C>несколько списков. Кэширование поможет, но тогда уж проще будет > C>скопировать граф. > С навигационным недекларативным доступом — да.
С декларативным — тоже.
> C>Ну и мелочи — графовые алгоритмы часто и так уже сложны, так что как > C>сделать их в виде функциональных итераторов может быть задачей для > C>диссертации. > На 90 процентов алгоритмы — это итераторы прохода через граф.
Уууу.... У меня алгоритмы поиска разломов, например, требуют временной
модификации графа для хранения промежуточных результатов. С
многочисленными возвратами и т.п.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
VD>>Может для тебя это и обычно. Я вообще с object-ами не работаю. И для меня это не обычно.
AVK>Это не вопрос того, с чем ты работаешь. Это кусок кода для поддержки компонентной модели дотнета. И тип объекта там на этапе компиляции неизвестен принципиально.
Малоги куски какого унаследованого старья ты где выкопаешь? Это никак не отменяет возможности лично мне использовать типизированный Clone().
VD>>Самое смешное, что коваринтности интерфейсов нет только в Шарпе. Дотнет ее поддерживает. Но в твоем случае это безтолку. Тут дизайн приложения надо менять. Обжекты выбрасывать.
AVK>Ну выброси обжекты в UITypeEditor
Это какая-то аномашия — говорить не в тему.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Малоги куски какого унаследованого старья ты где выкопаешь?
Это не унаследованное старье, это актуальная часть.
VD> Это никак не отменяет возможности лично мне использовать типизированный Clone().
Ты можешь использовать типизированный Clone, только если ты знаешь тип объекта во время компиляции. В случае работы дизайн-тайма дотнета ты этого не знаешь принципиально.
AVK>>Ну выброси обжекты в UITypeEditor
VD>Это какая-то аномашия — говорить не в тему.
Очень даже в тему. Если ты еще не понял — метод EditValue, это из этого класса. Вот теперь и расскажи, как мне написать этот метод используя типизированный Clone, учитывая то, что конкре5тный редактор совсем не обязан быть привязанным к конкретному типу.
Здравствуйте, WolfHound, Вы писали:
WH>Вот только если не делать так как ты говоришь можно и из системы выжать все и не перекомпилировать весь код.
вот только выжимать придется вручную
WH>Нет. В твоей системе придется перекомпилировать вобще все и вобще всегда. Ибо любое изменение кода может повлечь за собой невозможность оптимизации которое цепной реакцией распространиться на всю систему.
И даже код, который от измененного кода никак не зависит?
VladD2 wrote:
> kan>А чем константа отличается от неизменяемой переменной в данном случае? > Тем что константа получает свое значение при компиляции, а не изменяемая > перепменная при инициализации (в рантайме).
Константы времени компиляции в С++ сущность совсем другая, и со словом const они почти никак не связаны.
> kan>Объявление константного метода, это по сути приписывание const > "скрытой" переменной this. Так что в точности тоже самое. > Не совсем. Все же тут гарантируется (должно по крайней мере), инвариант > класса. Плюс по уму должно гарантироваться неизменность и других > объектов. То есть должно гарантироваться отсуствие побочных эффектов.
Понятие побочного эффекта для объекта вещь довольно расплывчатая. Так что спец-конструкцией тут не обойтись.
Смысл const в языке С++ довольно чёткий и вполне однозначный, ничего не перегружено, так что это заблуждение:
const используется для объявления констант, не изменяемых переменных и пометки методов признаком неизменения
состояния объекта. Спорить с этим глупо. Извини, но доказывать тебе очевидные прописные истины у меня времени нет.
А вот когда ты пытаешься выяснять как там "должно по крайней мере" быть — сразу всё плохо становится.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, prVovik, Вы писали:
V>Ну да, ну да, const_cast'ы рулят!
Дались тебе эти конст-касты. Когда я писал на плюсах, мне они были нужны только при вызове WinAPI и ему подобных. Во всех остальных случаях грамотного проектирования и расстановки mutable вполне достаточно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет, не то же самое. Главное отличие того, что предлагается в шарпе, от того, что есть в С++, это местоположение ответственности. В случае плюсового const ответственность несет вызываемая сторона, в случае immutable в шарпе — вызываемая. Говорить о том, какой вариант лучше, вот так навскидку я не берусь. На первый взгляд шарповский вариант все же пологичнее.
Cyberax wrote:
>> > Распараллелить автоматически можно (иногда) только если выполняются >> > одновременно два немутирующих метода. Да и то не всегда. >> Можно один, но много раз. Теоретически можно что-то типа такого: > А если ты из константного метода используешь mutable-переменные?
Вот тут и опаньки — mutable и const_cast портят всю малину, о чём Влад2 и скорбит.
>> Но, насколько я знаю, теоретические измышления по этому поводу до >> серьёзной практики так и не дошли... > Дошли, в принципе в OpenMP это делается, но для массивов.
Насколько эти случаи нетривиальны, что сложно сделать или легко забыть сделать пометки возможности параллелизации в коде
вручную?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Я тоже так и сделал, вот только это очень коряво. Даже если разнести вложенные классы по файлам с помощью частичного определения класса, испещренный типами вида StateMachine<byte>.EpsTransition код оччень напрягает.
В принципе, элементарный typedef помог бы делу, но они даже этого не сделали в C#.
Здравствуйте, AndreiF, Вы писали:
AF>И даже код, который от измененного кода никак не зависит?
В твоей системе зависимоти не предсказуемые. Либой код может привести к перекомпиляции всего. Либо основу придется держать не оптимизированной что есть очень медленно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Но в таком раскладе вернемся к тому, от чего пытались уйти — придется делать две реализации одного и того же метода — типизированную и нетипизированную.
При наличии множественного наследования реализаций — не придется.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Нет возможности использовать константные ссылки
Я не понимаю, где ты нашел смешение мух и котлет в очень простом желании — иметь возможность удостовериться, что определенный метод, куда я передаю свой объект, не сможет его изменить.
Здравствуйте, AndrewVK, Вы писали:
AVK>В шарпе — вызывающая.
Ну на самом деле в случае C++ отвтственность несет ни одна из этих сторон. Ответственность там несет компилятор. Другой вопрос, что в С++ оставили слишком много дырок, которые позволяют все-таки изменить неизменяемое
Ну да, чисто с эстетической точки зрения красивее, но суть таже.
