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

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

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

Мда, печальственно

AVK>>Проблема в том что этот самый std::map при наличии rtti не нужен.

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

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

AVK>>ОК, если действительно не понимаешь или делаешь вид, то пускай это будет веб-сервис. Так понятнее?

ГВ>Давай ещё проще — пусть это будет просто SOAP-овский вызов, который возвращает некий массив.

Не суть важно. Главное что в SOAP набор типов не огранизен каким то узким диапазоном.

AVK>>А если сервис не ты писал? А если он изменился?

ГВ>В каком смысле изменился?

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

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

Примерно.

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

ГВ>Это тезис понятен.

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

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

ГВ>На каком основании такие предположения? Единственное, что придётся сделать — написать mapping колонок, т.е. — что-то вроде:

ГВ>

ГВ>... = {
ГВ>col_map(0, "Attr1"),
ГВ>col_map(1, "Attr1"),
ГВ>col_map(2, "Attr1"),
ГВ>col_map(-1, "") // Финализатор описания
ГВ>}
ГВ>

И подождать полчасика пока проект пересоберется. Прелесть рефлекшена в том что в этом случае вобще ничего менять не надо.

ГВ>Притом такой маппинг описывать проще, чем прыгать по десяти Property-box-ам. Так что, кто из нас будет что-то-там как папа Карло — ещё не известно.

Не надо никуда низачем прыгать. Нужно просто подложить сборку с обработчиками.

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

ГВ>My God! Да почему?!

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

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

AVK>Здравствуйте, <Аноним>, Вы писали:

AVK>А вот то что "такие" объемы данных передаются клиенту свидетельствует о неверной архитектуре. Клиент, ака пользователь, способен воспринимать данные очень медленно, настолько медленно что даже куча служебной информации не способна сильно увеличить этот объем (мы не говорим конечно об аудио/видеопотоках). И если у тебя 100 тыс. записей отдаются клиенту это явный косяк.

Это оффлайновый клиент. Как ему еще работать?

А>>В этой ветке где-то был разговор про SOAP, так что вот конкретный пример. А передать по низкоскоростному каналу связи лишние несколько метров как-то не хочется.
А>>По моему в RSDN как раз была статься по ручной сереализации dataset для решения этих проблем.

AVK>Это уже совершенно отдельный разговор, к самой идее сериализации не имеющий отношения. Это уже проблемы конкретных особенностей xml, soap и реализации мсовских форматтеров.

Но приходим к тому, что все равно приходится писать ручками. И без всяких rtti, чтобы быстрее. Разве я не прав? Лично я не видел быстрых реализаций с rtti с минимальным объемом выходного файла

Конечно, для некоторых вещей, как например настройки, rtti удобно. Но если я буду заниматься проектьом год, а настройки вместо 2 часов напишу за 2 дня, по моему это не настолько критично.

А>>PS Да, и на моей практике, если менялись типы данных или запросов, то все равно менялась логика, поэтому прелесть определения типов как то падает.

AVK>Опять же следствия недостаточно гибкого дизайна.

may be

Здравствуйте, <Аноним>, Вы писали:

А>Это оффлайновый клиент. Как ему еще работать?

Вот янус чего то 100 тыс записей не таскает.

AVK>>Это уже совершенно отдельный разговор, к самой идее сериализации не имеющий отношения. Это уже проблемы конкретных особенностей xml, soap и реализации мсовских форматтеров.

А>Но приходим к тому, что все равно приходится писать ручками.

Необязательно.

А>И без всяких rtti, чтобы быстрее.

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

А>Разве я не прав? Лично я не видел быстрых реализаций с rtti с минимальным объемом выходного файла

А сколько ты вобще видел реализаций с rtti?

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

AVK>Здравствуйте, <Аноним>, Вы писали:


AVK>Вот янус чего то 100 тыс записей не таскает.

Где возможно, такой объем пережается один раз, а потом делаем обновления. А где нельзя, приходится так

AVK>>>Это уже совершенно отдельный разговор, к самой идее сериализации не имеющий отношения. Это уже проблемы конкретных особенностей xml, soap и реализации мсовских форматтеров.

А>>Но приходим к тому, что все равно приходится писать ручками.

AVK>Необязательно.

А>>И без всяких rtti, чтобы быстрее.

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

Ну не только быстрее, но и меньший объем. Просто не переписпл из предыдущего сообщения

А>>Разве я не прав? Лично я не видел быстрых реализаций с rtti с минимальным объемом выходного файла

AVK>А сколько ты вобще видел реализаций с rtti?

Мало, только .net и java. Поэтому и говорю лишь про свое мнение. Но разговор в ветке проде идет о C#.

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

http://rsdn.ru/ftp/CLI/Generic/Samles/generics.html

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

A>Очень уж эффективным не получится. Остаются виртуальные вызовы, к которым приводит наличие constraints.

Я бы не стал делать выводы до появления бэт. Думаю ребята из МС сейчас и работают над созданием простого и эффективного решения. Что у них получится посмотрим.

A>http://www.google.com/search?q=policy-based+programming&amp;hl=en&amp;lr=&amp;ie=UTF-8&amp;oe=UTF-8&amp;start=10&amp;sa=N.

Ну, это практически равносильно посланию на...

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

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

VD>>Это уже снобизм и шовинизм. Мне почему-то знание С++ не мешает писать на шарпе. Я еще и С знаю. И на нем много писал. Этак мы дойдем, что все кто знают старые зыки на новые уже могзги переглючить не могут.

AVK>Да и сам ты поначалу очень сильно против дотнета возражал, достаточно почитать твои споры с мной и IT на эту тему полуторагодичной давности . А вот у новичков этого нет, они сразу воспринимают особенности шарпа как единственно верные.

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

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

Да уж. Факт извеснейший. Те кто ничего в жизни не видел, и ничего не знает обысно со всем согласны.

Здравствуйте, <Аноним>, Вы писали:

А>Такая сериализация имеет недостатком скорость.

Скорость сериализации в дотнете и в првду плохая. Но дело тут не в универсальности, а в кривой реалзации.

А> Если надо сохранить словарь терминов на 100,000, что например встречается у нас постоянно, все выглядит очень удручающе. Да и объем тоже не воодушевляет.

Согласен. Я собственно первый об этом говорил. Но тем не менее создать универсальную, но быструю реализацию можно.

А>Так что для сохранения настроек такая технология подходит очень хорошо, а для сохранения реальных данных (по крайней мере в моем случае) как то не катит

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

У меня были мысли написать свой универсльный сериализатор. Общая идея такая. На базе рефлекшона генерировать в рантайме оптимальный код сериализации. Если сборка-сериализатор уже есть и ее версия свежая, использовать ее.

Здравствуйте, <Аноним>, Вы писали:

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

Ламерство там было. Шыло на мыло заменялось. Держи действительно шуструю и компактную сераилизацию датасета.

http://www.rsdn.ru/forum/Message.aspx?mid=247335&amp;only=1

Автор: VladD2
Дата: 21.04.03

У меня есть версия которая может писть в бинарный поток прямо из ридера.

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

_>Как он изменится, если мы ставим целью избавиться от object и Type?

Ну, вообще-то было бы разумно сделать типизированные гет-еры/сет-еры. Типа AsInt, AsStr...

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

VD>>А у меня в основном на моей совести.
WH>Просто я научился писать так что большинство логичиских ошибок становятся ошибками компиляции те сводятся на уровень опечаток которые я за ошибки не считаю.

И любиш же ты про свои достижения расказывать.

WH>К стати за VC++7.1 я еще не замечал не верно сгенерированого кода. Так что на нем все мое. Правда и средства контороля выше.

Да, я к тому, что хороший программист не должен сваливать ошибки в програме на компилятор. А неверно сгенерированный код для любого компилятора можно надыбать если поискать как следует. Например, твой любимый VC7.1 прекрасно компилирует вот такой прикол:

void f()
try
{
    printf("try\n");
}
catch(...)
{
}

Я не дока в стандерте С++, но что-то мне подсказывает, что у функции обызаня быть скобки.

VD>У меня были мысли написать свой универсльный сериализатор. Общая идея такая. На базе рефлекшона генерировать в рантайме
оптимальный код сериализации. Если сборка-сериализатор уже есть и ее версия свежая, использовать ее.

Было бы интересно.

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

_>>Как он изменится, если мы ставим целью избавиться от object и Type?
VD>Ну, вообще-то было бы разумно сделать типизированные гет-еры/сет-еры. Типа AsInt, AsStr...

Если говорить про ado.net, то они есть в DataReader, который проектировался для максимальной производительности. С точки зрения надежности и статической типизации Row.AsInt(col1) ничем не лучше Row.GetValue(col1).ToInt() — и там и там при неправильном типе будет ошибка выполнения.

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

VD>void f()
VD>try
VD>{
VD>Я не дока в стандерте С++, но что-то мне подсказывает, что у функции обызаня быть скобки.

Учи матчасть — 15/3. В конструкторах, например, перед скобками происходит инициализация базовых классов, и иногда возникает желание поймать произошедшие там исключения.

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

AVK>Неа. Форматтеры и XmlSerializer вполне могут быть написаны самостоятельно без использования фич clr. Точнее с использованием одной фичи, которая называется рефлекшен.

Уточню. Не могут быть, а именно написаны.

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

S>Что именно тебя тут пугает? Угловые скобки не нравятся, предпочитаешь квадратные?

Попробуй отойти от компьютера... забыть на секунду про все сложности С++... подойди обратно... и ужаснись этим награмождением скобок и знаков приминания.

S>Неправильно понимаешь. Вся генерация кода делается в компил-тайме.

К сожалению я не знаю реализации ТайпЛистов... Ну, да ладно. Это тут непричем.

S>Угу, только у класса TestC есть десяток членов, которые сериализовать не надо.

Помечаешь их одним атрибутом и все.

S> По этому атрибут [Serializable] придется для каждого члена указывать,

Нет. Для отмены есть другой флаг. Да и не все равно это проще, а главное читабельнее.

S> во вторых — для каждого члена, вовлеченного в другие операции (у меня это — DoDataExchange), придется другие атрибуты добавлять. Получится еще страшнее, чем у меня.

Получается красиво и пушисто. Уж точно такой жути в коде не будет.

S>Собственно, код сериализации сидит в библиотеке — в обоих случаях.

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

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

AVK>Атрибут только называется Serializable

Это не важно.

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

AVK>Им надо начинать править не с этого, а с добавления пользовательских value-типов в язык.

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

Здравствуйте, <Аноним>, Вы писали:

А>Это оффлайновый клиент. Как ему еще работать?

Гы. Голлеги.

А>Лично я не видел быстрых реализаций с rtti с минимальным объемом выходного файла

Но это же не значит, что ее нельзя создать?