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

_>А, действительно и в поле типа T можем. Получается почти как в ATL, но там они еще экономили место под указатель. Совсем как в ATL может быть только с приведением прямо в месте вызова, но компилятор должен быть слишком умным, как я описал.

Кстати, нет физических причин чтобы не сделать такой же оптимизации. Ведь уже на стадии компиляции известно, что текущий this можно привести к T. Просто это уже не хилая оптимизация, которая вряд ли появится в ближайшее время.

Одна надежда на Сан. Если они сделают хорошую (быструю) реализацию балонов в Яве, то МС будет вынуждена заняться оптимизацией и мы еще при жизни увидим такое чуда, как безопасное программирование на Шарпе в стиле ATL.

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

_>Твой десятилетний опыт работы с плюсами должен был подсказать тебе, где ошибка

Так не испоьзуй в таких методах члены-классы и все будет ОК. Сам по себе вызов проблемы не вызовет. По крайней мере по сравнению с виртуальным проблем туочно будет меньше.

Обычно такие приколы в конструкторе нужны только для изменения поведения. Это опасно, но не смертельно. Полностью соотвествует политике С++.

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

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

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

_>Если ошибочный дизайн приводит к более простому и ясному коду, чем правильный, то пора пересмотреть методы оценки дизайна.

Угу, и заодно объявить вечный двигатель легкодостижимым и общедоступным средством. Недостатки Rtti-based подхода абсолютно никуда не деваются от повышения понятности и ясности кода. Если у тебя на C++ распыляется switch(type_id) по нескольким файлам, то аналогичную ситуацию ты получишь и в любом другом аналогичном языке.

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

VD>Одна надежда на Сан. Если они сделают хорошую (быструю) реализацию балонов в Яве, то МС будет вынуждена заняться оптимизацией и мы еще при жизни увидим такое чуда, как безопасное программирование на Шарпе в стиле ATL.

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

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

_>>Если ошибочный дизайн приводит к более простому и ясному коду, чем правильный, то пора пересмотреть методы оценки дизайна.

ГВ>Угу, и заодно объявить вечный двигатель легкодостижимым и общедоступным средством. Недостатки Rtti-based подхода абсолютно никуда не деваются от повышения понятности и ясности кода. Если у тебя на C++ распыляется switch(type_id) по нескольким файлам, то аналогичную ситуацию ты получишь и в любом другом аналогичном языке.

Чем плох вот такой дизайн?

class A
{
void Save(IStream stream)
{
  foreach (Property prop in A.Properties)
    stream.Save(prop);
}
  ...
}

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

ГВ>>Угу, и заодно объявить вечный двигатель легкодостижимым и общедоступным средством. Недостатки Rtti-based подхода абсолютно никуда не деваются от повышения понятности и ясности кода. Если у тебя на C++ распыляется switch(type_id) по нескольким файлам, то аналогичную ситуацию ты получишь и в любом другом аналогичном языке.

DG>Чем плох вот такой дизайн?

DG>

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

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

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

VD>А. Экономия микросикунд...

VD>Может лучше о запросах думать?

О запросах тоже надо думать, но съэкономить микросекунды когда это ничего не стоит имхо тоже имеет смысл.

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

_>У них все еще хуже — они даже не позволяют value-типу быть параметром шаблона. Виртуальная машина не меняется, и шаблоны остаются чисто синтаксической конструкцией. Они не могут поднять производительность,

Ну ты все таки поменьше верь рекламным лозунгам МС. Они не поднимут производительность при работе с value-типами путем отбрасывания боксинга просто потому что там боксинга нет. Все остальные аспекты повышения производительности, применимые к шаблонам С++ точно так же применимы и к дженерикам джавы.

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

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

Ну расскажи тогда как правильно реализовать, к примеру, сериализацию классов.

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

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

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

AVK>Ну расскажи тогда как правильно реализовать, к примеру, сериализацию классов.

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

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

ГВ>Недостатки Rtti-based подхода абсолютно никуда не деваются от повышения понятности и ясности кода.

Есть задачи, явно требующие динамического определения типа, скажем, клиентский курсор. Его внешний интерфейс содержит операции "взять значение" и "положить значение", а также уведомление об изменении значения с возможностью уведомляемого подменить его. От запроса курсор получает типы данных всех столбцов и организует для каждого столбца хранилище, оптимизированное под его тип. Как должен выглядеть интерфейс клиента без rtti или аналогов? По одному методу для каждого типа? А внутренние передачи данных — тоже? Реализация курсора состоит из десятков классов, время от времени обменивающихся значениями полей. Сколько методов придется размножить для каждого типа? Что делать, если захочется поддержать новый тип данных?

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

_>>У них все еще хуже — они даже не позволяют value-типу быть параметром шаблона. Виртуальная машина не меняется, и шаблоны остаются чисто синтаксической конструкцией. Они не могут поднять производительность,
AVK>Ну ты все таки поменьше верь рекламным лозунгам МС. Они не поднимут производительность при работе с value-типами путем отбрасывания боксинга просто потому что там боксинга нет. Все остальные аспекты повышения производительности, применимые к шаблонам С++ точно так же применимы и к дженерикам джавы.

Повышение производительности там если только у труда программиста.

http://www-106.ibm.com/developerworks/java/library/j-djc02113.html

   Hashtable<Integer, String> h = new Hashtable<Integer, String>();

One limitation to type variables in Tiger is that they must be instantiated with reference types -- primitive types won't work. So, in the example above, if we wanted to instead create a Hashtable mapping ints to Strings, we couldn't do it.

That's unfortunate, because it means that you have to wrap primitive types whenever you want to use them as arguments to a generic type. On the other hand, that's no worse than the current situation; you can't pass an int as a key to Hashtable because all keys must be of type Object.

What we'd really like to see would be automatic boxing and unboxing of primitive types, similar to what is done in C# (except better). Unfortunately, Tiger is not scheduled to include autoboxing of primitives (but one can always hope for Java 1.6!).

Good news! After this article was written, autoboxing was added to the Java 1.5 spec!

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

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

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

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

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

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

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

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

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

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

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

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

ГВ>>Недостатки Rtti-based подхода абсолютно никуда не деваются от повышения понятности и ясности кода.

_>Есть задачи, явно требующие динамического определения типа, скажем, клиентский курсор. Его внешний интерфейс содержит операции "взять значение" и "положить значение", а также уведомление об изменении значения с возможностью уведомляемого подменить его. От запроса курсор получает типы данных всех столбцов и организует для каждого столбца хранилище, оптимизированное под его тип. Как должен выглядеть интерфейс клиента без rtti или аналогов? По одному методу для каждого типа? А внутренние передачи данных — тоже? Реализация курсора состоит из десятков классов, время от времени обменивающихся значениями полей. Сколько методов придется размножить для каждого типа? Что делать, если захочется поддержать новый тип данных?

Так... значит, когда ты создаёшь курсор, ты не знаешь, для какого типа данных он создаётся? Т.е., если исходно у тебя что-то вроде:

create table XTable ( ... attr1 int, attr2 varchar(100), ...)

а потом:

select attr1, attr2 from XTable

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

С другой стороны, типы данных SQL-колонок — это внешние по отношению к клиенту данные и их символы находятся вне пространства определения типов C++. А потому распознавание и анализ типов SQL-данных это не rtti, а скорее ближе к распознаванию образов или к банальной проверке входных данных на допустимость. И то и то можно решить без rtti.

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

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

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

ГВ>[...]

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

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

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

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

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

Да не нужны мне мультикасты. Я их за пять минут напишу если будет не мульткаст реализован. А реализации таких приколов можно найти в форуме по С++. Мы где-то год или 1.5 назад обсуждали это дело и там были несколько решений. Мое було как раз на ассемблере, но потом кто-то показал аналог на чистом С++.

Самое смешное, что мой с ассемблером читался даже проще, чем тот второй.

_>На работе я порчу ado.net на плюсы, а дома дизассемблирую windows forms. Шесть наследников IList по 100 строк, у которых отличается максимум треть кода, — это ужасно.

Соласен. Только кто тебе сказал, что они не сгенерированы по шаблону? К тоу-же есть CollectionBase. Наследуйя от него и 90% коллекций будут писаться за пару минут. Типизированную обвязку можно сделать генератором. Хотя конечно бесспорно, что именно для этого шаблоны подходят как нельзя кстати. Тут никто и не сприт. Даже народ не использовавший ранее шаблоны не спорит (ну, за исключением упертых фанатов переписавших на дельфи или Яве). Ну, что же?... будем ждать. А пока и так более менее можно жить.

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

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

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

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

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

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

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

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

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

VD>Соласен. Только кто тебе сказал, что они не сгенерированы по шаблону?

У CheckedListViewItemCollection сначала идет Count, а потом ItemArray, а у SelectedListViewItemCollection — наоборот, сначала SelectedItemArray, а потом Count

VD>К тоу-же есть CollectionBase. Наследуйя от него и 90% коллекций будут писаться за пару минут.

Это те самые остальные 10%. *ListViewItemCollection пользуются *IndexCollection для получения номеров, чтобы потом вытащить сами элементы из ListViewItemCollection.

VD>Типизированную обвязку можно сделать генератором.

Кстати, к msvc 1.0 такой был

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

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

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