Re[22]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:12
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ай-яй-яй Определи-ка мне термин "уродство", не сочти за труд.


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

ГВ>А то не дискуссия, а базарная склока получится. Да, и ещё обоснуй употребление предиката "все". А то у меня появляются основания обвинить тебя в неправомерном обобщении.


Все что я видел
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[25]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 15:12
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

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


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

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

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


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

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


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


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

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


Снова то же самое, что и выше, только в профиль. Узлы синтаксического дерева (или дерева вычисления выражения) вполне можно сделать по аналогии с редакторами. Да, с большой вероятностью возникает необходимость преобразований типа string-float, float-date и т.п. Прекрасно решается матрицей конвертеров, поскольку базовый набор типов ограничен набором SQL-типов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 15:14
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.


У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:22
Оценка:
Здравствуйте, Nose, Вы писали:

N>я имел ввиду, что читать этот код придется не настолько часто, чтобы его сложность представляла собой реальную проблему.


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

N>Не так уж часто приходится читать исходники библиотек, да?


Кому как. Написателям библиотек например очень часто приходиться

N>Это не костяк программы, это инструментарий.


Инструментарий тоже надо писать и развивать
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[23]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:22
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Но это не значит что аналогичный по назначению , но реализованный иначе механизм существовать не может.


VD>К сожалению, твой вариант был более медленныи и совсем неудобным.


Мой вариант делегатов? Ты о чем?

AVK>>Меньше кода, код легче читать.


VD>А счего меньше кода? Куда эти чуда-методы пихать?


В делегаты
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[22]: Будущее C#
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 03.07.03 15:22
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

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


DG>>А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.


_>У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.


Это связанно с тем, что каждый отдельный obj хранит всю информацию, которая встречалась в данном cpp-ишнике и всех H-ников, которые в него include-ились, что сейчас как раз приводит к раздуванию obj-ей. если бы вместо h-ников были бы obj-и, то тогда можно было просто хранить ссылку на исходный obj, а не компилировать то же самое заново.
Re[22]: Будущее C#
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 03.07.03 15:24
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

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


DG>>А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.


_>У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.



В продолжение, к предыдущему письму.
И на данный момент, конечно, единица трансляции в один cpp-файл, конечно, очень маловато будет.Особенно учитывая, что обычно один класс — один cpp.
Re[26]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 15:24
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


И формирование выходных данных тоже — после редактирования надо разобрать введенную строку в значение нужного типа и записать его в курсор. В результате свитч все равно остается, но называется все это не rtti, а каким-то другим умным словом. Вместо проверки typeid мы будем проверять какой-то заведенный нами enum. Сейчас у нас в проекте так и сделано. И чем это лучше передачи типа object/variant в функцию форматирования, где внутри стоит свитч по типу?

ГВ>Узлы синтаксического дерева (или дерева вычисления выражения) вполне можно сделать по аналогии с редакторами.


Да-да. Со свитчами.
Re[23]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 15:24
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


ГВ>>Ай-яй-яй Определи-ка мне термин "уродство", не сочти за труд.


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


Так бы сразу и сказал. Только объясни, плиз, что это за "ненужный" код?

ГВ>>А то не дискуссия, а базарная склока получится. Да, и ещё обоснуй употребление предиката "все". А то у меня появляются основания обвинить тебя в неправомерном обобщении.


AVK>Все что я видел


Т.е., все реализации, которые ты видел содержали как минимум, кучу ненужного кода? Не верю! (c) Станиславский.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 15:27
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

_>>У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.

DG>Это связанно с тем, что каждый отдельный obj хранит всю информацию, которая встречалась в данном cpp-ишнике и всех H-ников, которые в него include-ились, что сейчас как раз приводит к раздуванию obj-ей.

Я просто неправильно тебя понял. Я полностью с тобой согласен — система раздельной компиляции через obj напрочь устарела, и скомпилированные модули с метаданными рядом с кодом, впервые увиденные мной в турбопаскале, увеличивают скорость компиляции на порядки.
Re[24]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:31
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>Так бы сразу и сказал. Только объясни, плиз, что это за "ненужный" код?


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

AVK>>Все что я видел


ГВ>Т.е., все реализации, которые ты видел


Все реализации без RTTI естественно.

ГВ>содержали как минимум, кучу ненужного кода? Не верю! (c) Станиславский.


Твое право
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[26]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:40
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


Написание редакторов для каждого типа по твоему правильный дизайн? Мда. А если у источника данных очень большой набор выходных типов и/или он часто меняется? Так и будем клепать редакторы по каждому чиху?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[25]: Будущее C#
От: Sergey Россия  
Дата: 03.07.03 15:47
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>Я против Map-ов, потому что нарушается "атомарность" действий добавления/удаления свойст в классе, т.е.

DG>при добавление/удалении свойств, надо постоянно помнить (а также еще их найти, что может быть сложно в случаи того же наследования), что необходимо сделать синхронное изменение в Map-ах

Я тоже.

DG>зы

DG>Но ведь так сейчас тоже нельзя сделать:
DG>
DG>class A
DG>{
DG>  int A;
DG>  string B;
DG>  double C;
DG>  Properties <PropsForSave>()
DG>  {
DG>    return <list>{A.A, A.C};
DG>  }
DG>  void Save(IStream stream)
DG>  {
DG>     <foreach> (Property <prop> in <PropsForSave)
DG>       stream.Save(<prop>.Name);
DG>  }
DG>} 
DG>

DG>Угловые скобки указывают, что конструкция в угловых скобках есть только на этапе компиляции.


DG>Ухищрения в стиле Александреску позволяют как-то к этому приблизится, но как же это не удобно, сложно, и не все можно сделать.

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

Вот такой стиль устраивает?

class TestA : public ddx::controller<TestA, Loki::NullType>, public CDialog
{
    typedef ddx::controller<derived_type, base_type> parent_t;
protected:
    typedef ddx::member<CString, IDC_SERVER, Ser, &DDX_CBString> m_Server;
    typedef ddx::member<CString, IDC_PROCESS_NAME, Ser, &DDX_Text> m_ProcessName;
    typedef ddx::members<TYPELIST_2(m_Server, m_ProcessName)> members_info;
public:
    TestA(CWnd *wnd) {}
    members_info ddxMembers;
};

class TestC : public ddx::controller<TestC, TestA>
{
    typedef ddx::controller<derived_type, base_type> parent_t;
protected:
    typedef ddx::members<Loki::NullType> members_info;
public:
    TestC(CWnd *wnd) : parent_t(wnd) {}
    members_info ddxMembers;
};

class TestB : public ddx::controller<TestB, TestC>
{
    typedef ddx::controller<derived_type, base_type> parent_t;
protected:
    typedef ddx::member<BOOL, IDC_CREATEMM, Ser, &DDX_Check> m_CreateMM;
    typedef ddx::members<TYPELIST_1(m_CreateMM)> members_info;
public:
    TestB(CWnd *wnd) : parent_t(wnd) {}
    members_info ddxMembers;
};


Сделано (только сегодня доделал, кстати "в стиле Александреску" для избавления от возни с DoDataExchange. У каждого класса-наследника ddx::controller генерится функция void ddxExecute(CDataExchange* pDX), вызывающая DDX_ функции для каждого члена (и каждого члена базовых классов). Потом переделаю ее на шаблонную, чтоб только у терминальных классов инстанцировалась. Ну и сериализация появится
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[27]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 16:02
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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


AVK>Написание редакторов для каждого типа по твоему правильный дизайн? Мда.


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

AVK>А если у источника данных очень большой набор выходных типов и/или он часто меняется? Так и будем клепать редакторы по каждому чиху?


Пример такого источника можно? А то что-то не верится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 16:11
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


Ладно, едем дальше. Каким образом ты собираешься привязывать верификаторы+конверторы к типам?

ГВ>Пример такого источника можно? А то что-то не верится.


SOAP
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[27]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 16:18
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

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


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


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


Где? Цепочка конвертеров вполне избавляет от необходимости свитчей. Свитч по большому счёту нужен только для первичного распознавания SQL-типа, да и то без него можно обойтись списком конвертеров.

_>но называется все это не rtti, а каким-то другим умным словом. Вместо проверки typeid мы будем проверять какой-то заведенный нами enum. Сейчас у нас в проекте так и сделано. И чем это лучше передачи типа object/variant в функцию форматирования, где внутри стоит свитч по типу?


Чем это лучше в вашем проекте — не знаю, но рискну предположить, что enum появился не случайно. Скорее всего вы ограничили набор SQL-типов, сведя, например, char(x), varchar(x) и text в единый тип с набором ограничений.

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

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

ГВ>>Узлы синтаксического дерева (или дерева вычисления выражения) вполне можно сделать по аналогии с редакторами.


_>Да-да. Со свитчами.


Зачем? Можно при распознавании синтаксиса сразу развесить нужные конвертеры. Свитчи снова остаются в области анализа входных данных (парсируемое выражение + набор колонок). Но там без них в общем случае не обойдёшься.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Будущее C#
От: mihailik Украина  
Дата: 03.07.03 16:22
Оценка: :)
AVK>>Что то последнее время больше не по делу.

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


Не, генерики и баста. Хорошенько понемножку.

Слишком большая гибкость только вредит. Ртуть вон гибче глины, зато из неё фигурки не лепятся.
... << RSDN@Home 1.1 beta 1 >>
Re[27]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 16:26
Оценка:
Здравствуйте, 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.: Винодельческие провинции — это есть рулез!
Re[24]: Будущее C#
От: IT Россия linq2db.com
Дата: 03.07.03 16:30
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Кривыми затычками — можно.




_>REGISTER_CLASS("CategoryInfo", CategoryInfo)
_>  REGISTER_MEMBER("CategoryID", CategoryID)
_>  REGISTER_MEMBER("CategoryName", CategoryName)
_>  REGISTER_MEMBER("Count", Count)
_>END_REGISTER_CLASS()


Макросами много чего можно. В твоём примере можно даже строковое задание имён полей убрать и сгенерировать их через #. Но что-то мне помнится Страуструп говорил о макросах и о плохом дизайне

_>И дальше получается та же одна строка.


Дальше получается что макросы мощнее шаблонов

_>Не надо путать написание шаблонов и их использование. Запрещать использовать vector, string, map, sort при работе на c++ — очень странное решение.


Ну ладано-ладно, подловил Хотя глядя на for с трёхэтажными итераторами в C++ и наглядность foreach в C# начинаешь задумываться о смысле жизни.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Будущее C#
От: WolfHound  
Дата: 03.07.03 16:33
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Где гарантия наличия реализации Save

Вто не надо... с темже успехом можно сказать,а где рарантия что компилятор сгенерирует правильный код? Например в моей текущей практике почти половина ошибок на совести компилятора.(BCB6)
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.