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

_>Integer — это и есть забоксенный int.

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

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

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

ГВ>>Где гарантия наличия реализации Save (или адекватности его генерации) для всех членов A.Properties?
ГВ>> Или скажем так, чем гарантируется, что при введении 501-го типа Property система не начнёт слетать в одном случае из сотни?

DG>Я тебя понял, т.е. ты за максимум проверки корректности на этапе компиляции? Я прав?

Да, ты прав.

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

DG>

DG>class A
DG>{
DG>void Save (IStream stream)
DG>{
DG>  template_foreach(Property prop in A.Properties)
DG>     stream.Save(prop.Name);
DG>}
DG>}
DG>

DG>где template_foreach — конструкция, которая разбирается компилятором на этапе компиляции, и приводит к следующему внутреннему коду:

DG>

DG>void Save (IStream stream)
DG>{
DG>  stream.Save(a);
DG>  stream.Save(b);
DG>}
DG>

DG>А этот код уже проверяется компилятором.

DG>Сейчас этого нет, что и приводит к ужасным констркуциям Begin_Map/MapElement/End_Map.

В принципе — да, но я бы не стал обобщать, что Begin_Map/... — единственный возможный способ реализации списка полей для класса. И не стал бы утверждать, что сериализация должна всегда выполняться для всех полей экземпляра.

Я клоню к тому, что A.Properties на самом деле должен быть неким Ax.Properties, где Ax.Properties есть подмножество A.Properties. Выделить это подмножество можно атрибутами свойств или заведением дополнительных классов-"фильтров" (здравствуй, Begin_Map, на правда ли?). Так что, при ближайшем рассмотрении твой пример становится не очень убедительным.

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

_>>Integer — это и есть забоксенный int.
AVK>Боксить тока надо ручками.

В 1.5 уже не надо будет.

AVK>Что же касается перфоманса, то в отличие от С++ и джава и дотнет должны производить кастинг в рантайме даже для совместимых типов, поскольку неясно что тебе в итоге могут подсунуть, поэтому шаблоны избавляют от определенной части этого кастинга и тем самым увеличивают эффективность полиморфных алгоритмов.

Если только чуть-чуть. В отсутствие множественного наследования для проверки возможности кастинга, если кастят не к интерфейсу (а это бывает часто), достаточно пробежаться по цепочке предков испытуемого объекта и попытаться найти нужный тип. А нормальные коллекции value-типов, поднимающие производительность гораздо сильнее, джаве не светят.

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

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

ГВ>>Хорошо, расскажу (оформлю как код, хотя здесь уже где-то пробегали реализации), но вот при чём тут rtti?..

AVK>Потому что все реализации без rtti выглядят как уроды.

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

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

ГВ>Я клоню к тому, что A.Properties на самом деле должен быть неким Ax.Properties, где Ax.Properties есть подмножество A.Properties. Выделить это подмножество можно атрибутами свойств или заведением дополнительных классов-"фильтров" (здравствуй, Begin_Map, на правда ли?).

Или здравствуй, .NET

Чтобы проверить, есть ли у свойства нужный атрибут, надо перебрать все атрибуты и попытаться найти среди них атрибут нужного типа. Опять rtti

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

_>Как это не будет? Все тот же gyro/docs/generics/csharp.html:

Ну, тем лучше.

_>Вот явной полной или частичной специализации действительно не будет.

А вот это не факт. Все из МС в один голос заявляют, что МС-Ресерч и МС две большие разницы. И что реализация дженириков на шарпе не не будет копией gyro.

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

AVK>А про совершенство никто и не говорил. Но вопли то вроде того что шарп полная туфта по сравнению с С++.

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

AVK>Что то последнее время больше не по делу.

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

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

VD>>Легко. Компилируются даже шаблонные навароты ATL-я.
AVK>Нет, gc-классы не могут использовать МН.

А причем тут gc-классы? Классы это не код. Классы это данные. Да данные могут быть менеджед только если помечены как __gc или __value. Но код все равно будет менеджед.

VD>>Не путаю. IL == managed.
AVK>Ничего подобного. Цитата из MSDN
AVK>

AVK>Compilers and tools expose the runtime's functionality and enable you to write code that benefits from this managed execution environment. Code that you develop with a language compiler that targets the runtime is called managed code; it benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.

И где здесь написано обратное? А вот тебе другая цитата:

What is managed code and managed data?
Managed code is code that is written to target the services of the common language runtime (see What is the Common Language Runtime?). In order to target these services, the code must provide a minimum level of information (metadata) to the runtime. All C#, Visual Basic .NET, and JScript .NET code is managed by default. Visual Studio .NET C++ code is not managed by default, but the compiler can produce managed code by specifying a command-line switch (/CLR).

Короче, это спор о терминах. Анменеджед его точно назвать нельзя. Так как он компилируется в МСИЛ, требует CLR для исполнения и пердоставляет методанные.

AVK>Слабо сделать класс с МН, чтобы его можно было использовать из C# или VB.NET?

Еще раз. Есть менеджед-код, а есть менеджед-данные. Сделать класс методы котороко компилируютсяв в менеджед код и который поддерживает множественное наследование ничего не стоит.

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

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

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

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

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

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

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

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

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

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

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

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


DG>>Сейчас этого нет, что и приводит к ужасным констркуциям Begin_Map/MapElement/End_Map.

ГВ>В принципе — да, но я бы не стал обобщать, что Begin_Map/... — единственный возможный способ реализации списка полей для класса. И не стал бы утверждать, что сериализация должна всегда выполняться для всех полей экземпляра.

ГВ>Я клоню к тому, что A.Properties на самом деле должен быть неким Ax.Properties, где Ax.Properties есть подмножество A.Properties. Выделить это подмножество можно атрибутами свойств или заведением дополнительных классов-"фильтров" (здравствуй, Begin_Map, на правда ли?). Так что, при ближайшем рассмотрении твой пример становится не очень убедительным.


Пусть будет так:

class A
{
  [Не сохранять]
  int A;  
  [Сохранить]
  string B;
  void Save (IStream stream)
  {
    template_foreach (prop in Select * From A.Properties where Сохранить is presence)
      stream.Save(prop.Name);
  }
}

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

зы
Но ведь так сейчас тоже нельзя сделать:

class A
{
  int A;
  string B;
  double C;
  Properties <PropsForSave>()
  {
    return <list>{A.A, A.C};
  }
  void Save(IStream stream)
  {
     <foreach> (Property <prop> in <PropsForSave)
       stream.Save(<prop>.Name);
  }
}

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

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

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

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

N>>Да, код кажется ужасным. Но этот код _не_ предназначен для того, чтобы его читали.

VD> Я плякаль...

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

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

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

ГВ>>Они сознательно ограничивали его рассмотрение. И ИМХО, совершенно разумно, поскольку необходимость "самоанализа" (он же — rtti) в сущности, является ошибкой дизайна.

K_O>На самом деле, RTTI нужен не столько программистам, пишущим на C++ (хотя есть некоторые задачи, где RTTI ну оччень бы пригодился), сколько самому компилятору С++. Если бы в объектные файлы помещалась информация о типах, то компилятору при компиляции каждого cpp-файла не приходилось бы обрабатывать сотни килобайт исходного кода, которые вставляются через #include.

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

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

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

ГВ>>Я клоню к тому, что A.Properties на самом деле должен быть неким Ax.Properties, где Ax.Properties есть подмножество A.Properties. Выделить это подмножество можно атрибутами свойств или заведением дополнительных классов-"фильтров" (здравствуй, Begin_Map, на правда ли?).

_>Или здравствуй, .NET

Ну, это в примитивном обобщении.

_>Чтобы проверить, есть ли у свойства нужный атрибут, надо перебрать все атрибуты и попытаться найти среди них атрибут нужного типа. Опять rtti

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

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

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



AVK> Можешь напечатать на большом листе и повесить на стену.
Уж увольте. Склерозом не страдаю, а посему записки самому себе не пишу.

Я ответил, что я имел ввиду в соседнем сообщении.

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

K_O>>На самом деле, RTTI нужен не столько программистам, пишущим на C++ (хотя есть некоторые задачи, где RTTI ну оччень бы пригодился), сколько самому компилятору С++. Если бы в объектные файлы помещалась информация о типах, то компилятору при компиляции каждого cpp-файла не приходилось бы обрабатывать сотни килобайт исходного кода, которые вставляются через #include.

ГВ>Ну, в общем — да, это было бы поудобней в чём-то, чем исходники, но тогда объектники (и библиотеки, кстати, тоже!) тащили бы груду лишней информации о тех же шаблонах. Хорошо это или плохо... трудно сказать. Мне, по крайней мере.

А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.
Единственная проблема в том, что надо как-то стандартизовать, менять и т.д. формат информации в obj-е, но тут мог помочь xml.

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

_>>Чтобы проверить, есть ли у свойства нужный атрибут, надо перебрать все атрибуты и попытаться найти среди них атрибут нужного типа. Опять rtti
ГВ>Нет, больше похоже на подмену понятий. Достаточно найти атрибут с нужной сигнатурой, или содержащий нужный символ.

У атрибутов в .net еще и поля со значениями бывают. Например, пишем [PermissionSet(SecurityAction.LinkDemand, File="Unrestricted.xml")], и этот файл зачитывается во время компиляции и помещается в код как параметр конструктора класса PermissionSetAttribute. Компилятор, кстати, об этом не знает — он знает, что надо вызвать конструктор PermissionSetAttribute(SecurityAction.LinkDemand), присвоить его свойству File указанное значение, а потом сериализовать получившийся объект прямо в результирующий код, где на рантайме он оживет, когда попросят.

А буковки еще хуже, чем rtti — с классами атрибутов компилятор контролирует, какой класс создается, а сигнатуру можно любую написать. И от проверок и свитчей сигнатуры все равно не избавят.

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

AVK>>Что то последнее время больше не по делу.

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

Соглашусь

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

VD>А причем тут gc-классы? Классы это не код. Классы это данные.

+ код

VD>Короче, это спор о терминах.

Хорошо, пускай о терминах, но это ты его начал.
Тем не менее, возвращаясь к исходному спору, если мы хотим чтобы компоненты, писанные на МС++ использовались в других языках дотнета, то вынужденны лишиться возможности использовать некоторый набор фич.

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

ГВ>Ну, в общем — да, это было бы поудобней в чём-то, чем исходники, но тогда объектники (и библиотеки, кстати, тоже!) тащили бы груду лишней информации о тех же шаблонах.

Лучше один шаблон, чем куча классов, построенных на его основе.