Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ай-яй-яй Определи-ка мне термин "уродство", не сочти за труд.
Куча ненужного кода, необходимость явно описывать и регистрировать сериализуемые классы.
ГВ>А то не дискуссия, а базарная склока получится. Да, и ещё обоснуй употребление предиката "все". А то у меня появляются основания обвинить тебя в неправомерном обобщении.
Здравствуйте, desperado_gmbh, Вы писали:
_>Здравствуйте, Геннадий Васильев, Вы писали:
_>>>Часто даже представления не имею. Грид тоже кто-то должен писать, по волшебству он не появится. О конкретном типе данных в гриде надо вспоминать разве что при форматировании и парсинге. ГВ>>Ну и причём тут rtti? В гриде (если речь идёт о чём-то вроде контрола) данные представляются строковым типом. Следовательно, тебе нужен комплект конвертеров <SQL-тип> -> <строка>. Заметь — даже однонаправленных конвертеров будет вполне достаточно.
_>Все же двунаправленных — данные редактируются. А как будет выглядеть прототип метода конвертера? Шаблонный? А как я вызову из грида нужный конвертер? Сделать столбцы грида шаблонными? А как я создам нужные столбцы, если структура таблицы заранее неизвестна?
Да очень просто. Базовый алфавит тебе известен — набор элементарных типов SQL. Пишешь набор редакторов (по одному для каждого SQL-типа), унаследованных от общего интерфейса с виртуальными функциями и конфигурируешь их набор в зависимости от поступившего набора колонок. Но это не имеет ничего общего с rtti! Это — распознавание входных данных.
ГВ>>Предполагаю, что ты возразишь, что из грида на самом деле потом извлекаются данные для дальнейшей обработки. Я прав?
_>К счастью, нет.
Это приятно слышать.
_>Но в клиентском курсоре обработка действительно нужна, например, индексирование, поиск и вычисляемые столбцы с парсером выражений, содержащих столбцы любого типа.
Снова то же самое, что и выше, только в профиль. Узлы синтаксического дерева (или дерева вычисления выражения) вполне можно сделать по аналогии с редакторами. Да, с большой вероятностью возникает необходимость преобразований типа string-float, float-date и т.п. Прекрасно решается матрицей конвертеров, поскольку базовый набор типов ограничен набором SQL-типов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.
У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.
Здравствуйте, Nose, Вы писали:
N>я имел ввиду, что читать этот код придется не настолько часто, чтобы его сложность представляла собой реальную проблему.
Плохая читаемость кода всегда представляет собой реальную проблему
N>Не так уж часто приходится читать исходники библиотек, да?
Кому как. Написателям библиотек например очень часто приходиться
N>Это не костяк программы, это инструментарий.
Здравствуйте, VladD2, Вы писали:
AVK>>Но это не значит что аналогичный по назначению , но реализованный иначе механизм существовать не может.
VD>К сожалению, твой вариант был более медленныи и совсем неудобным.
Мой вариант делегатов? Ты о чем?
AVK>>Меньше кода, код легче читать.
VD>А счего меньше кода? Куда эти чуда-методы пихать?
Здравствуйте, desperado_gmbh, Вы писали:
_>Здравствуйте, DarkGray, Вы писали:
DG>>А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.
_>У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.
Это связанно с тем, что каждый отдельный obj хранит всю информацию, которая встречалась в данном cpp-ишнике и всех H-ников, которые в него include-ились, что сейчас как раз приводит к раздуванию obj-ей. если бы вместо h-ников были бы obj-и, то тогда можно было просто хранить ссылку на исходный obj, а не компилировать то же самое заново.
Здравствуйте, desperado_gmbh, Вы писали:
_>Здравствуйте, DarkGray, Вы писали:
DG>>А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.
_>У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.
В продолжение, к предыдущему письму.
И на данный момент, конечно, единица трансляции в один cpp-файл, конечно, очень маловато будет.Особенно учитывая, что обычно один класс — один cpp.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да очень просто. Базовый алфавит тебе известен — набор элементарных типов SQL. Пишешь набор редакторов (по одному для каждого SQL-типа), унаследованных от общего интерфейса с виртуальными функциями и конфигурируешь их набор в зависимости от поступившего набора колонок. Но это не имеет ничего общего с rtti! Это — распознавание входных данных.
И формирование выходных данных тоже — после редактирования надо разобрать введенную строку в значение нужного типа и записать его в курсор. В результате свитч все равно остается, но называется все это не rtti, а каким-то другим умным словом. Вместо проверки typeid мы будем проверять какой-то заведенный нами enum. Сейчас у нас в проекте так и сделано. И чем это лучше передачи типа object/variant в функцию форматирования, где внутри стоит свитч по типу?
ГВ>Узлы синтаксического дерева (или дерева вычисления выражения) вполне можно сделать по аналогии с редакторами.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Ай-яй-яй Определи-ка мне термин "уродство", не сочти за труд.
AVK>Куча ненужного кода, необходимость явно описывать и регистрировать сериализуемые классы.
Так бы сразу и сказал. Только объясни, плиз, что это за "ненужный" код?
ГВ>>А то не дискуссия, а базарная склока получится. Да, и ещё обоснуй употребление предиката "все". А то у меня появляются основания обвинить тебя в неправомерном обобщении.
AVK>Все что я видел
Т.е., все реализации, которые ты видел содержали как минимум, кучу ненужного кода? Не верю! (c) Станиславский.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
_>>У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb. DG>Это связанно с тем, что каждый отдельный obj хранит всю информацию, которая встречалась в данном cpp-ишнике и всех H-ников, которые в него include-ились, что сейчас как раз приводит к раздуванию obj-ей.
Я просто неправильно тебя понял. Я полностью с тобой согласен — система раздельной компиляции через obj напрочь устарела, и скомпилированные модули с метаданными рядом с кодом, впервые увиденные мной в турбопаскале, увеличивают скорость компиляции на порядки.
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>Куча ненужного кода, необходимость явно описывать и регистрировать сериализуемые классы.
ГВ>Так бы сразу и сказал. Только объясни, плиз, что это за "ненужный" код?
Описание и регистрация учавствующих классов, а зачастую еще и ручная реализация сериализации для каждого типа.
AVK>>Все что я видел
ГВ>Т.е., все реализации, которые ты видел
Все реализации без RTTI естественно.
ГВ>содержали как минимум, кучу ненужного кода? Не верю! (c) Станиславский.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да очень просто. Базовый алфавит тебе известен — набор элементарных типов SQL. Пишешь набор редакторов (по одному для каждого SQL-типа),
Написание редакторов для каждого типа по твоему правильный дизайн? Мда. А если у источника данных очень большой набор выходных типов и/или он часто меняется? Так и будем клепать редакторы по каждому чиху?
Здравствуйте, DarkGray, Вы писали:
DG>Я против Map-ов, потому что нарушается "атомарность" действий добавления/удаления свойст в классе, т.е. DG>при добавление/удалении свойств, надо постоянно помнить (а также еще их найти, что может быть сложно в случаи того же наследования), что необходимо сделать синхронное изменение в Map-ах
Я тоже.
DG>зы DG>Но ведь так сейчас тоже нельзя сделать: DG>
DG>Угловые скобки указывают, что конструкция в угловых скобках есть только на этапе компиляции.
DG>Ухищрения в стиле Александреску позволяют как-то к этому приблизится, но как же это не удобно, сложно, и не все можно сделать. DG>Не понятно, почему этого нет в самом компиляторе — ему то, это уж точно проще поддержать.
Сделано (только сегодня доделал, кстати "в стиле Александреску" для избавления от возни с DoDataExchange. У каждого класса-наследника ddx::controller генерится функция void ddxExecute(CDataExchange* pDX), вызывающая DDX_ функции для каждого члена (и каждого члена базовых классов). Потом переделаю ее на шаблонную, чтоб только у терминальных классов инстанцировалась. Ну и сериализация появится
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Да очень просто. Базовый алфавит тебе известен — набор элементарных типов SQL. Пишешь набор редакторов (по одному для каждого SQL-типа),
AVK>Написание редакторов для каждого типа по твоему правильный дизайн? Мда.
Оговорился, извиняйте. Вообще-то редактор в смысле стрелочки-буковки-циферки нужен для одного типа — строки. Остальные можно скомпоновать из такого редактора и верификаторов+конвертеров для разных типов. Собственно, такой агрегат я и называл редактором.
AVK>А если у источника данных очень большой набор выходных типов и/или он часто меняется? Так и будем клепать редакторы по каждому чиху?
Пример такого источника можно? А то что-то не верится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Оговорился, извиняйте. Вообще-то редактор в смысле стрелочки-буковки-циферки нужен для одного типа — строки. Остальные можно скомпоновать из такого редактора и верификаторов+конвертеров для разных типов. Собственно, такой агрегат я и называл редактором.
Ладно, едем дальше. Каким образом ты собираешься привязывать верификаторы+конверторы к типам?
ГВ>Пример такого источника можно? А то что-то не верится.
Здравствуйте, desperado_gmbh, Вы писали:
_>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Да очень просто. Базовый алфавит тебе известен — набор элементарных типов SQL. Пишешь набор редакторов (по одному для каждого SQL-типа), унаследованных от общего интерфейса с виртуальными функциями и конфигурируешь их набор в зависимости от поступившего набора колонок. Но это не имеет ничего общего с rtti! Это — распознавание входных данных.
_>И формирование выходных данных тоже — после редактирования надо разобрать введенную строку в значение нужного типа и записать его в курсор. В результате свитч все равно остается,
Где? Цепочка конвертеров вполне избавляет от необходимости свитчей. Свитч по большому счёту нужен только для первичного распознавания SQL-типа, да и то без него можно обойтись списком конвертеров.
_>но называется все это не rtti, а каким-то другим умным словом. Вместо проверки typeid мы будем проверять какой-то заведенный нами enum. Сейчас у нас в проекте так и сделано. И чем это лучше передачи типа object/variant в функцию форматирования, где внутри стоит свитч по типу?
Чем это лучше в вашем проекте — не знаю, но рискну предположить, что enum появился не случайно. Скорее всего вы ограничили набор SQL-типов, сведя, например, char(x), varchar(x) и text в единый тип с набором ограничений.
Хотя, надо сказать, что ты сейчас сравниваешь подход и конкретное решение. При моём подходе общая функция форматирования будет вырожденной, т.е., не содержащей кода форматирования. Последний будет вынесен в отдельные функции, специфические для каждого типа (скорее всего — методы).
Один из плюсов такого подхода — в возможности добавления новых конвертеров без влияния (т.е., — даже без потенциального редактирования!) на код, реализующий общую часть алгоритмов форматирования, например.
ГВ>>Узлы синтаксического дерева (или дерева вычисления выражения) вполне можно сделать по аналогии с редакторами.
_>Да-да. Со свитчами.
Зачем? Можно при распознавании синтаксиса сразу развесить нужные конвертеры. Свитчи снова остаются в области анализа входных данных (парсируемое выражение + набор колонок). Но там без них в общем случае не обойдёшься.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, desperado_gmbh, Вы писали:
_>>>Чтобы проверить, есть ли у свойства нужный атрибут, надо перебрать все атрибуты и попытаться найти среди них атрибут нужного типа. Опять rtti ГВ>>Нет, больше похоже на подмену понятий. Достаточно найти атрибут с нужной сигнатурой, или содержащий нужный символ.
_>У атрибутов в .net еще и поля со значениями бывают. Например, пишем [PermissionSet(SecurityAction.LinkDemand, File="Unrestricted.xml")], и этот файл зачитывается во время компиляции и помещается в код как параметр конструктора класса PermissionSetAttribute. Компилятор, кстати, об этом не знает — он знает, что надо вызвать конструктор PermissionSetAttribute(SecurityAction.LinkDemand), присвоить его свойству File указанное значение, а потом сериализовать получившийся объект прямо в результирующий код, где на рантайме он оживет, когда попросят.
Погоди, к чему ты это? Ну да, я согласен, что ты продемонстрировал неплохой пример решения очень частной задачи. Согласен, что компилятор в .Net используется несколько отличающимся от C++ способом. Но rtti-то тут при чём ? Или ты пытаешься показать способ обхода rtti в .Net?
_>А буковки еще хуже, чем rtti — с классами атрибутов компилятор контролирует, какой класс создается, а сигнатуру можно любую написать. И от проверок и свитчей сигнатуры все равно не избавят.
Ээээ... согласен, да. Сигнатуры — одно из возможных, но не лучшее решение, поскольку в данном случае просто подменяют rtti.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Макросами много чего можно. В твоём примере можно даже строковое задание имён полей убрать и сгенерировать их через #. Но что-то мне помнится Страуструп говорил о макросах и о плохом дизайне
_>И дальше получается та же одна строка.
Дальше получается что макросы мощнее шаблонов
_>Не надо путать написание шаблонов и их использование. Запрещать использовать vector, string, map, sort при работе на c++ — очень странное решение.
Ну ладано-ладно, подловил Хотя глядя на for с трёхэтажными итераторами в C++ и наглядность foreach в C# начинаешь задумываться о смысле жизни.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Где гарантия наличия реализации Save
Вто не надо... с темже успехом можно сказать,а где рарантия что компилятор сгенерирует правильный код? Например в моей текущей практике почти половина ошибок на совести компилятора.(BCB6)
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн