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

AVK>Нет, я имел ввиду что не только может управлять этим, но и это управление не сводится к ручному управлению памятью в случае кучи.

А смарт поинтеры на что?

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

AVK>>Нет, я имел ввиду что не только может управлять этим, но и это управление не сводится к ручному управлению памятью в случае кучи.

WH>А смарт поинтеры на что?

А смартпоинтеры это уже заплатка, да и не решают они всех проблем.

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

_>

_>op oper2 = new op(ctl){MyOp(ctl)}; // будет компилиться
_>

Ой, я видимо что-то пропустил.
А что лямбда-функции уже ввели?

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

Для Вас и для VladD2. Мне не очень хочется с вами спорить. У меня не много опыта для этого.
Но. Если вам в руки попадется Александреску, прочитайте. Плохо сосотавлять мнение по чьим-то словам.

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

AVK>А смартпоинтеры это уже заплатка,
Да для тебя все заплатка
AVK>да и не решают они всех проблем.
Всех нет но 99% легко.

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

ГВ>>Да ну? А как же run-time analysis: "Если символ типа — X, то использовать алгоритм Z"? Или мы с тобой подразумеваем под rtti разные вещи.

VD>Ну, да. Ты под ним понимаешь того убогого урода что есть в С++ и для С++ который по своей природе тяготеет к монолитности. А АВК говорит о рефлекшоне который по сравнению с ртти, как Феррари и трехколесный велосипед.

Да, всё верно, но тогда спор получается просто спором о терминах.

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

ГВ>>Ну нет, почему же? Если сопоставление метаинформации реализуется для его дальнейшего использования, то чтение будет удобным. По-моему, это очевидно.

VD>Тогда попробуй предствить, что вся метаинформация делается именно для того, чтобы ее читали.

По-моему, я этого и не отрицал. Это прикольно — приписывать мне отрицание моих собственных взглядов.

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

VD>>>Гарантия в коде универсального сериализатора. Код сериализации автоматически сериализует состояние объектов на основании информации о них.
ГВ>>Да фиг с ней, с сериализацией.
AVK>А, то есть таки сериализация красиво и лаконично без наличия rtti не выходит?

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

AVK>Так как тогда быть с твоими заявлениям про неверный дизайн?

Оно никуда не делось, и я от него не отказываюсь.

ГВ>>Вопрос не в сериализации самой по себе. Предположим, что речь идёт не о сериализации, а о чём-то ещё,
AVK>Не увиливай. Речь идет о сериализации.

Не передёргивай. Речь идёт о подходе, основанном на "самоанализе" программы. Всему своё время, сериализацию ещё вспомним.

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

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

AVK>>>>>Куча ненужного кода, необходимость явно описывать и регистрировать сериализуемые классы.
ГВ>>>>Так бы сразу и сказал. Только объясни, плиз, что это за "ненужный" код?
AVK>>>Описание и регистрация учавствующих классов, а зачастую еще и ручная реализация сериализации для каждого типа.

ГВ>>Упс? А почему этот код — ненужный?

AVK>Потому что можно обойтись без этого.

В дотнете — да. В той системе, для которой были написаны виденные тобой реализации, скорее всего — нет.

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

AVK>>>>>Куча ненужного кода, необходимость явно описывать и регистрировать сериализуемые классы.
ГВ>>>>Так бы сразу и сказал. Только объясни, плиз, что это за "ненужный" код?
AVK>>>Описание и регистрация учавствующих классов, а зачастую еще и ручная реализация сериализации для каждого типа.

ГВ>>Упс? А почему этот код — ненужный?

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

Я говорил о подходе. То, что в частном случае вытряхивание информации о структуре типа полезно — никак не отрицает недостатков RTTI-bases.

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

ГВ>>А я сказал, что это (такой вот тупой маппинг) обязательно надо делать? Это просто прямая альтернатива ручному "программированию" елозеньем мышкой по Object Property-ям. Только и всего. А вообще он вполне сможет сгенериться и по структуре рекордсета.

AVK>О, мы уже до кодогенераторов дошли. Типа рефлекшен это кривой дизайн, а вот кодогенераторы это уже прямой. Самому не смешно?

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

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

Да, если такая функциональность (внесения в мапперы или аналогичная) уже реализована в окружении и попросту дублируется.
Нет, если такой функциональнсти нет. Более того, это почти единственный способ избежать модификации логики, использующий сей маппер. См. по ключевым словам: "Liscov's Substitution Principle". Позицию Лисковой я лично, разделяю.

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

AVK>>>Вот вот, выбор ты как будешь осуществлять и из чего?

ГВ>>"Из чего" — из набора прекомпилированных конвертеров.
AVK>Мда, печальственно

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

AVK>>>Проблема в том что этот самый std::map при наличии rtti не нужен.
ГВ>>Да ну? А как же run-time analysis: "Если символ типа — X, то использовать алгоритм Z"? Или мы с тобой подразумеваем под rtti разные вещи.

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

А что ты будешь делать, если для некоего нового типа данных ещё нет обработчика среди дополнительных сборок?

AVK>>>ОК, если действительно не понимаешь или делаешь вид, то пускай это будет веб-сервис. Так понятнее?
ГВ>>Давай ещё проще — пусть это будет просто SOAP-овский вызов, который возвращает некий массив.
AVK>Не суть важно. Главное что в SOAP набор типов не огранизен каким то узким диапазоном.

OK, я тебя понял. И то, к чему ты упомянул про дополнительные сборки в каталогах программы — тоже. И сразу хочу задать встречный вопрос. А кто напишет для моей программы нужные именно ей конвертеры? Предположим, что речь идёт не о банльной конвертации в строковое представление, а например, в хливких шорьков, метОда использования которых известна только мне. Я позволю себе задать этот вопрос, поскольку спор начинался с общих фраз.

AVK>>>А если сервис не ты писал? А если он изменился?
ГВ>>В каком смысле изменился?
AVK>А вот в таком смысле и изменился — в возвращаемую табличку добавились типы, неизвестные на момент компиляции.

1. Программа выдаст пустые строки или сообщение об ошибке в зависимости от контекста.
2. Я разберусь с тем, что происходит и сделаю Upgrade своей проги.
3. Чтобы избежать п.п. 1 и 2 заключу с разработчиком сервиса соглашение, по которому он будет предупреждать меня о предстоящих изменениях, чтобы наши с ним юзеры не поливали нас грязью.
4. Если п.3 по каким-то причинам невозможен, то постараюсь сократить временой разраыв между 1 и 2.

ГВ>>Я правильно предположил?
AVK>Примерно.

AVK>>>Нет, я имею ввиду что для отображения недетерминированных заранее источников данных rtti очень полезен.
ГВ>>Это тезис понятен.
AVK>Тогда объясни свой тезис о неправильном дизайне при использовании rtti

Всё очень просто. Вот код:

void func(object x)
{
  x.method();
}

На момент компиляции неизветсно — есть у входного x метод "method" или нет. Гарантировать хотя бы его наличие — невозможно (тип — object) . Соответственно, такой код означает следующее:

1. Проверить наличие метода "method" с сигнатурой, совместимой с "void x.method(void)"
2. Если есть, то п.3, иначе - п.4
3. Выбросить исключение.
4. Вызывать метод x.method()
...

Это, в принципе, эквивалентно:

if (x.has_method("void (void)")) x.method(); else throw_exception;

Если сделать небольшую индукцию, то получится, что всё это очень похоже на то, что принято называть "запущенным случаем":

switch(x.get_type_code())
{
  case type_1: x.meth(); break;
  case type_2: x.method(); break;
  ...
  default: throw object_has_no_required_method();
}

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

То, что написано выше я называю "RTTI-based подходом". Возможно, я не совсем прав в выборе термина.

Следствия такого подхода (который я называю в том числе и кривым) нужно описывать? Думаю — нет. Сейчас не хочется просто, но если необходимо — объясню.

В противовес этому сильная типизация исключает фазы анализа x на наличие у него этого метода. Он есть по определению. Остаётся только оверхед на вычисление адреса точки входа по VMT. Но! Само по себе наличие метода гарантируется компилятором. Это, кстати, справедливо и для C++ и для .Net.

И вот что интересно. Тот пример, который ты привёл, по сути, иллюстрирует не RTTI-based подход, а видоизменённый механизм виртуальных функций. Согласен, что .Net добавляет к этому ещё и JIT-компиляцию. Но суть та же самая.

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

ГВ>>Да фиг с ней, с сериализацией. Вопрос не в сериализации самой по себе. Предположим, что речь идёт не о сериализации,
VD>Нет, ну почему же? Это хороший пример демонстрирующий приемущества наличия полноценной информации.

Бесспорно, но не отрицающий недостатков "типоаналитического" подхода в целом.

ГВ>> а о чём-то ещё, что так же, как и сериализация, строится по прнципу вызова специфического кода для каждого поля объекта.
VD>Еще раз повторяю. Отойди от привычный тебе концепций. В дотнете богатство информации о типах позволяет во многих случаях писать универсальный код. В том числе и для сериализации.

Согласен — во многих, что логически (да и жизненно ) верно видоизменить на "в некоторых". Для того, чтобы говорить о "многих", нужно определить "все возможные случаи".

ГВ>> Ну, к примеру, визуализация.
VD>Визуализация слишком абстрактный термин.

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

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

ГВ>>Ну нет, почему же? Если сопоставление метаинформации реализуется для его дальнейшего использования, то чтение будет удобным. По-моему, это очевидно.

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

Это бабушка надвое сказала. Полностью автоматически вся метаинформация всё равно не появится. Тем паче, что C++ позволяет до определённой степени автоматизировать этот процесс.

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

AVK>>А смартпоинтеры это уже заплатка,
WH>Да для тебя все заплатка

Аргумент.

AVK>>да и не решают они всех проблем.
WH>Всех нет но 99% легко.

Циклические ссылки они не отслеживают, а это больше 1%.

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

AVK>>Потому что можно обойтись без этого.

ГВ>В дотнете — да. В той системе, для которой были написаны виденные тобой реализации, скорее всего — нет.

Так как быть с неправильностью rtti?

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

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

Извини, но все равно получается через задний проход.

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

ГВ>А что ты будешь делать, если для некоего нового типа данных ещё нет обработчика среди дополнительных сборок?

Напишу и скомпиляю в отдельную сборку.

ГВ>OK, я тебя понял. И то, к чему ты упомянул про дополнительные сборки в каталогах программы — тоже. И сразу хочу задать встречный вопрос. А кто напишет для моей программы нужные именно ей конвертеры? Предположим, что речь идёт не о банльной конвертации в строковое представление, а например, в хливких шорьков, метОда использования которых известна только мне. Я позволю себе задать этот вопрос, поскольку спор начинался с общих фраз.

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

AVK>>А вот в таком смысле и изменился — в возвращаемую табличку добавились типы, неизвестные на момент компиляции.

ГВ>1. Программа выдаст пустые строки или сообщение об ошибке в зависимости от контекста.
ГВ>2. Я разберусь с тем, что происходит и сделаю Upgrade своей проги.

Причем править придется старый код. А это действительно кривой дизайн.

AVK>>Тогда объясни свой тезис о неправильном дизайне при использовании rtti

ГВ>Всё очень просто. Вот код:

ГВ>То, что написано выше я называю "RTTI-based подходом". Возможно, я не совсем прав в выборе термина.

Ну уж нет, ты не про rtti-based подход говорил, ты говорил просто про использование rtti.

ГВ>Следствия такого подхода (который я называю в том числе и кривым) нужно описывать? Думаю — нет.

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

ГВ>В противовес этому сильная типизация исключает фазы анализа x на наличие у него этого метода. Он есть по определению. Остаётся только оверхед на вычисление адреса точки входа по VMT. Но! Само по себе наличие метода гарантируется компилятором. Это, кстати, справедливо и для C++ и для .Net.

Вот только компилятор не может гарантировать того чего может не знать.

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

AVK>>О, мы уже до кодогенераторов дошли. Типа рефлекшен это кривой дизайн, а вот кодогенераторы это уже прямой. Самому не смешно?

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

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

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

ГВ>Да, если такая функциональность (внесения в мапперы или аналогичная) уже реализована в окружении и попросту дублируется.Нет, если такой функциональнсти нет.

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

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

ГВ>>>Да фиг с ней, с сериализацией. Вопрос не в сериализации самой по себе. Предположим, что речь идёт не о сериализации,
VD>>Нет, ну почему же? Это хороший пример демонстрирующий приемущества наличия полноценной информации.

ГВ>Бесспорно, но не отрицающий недостатков "типоаналитического" подхода в целом.

Недостатки в целом? Извини, но это демагогия. Уже одно то что рефлекшен позволяет в разы упростить сериализацию дает ему право на существование. Естественно что у него, как и у любой технологии, есть свои недостатки, ровно как есть они у шаблонов или МН, но это отнюдь не означает что его применение свидетельствует о кривом дизайне.

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

ГВ>Согласен — во многих, что логически (да и жизненно ) верно видоизменить на "в некоторых".

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

ГВ>Для того, чтобы говорить о "многих", нужно определить "все возможные случаи".

Случаи, встречающиеся мне на практике — так устроит?

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

AVK>>Так как тогда быть с твоими заявлениям про неверный дизайн?

ГВ>Оно никуда не делось, и я от него не отказываюсь.

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

AVK>>Не увиливай. Речь идет о сериализации.

ГВ>Не передёргивай. Речь идёт о подходе, основанном на "самоанализе" программы. Всему своё время, сериализацию ещё вспомним.

Переключение спора на другую тему является демагогией.