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

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

_>>>Часто даже представления не имею. Грид тоже кто-то должен писать, по волшебству он не появится. О конкретном типе данных в гриде надо вспоминать разве что при форматировании и парсинге.
ГВ>>Ну и причём тут rtti? В гриде (если речь идёт о чём-то вроде контрола) данные представляются строковым типом. Следовательно, тебе нужен комплект конвертеров <SQL-тип> -> <строка>. Заметь — даже однонаправленных конвертеров будет вполне достаточно.

_>Все же двунаправленных — данные редактируются. А как будет выглядеть прототип метода конвертера? Шаблонный? А как я вызову из грида нужный конвертер? Сделать столбцы грида шаблонными? А как я создам нужные столбцы, если структура таблицы заранее неизвестна?

Да очень просто. Базовый алфавит тебе известен — набор элементарных типов SQL. Пишешь набор редакторов (по одному для каждого SQL-типа), унаследованных от общего интерфейса с виртуальными функциями и конфигурируешь их набор в зависимости от поступившего набора колонок. Но это не имеет ничего общего с rtti! Это — распознавание входных данных.

ГВ>>Предполагаю, что ты возразишь, что из грида на самом деле потом извлекаются данные для дальнейшей обработки. Я прав?

_>К счастью, нет.

Это приятно слышать.

_>Но в клиентском курсоре обработка действительно нужна, например, индексирование, поиск и вычисляемые столбцы с парсером выражений, содержащих столбцы любого типа.

Снова то же самое, что и выше, только в профиль. Узлы синтаксического дерева (или дерева вычисления выражения) вполне можно сделать по аналогии с редакторами. Да, с большой вероятностью возникает необходимость преобразований типа string-float, float-date и т.п. Прекрасно решается матрицей конвертеров, поскольку базовый набор типов ограничен набором SQL-типов.