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

AVK>>С чем сравнивал?

VD>С собственными тестами. В прочем, ты должен был и сам догадаться.

Я догадался, потому и спрашивал. В твоих тестах не было с чем XmlSerializer сравнивать. SoapFormatter и DataSet были явно медленнее в разы, а сравнивать с бинарными сериализаторами текстовый глупо.

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

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

AVK>>Термин RTTI имеет ровно одно значение — RunTime Type Information, т.е. информация о типах во время ваыполнения.

VD>Вот ксатати, именно по этому мне этот термин не нравится. Дотнетный рефлекшон доступен еще на дизайн-тайме.

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

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

ГВ>Просто я считаю особенности RTTI-based дизайна очевидными.

Ну считай. Не надо только говорить что использование информации о типах это безусловно кривой дизайн.

AVK>>Хорошо, уточню формулировку — неизвестных типов дотнета.

ГВ>OK, но откуда они там возьмутся? Либо это дотнетовские, а значит — известные типы,

Вот когда С++ научится распознавать хотя бы свои собственные типы в рантайме из чужих модулей тогда и поговорим. А пока плюсовые шаблоны даже такого не обеспечивают.

AVK>>Значит ты влез не в тему, потому что в начальном топике имелся ввиду именно рефлекшен в целом. Не веришь — можешь у Влада уточнить. Я тебе гарантирую что твое понятие rtti он точно не имел ввиду.

ГВ>Знаешь, я вот думаю сейчас, а не поспешно ли я признал, что reflection и rtti — разные вещи...

Правильно думаешь. Рефлекшен это дальнейшее развитие rtti, по сути rtti доведенный до ума, так чтобы им можно было пользоваться.

ГВ>Нет проблем. Ты приписываешь мне категоричное утверждение — "использование рефлекшена = кривой дизайн".

Я не приписываю, оно так и есть. Или ты уже от своих слов отказываешься?

ГВ>снова повторяю характерные черты RTTI-based-дизайна,

Зачем? У тебя про твой придуманный термин никто ничего и не спрашивал. Речь шла про рефлекшен в шарпе, и отсутствие онного к С++ если ты еще не понял.

ГВ>поскольку они могут присутствовать при использовании информации из reflection. Т.е. я просто смягчаю категоричность, которую ты мне упорно навязываешь

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

ГВ>и пытаюсь обратить твоё внимание на очевидный, ИМХО, факт.

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

AVK>>То есть, памятуя о контексте твоего высказывания, ты все таки не прав.

ГВ>Хех, если с использованием reflection можно добиться чистого LSP-compliant, то Reflection <> RTTI, если нельзя, то увы: Reflection=RTTI и я ошибся, сказав, что это разные вещи.

Твои приравнивания просто не правомерны. Рефлекшен — это технология, RTTI это принцип. Сравнивать их нельзя.

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

AVK>>Объясни тогда пожалуйста почему рефлекшен это не RTTI? Что еще предоставляет рефлекшен окромя информации о типах?

VD>Вообще-то он предостовляет механизм динамического вызова.

Это тот же самый RTTI.

VD> Ну, и еще в дотнете есть средства генерации метаданных, да и кода.

Про эмит я сразу оговорился что его не учитываем.

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

VD>>Нда. Атрибуты — это средства расширения метаинформации. И атрибуты всегда ассоциируются с метаданными классов/методов. К объектам же они отношения не имеют.

ГВ>Да ну?

Именно что не имеют. Объекты там возникают только в момент их чтения, как удобная оболочка для доступа к ним. До этого атрибуты совершенно необъектная сущность. Просто в дотнете их постарались максимально закрыть классами для упрощения работы с ними. Однако некоторые атрибуты вобще как правило ввиде объектов не создаются, например атрибуты Flags, DllImport.

ГВ>Интересно, VC-шный class browser вероятно не предоставляет информации о классах в период разработки? Странно...

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

ГВ>С другой стороны, reflection имеет ещё кучу отличий от rtti.

Рефлекшен это и есть rtti дотнета.

VD>>Ты снова судишь с позиции С++. А АВК говорит с позиции чистого термина. То что rtti в С++ — это убогий уродец с тобой никто не спорит. Но сама концепция равитая в дургих средах/языках от этого хуже не становится.

ГВ>Может быть и так. Но от свойственных ей недостатков (sorry — особенностей ) как оверхед (всегда) + ненадёжность (почти всегда) она от этого не избавляется.

Ну и что? Исходя из этого его не стоит применять?

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

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

AVK>>Ваши нагромождения шаблонов превращают плюсы в птичий язык.

VD>Ну, это ты зря. Если шаблонами пользоваться умело и по месту,

Ключевая фраза. По месту. А вот если не по месту а для затычки дырок языка то куча вложенных шаблонов никаких положительных эмоций не вызывает.

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

ГВ>>>Так о том-то и речь, что пока библиотеки хватает, — всё вокруг ништяк. А шаг влево, шаг вправо...
AVK>>Какой библиотеки?

ГВ>Библиотеки Framework-а.

Рефлекшен это свойство CLR, библиотека используется для доступа к нему.

AVK>>Ну и что? Грамотный дизайн априори считает что атрибутов нет и используются они только в тех случаях когда надо изменить стандартное поведение. Нет атрибута значит алгоритм отработает штатно.

ГВ>Поздравляю. Это и есть первейший признак RTTI-based дизайна. "Если есть нечто, влияющее на алгоритм..." И это ты называешь "грамотным дизайном"? По идее алгоритм всегда работает штатно, выполняясь на адаптированных для него сущностях. Да, отдельные сегменты могут варьироваться в зависимости от сущностей, но эти сегменты предоставляются самими сущностями (см. — виртуальные функции). Но сам факт выполнения этих сегментов не зависит от характера сущности или же, в случае, если он не нужен, может оптимизироваться компилятором.

Смысл твоей фразы? Чего хоть сказать хотел?

ГВ>1. Атрибуты могут быть применены, но они не могут быть обязательно применены

Зависит от компилятора.

ГВ> (если не подмешивается наследование от класса, у которого определён атрибут)

А если подмешивается?

ГВ>2. Если алгоритм предполагает поиск атрибута => условность, то это уже не LSP-дизайн, => близок к кривому...

То есть все что не соответствует какому то варианту, который тебе нравится то кривое?

ГВ>Хммм... получается, что...

Получается что ты опять не хочешь признать что помимо С++ есть что то еще.

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

WH>

WH>Если, прочитав материал, посвященный спискам типов, вы не свалились со стула, значит, вы сидели на полу.

WH>Scott Meyers

WH>

WH>Что нового можно сказать о языке С++, Оказывается, очень много.

WH>John Vlissides

WH>

WH>Современное проектирование на С++ — важная книга. По существу, "обобщенные шаблоны", или "шаблонные шаблоны", в ней представлены как новый мощный метод гибкого проектирования на языке С++ — новый способ комбинирования шаблонных классов и шаблонов поектирования, о котором мы и мечтать не могли. Если вы проектируете и программируете на языке С++, вам следует прочесть эту книгу. Очень рекомендую...

WH>Herb Sutter

Можно продолжить?

Кофе Гранд лучший кофе ...
Какой то известный актер советского кино

Вода Архыз ...
Армен Джигарханян

Циркониевые браслеты ...

Сок Чемпион ...

Продолжать?

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

S>Это не ерунда. Это фундаментальная проблема дизайна этих системи. Их не так много.
S>Еще раз: нет способа закрыть методы!

Что значит "закрыть методы"?

S>Ну вот смотри: Есть у нас класс Date. У него есть как геттеры, так и сеттеры. Если ты сделашь его сеттеры интернал, то он будет практически иммутабл.

А так оно для DateTime и есть.

S> И что дальше? Где ты собрался его использовать?

Обыкновенно.

S>В каждой сборке будет свой класс Date?

Зачем? Один на всех.

[skipped]

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

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

ГВ>>Интересно, VC-шный class browser вероятно не предоставляет информации о классах в период разработки? Странно...

VD>Он использует отладочную БД. Можешь обвыключаться rtti, а он все равно будет работать.

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

VD>Ага. В общем, оно говорит о грамотной реализации и удобстве в использовании.

Кстати, а VisualAssist по этому критерию чем не подходит? Большая часть того, чем он занимается — это предоставляет информацию о типах в design-time

VD>Все твои предложения по замене рефлекшона строились на том, что ты изобретал свою метаинформацию и анализировал ее. Это не будет быстрее чем анализ штантной метаинформации.

IMHO, в плюсах правильным (в том числе идеологически правильным ) было бы иметь полную метаинформацию о типах во время компиляции, и при необходимости вытаскивать ее в рантайм традиционным плюсовым путем — с помощью библиотек (ну и библиотека для этого нужны бы была стандартная). Я б тогда midl куда подальше закинул...

ГВ>>+ ненадёжность (почти всегда) она от этого не избавляется.

VD>Ну, а вот это твое глубокое заблуждение. Практика показывает обратное. Решения реализованные на метаинформации обычно надежнее лобового кодирования.

Вот тут ты прав на все сто.

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

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

VD>В общем, борость с метаинформацией и алгоритмами ее использующими так же бессмысленно как нелюбить Пушкина в нашей стране.

Да никто с ней в плюсах не борется. Ее, наоборот, всем не хватает Посмотри, хотя бы, на boost::mpl, если уж Александреску читать не хочешь.

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

VD>Я тебе скажу так. Хотя синтаксис шаблонов в С++ меня полностью устраивает. Но в общем и целом я согласен с АВК. Читать исходники на С++ намного сложнее чем на Шарпе.

Смотря какие исходники . Мы-то про вполне конкретный пример кода говорили, который, на мой взгляд, одинаково прост хоть на плюсах, хоть на шарпе.
А вообще, конечно, да — но это потому, что на С++ можно некоторые более сложные вещи записать меньшим объемом кода. Тут прямая аналогия с сервер-сайд скриптом, генерирующим клиентский скрипт — понимать его труднее, чем просто клиентский скрипт. Программа, выполняемая компилятором, генерирующая программу на "бесшаблонном С++", часто выглядит сложнее, чем код на "бесшаблонном С++", расписанный для всех требуемых случаев. Вот только пользоваться такой программой обычно довольно просто, особенно если она имеет грамотный интерфейс.

VD>А эмуляций остуствущей в функциональности на шаблонах еще больше усугубляет это положение.

Есть такое дело. Хотя если эту функциональность прятать в библиотеку с удобным интерфейсом, получается очень даже читабельно. Взять тот же boost::bind — внутри сущий кошмар, снаружи — лепота.

VD>На плюсах последий раз неделю назад. Вообще написал на них радимых кучу кода. А читать приходилось вообще ороменные листинги.

А это я не тебя спрашивал. У тебя знаний С++ поболее, тебе и вопросы другие Например, когда ты впервые узнал, что на плюсах можно посчитать факториал в компил-тайме? И сколько раз писал рекурсивные шаблоны? Но это так, в порядке подколки Книжку Александреску прочитать тебе не зря советовали.

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

S>Если мы унаследуемся вот так:
S>MyDate — >MyConstDate — > Date — >ConstDate
S>то MyConstDate получит в подарок неконстантный интерфейс. Упс.

Почемуто у меня создаётся устойчивое впечатление, что в этой ветке не доливают...

Здравствуйте, IT, Вы писали:
IT>Почемуто у меня создаётся устойчивое впечатление, что в этой ветке не доливают...
Перечитал 8 раз. Ниче не понял.

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

AVK>Можно продолжить?

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

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

WH>Не правомерное сравнение. За рекламу люди получают деньги

А ты думаешь товарищи, которые разрешили публиковать свои комментарии на обложке книжки сделали это бесплатно?

WH>при чем не рискуя своей профессиональной репутацией.

Не уверен что не рискуя.

WH>В данном случае я сильно сомневаюсь что ктото из них получил что либо,

Зря сомневаешься.

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

AVK>>>Ну и что? Грамотный дизайн априори считает что атрибутов нет и используются они только в тех случаях когда надо изменить стандартное поведение. Нет атрибута значит алгоритм отработает штатно.
ГВ>>Поздравляю. Это и есть первейший признак RTTI-based дизайна. "Если есть нечто, влияющее на алгоритм..." И это ты называешь "грамотным дизайном"? По идее алгоритм всегда работает штатно, выполняясь на адаптированных для него сущностях. Да, отдельные сегменты могут варьироваться в зависимости от сущностей, но эти сегменты предоставляются самими сущностями (см. — виртуальные функции). Но сам факт выполнения этих сегментов не зависит от характера сущности или же, в случае, если он не нужен, может оптимизироваться компилятором.
AVK>Смысл твоей фразы? Чего хоть сказать хотел?

А то ты не понял?

Имеем некую функцию.

"НЕграмотный дизайн":

void SomeFunc(SomeClass *pObj1, SomeOther *pObj2)
{
  SomeValue Value;
  if (typeid(*pObj) == typeid(SomeDerivedClass))
    { Value = pObj1 -> GetSomeValue2(); }
  else
    { Value = pObj1 -> GetSomeValue(); }
    
  pObj2 -> DoMethod(Value);
}

Суть в том, что дизайн здесь нужно изменить так, чтобы убрать if (typeid(*pObj) == typeid(SomeDerivedClass)), например, введя дополнительный метод в класс SomeClass, специально для использования в функции SomeFunc:

"грамотный дизайн":

void SomeFunc(SomeClass *pObj1, SomeOther *pObj2)
{
  SomeValue Value;
  Value = pObj1 -> GetSomeValueOfSomeFunc();
  pObj2 -> DoMethod(Value);
}

ГВ>>1. Атрибуты могут быть применены, но они не могут быть обязательно применены
AVK>Зависит от компилятора.

В смысле?

ГВ>> (если не подмешивается наследование от класса, у которого определён атрибут)
AVK>А если подмешивается?

Тогда мы имеем случай исправления RTTI-based дизайна средствами поддержки полиморфизма.

ГВ>>2. Если алгоритм предполагает поиск атрибута => условность, то это уже не LSP-дизайн, => близок к кривому...
AVK>То есть все что не соответствует какому то варианту, который тебе нравится то кривое?

Почему именно "мне нравится"? Не надо сводить всё к вкусовым предпочтениям. Это вполне объективная оценка определённых характеристик дизайна.

ГВ>>Хммм... получается, что...
AVK>Получается что ты опять не хочешь признать что помимо С++ есть что то еще.

Нет, я имею ввиду не это.

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

ГВ>А то ты не понял?

Нет. Потому и спросил.

ГВ>Имеем некую функцию.

ГВ>"НЕграмотный дизайн":
ГВ>

ГВ>void SomeFunc(SomeClass *pObj1, SomeOther *pObj2)
ГВ>{
ГВ>  SomeValue Value;
ГВ>  if (typeid(*pObj) == typeid(SomeDerivedClass))
ГВ>    { Value = pObj1 -> GetSomeValue2(); }
ГВ>  else
ГВ>    { Value = pObj1 -> GetSomeValue(); }
    
ГВ>  pObj2 -> DoMethod(Value);
ГВ>}
ГВ>

ГВ>Суть в том, что дизайн здесь нужно изменить так, чтобы убрать if (typeid(*pObj) == typeid(SomeDerivedClass))

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

ГВ>>>1. Атрибуты могут быть применены, но они не могут быть обязательно применены
AVK>>Зависит от компилятора.

ГВ>В смысле?

В смысле тот же компилятор шарпа кое какие атрибуты контроллирует при разработке.

AVK>>То есть все что не соответствует какому то варианту, который тебе нравится то кривое?

ГВ>Почему именно "мне нравится"?

Ну а как еще объяснить то что ты считаешь единственно верным только тот вариант дизайна который тебе известен? Опять твои суждения выглядят как — вот это рулез, а остальное кривота.

ГВ>Не надо сводить всё к вкусовым предпочтениям. Это вполне объективная оценка определённых характеристик дизайна.

Пока что я никаких аргументов твоих оценок не слышал.

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

ГВ>>Просто я считаю особенности RTTI-based дизайна очевидными.
AVK>Ну считай. Не надо только говорить что использование информации о типах это безусловно кривой дизайн.

Хорошо, я готов заменить определение "...в сущности является ошибкой дизайна." как двусмысленное на "...провоцирует на дизайн, который влечёт за собой неоправданную потерю быстродействия и снижение надёжности, поскольку контроль целостности перекладывается на время исполнения."

И что от этого изменилось?

AVK>>>Хорошо, уточню формулировку — неизвестных типов дотнета.
ГВ>>OK, но откуда они там возьмутся? Либо это дотнетовские, а значит — известные типы,
AVK>Вот когда С++ научится распознавать хотя бы свои собственные типы в рантайме из чужих модулей тогда и поговорим. А пока плюсовые шаблоны даже такого не обеспечивают.

Образно выражаясь, плюсовые шаблоны "направлены" не в сторону runtime-распознавания типов, а в сторону "исключения ситуации" распознаывания.

AVK>>>Значит ты влез не в тему, потому что в начальном топике имелся ввиду именно рефлекшен в целом. Не веришь — можешь у Влада уточнить. Я тебе гарантирую что твое понятие rtti он точно не имел ввиду.
ГВ>>Знаешь, я вот думаю сейчас, а не поспешно ли я признал, что reflection и rtti — разные вещи...
AVK>Правильно думаешь. Рефлекшен это дальнейшее развитие rtti, по сути rtti доведенный до ума, так чтобы им можно было пользоваться.

Хм

ГВ>>Нет проблем. Ты приписываешь мне категоричное утверждение — "использование рефлекшена = кривой дизайн".
AVK>Я не приписываю, оно так и есть. Или ты уже от своих слов отказываешься?

Не отказываюсь. Просто они не означают того, что ты думаешь.

ГВ>>снова повторяю характерные черты RTTI-based-дизайна,
AVK>Зачем? У тебя про твой придуманный термин никто ничего и не спрашивал. Речь шла про рефлекшен в шарпе, и отсутствие онного к С++ если ты еще не понял.

Угу, и ещё о том, что отсутствие рефлекшена в C++ — его чудовищный недостаток. Я тоже считаю, что у C++ есть недостатки, но отсутствие рефлекшена в дотнетовском исполнении к ним не отношу.

ГВ>>поскольку они могут присутствовать при использовании информации из reflection. Т.е. я просто смягчаю категоричность, которую ты мне упорно навязываешь
AVK>Я тебе ничего не навязываю, я тебя цитирую. Уж извини, но никакими приемами ты не докажешь что твоя абсолютно односмысленная фраза выражала что то совсем другое.

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

ГВ>>и пытаюсь обратить твоё внимание на очевидный, ИМХО, факт.
AVK>Нет, ты пытаешься отмазаться от своих же слов. Надо уметь признавать свою неправоту. Ничего плохого в том что ты оказался неправ нет. Все мы не идеальны.

Бесспорно.

AVK>>>То есть, памятуя о контексте твоего высказывания, ты все таки не прав.
ГВ>>Хех, если с использованием reflection можно добиться чистого LSP-compliant, то Reflection <> RTTI, если нельзя, то увы: Reflection=RTTI и я ошибся, сказав, что это разные вещи.
AVK>Твои приравнивания просто не правомерны. Рефлекшен — это технология, RTTI это принцип. Сравнивать их нельзя.

Но тем не менее:

AVK>Правильно думаешь. Рефлекшен это дальнейшее развитие rtti, по сути rtti доведенный до ума, так чтобы им можно было пользоваться.

Т.е., рефлекшен реализует rtti. Да, не только C++-rtti, да, более развитую модель, но последствия его активного использования тем не менее остаются теми же самыми, что и при использовании C++-rtti.

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

AVK>>Зачем? У тебя про твой придуманный термин никто ничего и не спрашивал. Речь шла про рефлекшен в шарпе, и отсутствие онного к С++ если ты еще не понял.
ГВ>Угу, и ещё о том, что отсутствие рефлекшена в C++ — его чудовищный недостаток. Я тоже считаю, что у C++ есть недостатки, но отсутствие рефлекшена в дотнетовском исполнении к ним не отношу.
А я отношу. Пусть не к чудовищьнам но к серьезным точно.

ГВ>Т.е., рефлекшен реализует rtti. Да, не только C++-rtti, да, более развитую модель, но последствия его активного использования тем не менее остаются теми же самыми, что и при использовании C++-rtti.
А может просветишь? В моем проекте я очень активно использую rtti и ни каких проблем не вижу. Система быстро растет как функциональнось движка так и колличество длл. Причем в основном по тому что движок не знает о конкретных длл и длл не знают что есть в движке и других длл но могут легко выяснить есть то что им надо или нет.

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

AVK>Ты упускаешь важный момент — закрытие сеттеров отнюдь не означает отсутствие публичных конструкторов, которые устанавливают все необходимые поля.
Допустим есть у тебя какой то массив ты хочешь его кому то дать почитать и при этом быть спокойным что этот кто то его не изменит. Ы?