Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 [2]  Все   Вниз
  Печать  
Автор Тема: Любопытная фича наследования в C#/CLR  (Прочитано 36108 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #30 : 23-07-2010 10:20 » 

Цитата: Dale
переменная b на самом деле ссылается на тот же экземпляр, что и a. В случае семантики значения мы бы имели копирование значения a в b, после чего это были бы совершенно разные объекты. Думаю, для многих новичков является сюрпризом, когда они обнаруживают, что при изменении a одновременно меняется и b.
Согласен.

Цитата: Dale
В процессе присваивания с самим первоначальным экземпляром ничего не происходит. Поэтому говорить о том, что у данного экземпляра появился еще один тип, не совсем корректно. Появилась лишь ссылка b, значением которой является ссылка на a, преобразованная к типу "ссылка на b".
Похоже, ты меня не понял. Я не говорил "появляется ещё один тип", я говорил "есть ещё один тип" - это устанавливается не во время исполнения, а на уровне семантики исходного кода. С другой стороны, отказывая в множестве типов значению, ты так или иначе переносишь это на ссылки. Каким образом ссылка типа A "сохраняет" в себе факт преобразования к типу B? Если уж обращаться к техническим подробностям реализации, то RTTI хранится не в ссылке, а в самом объекте. И при работе с объектом, когда к нему обращаются через ссылку, не происходит никаких "преобразований" каждый раз, просто структуры объектов разных типов, находящихся в отношении AKO между собой, чисто технически совпадают так, что с A можно работать как с B без всяких преобразований. Именно это я называю множественностью типов у значения (в отличие от единственности типа у переменной).

Цитата: Dale
Эта вся путаница из-за медвежьей услуги с неявным разыменованием ссылок. В кондовом С++ вряд ли кто-нибудь сказал бы, что если A наследует от B, то A - это B, хотя бы по той причине, что нет неявного преобразования A к B. А вот тип указателя на B запросто можно неявно привести к типу указателя на A. Но указатель и то, на что он указывает, там совершенно разные сущности.
Нет, всё равно RTTI хранится в объекте, а не в переменной. Да, в C++ по умолчанию присваивание означает копирование значения за исключением объявления ссылки. Причём ссылка в C++ - это не указатель, так как хранит не адрес, а само значение. Никакого преобразования не происходит.
Код:
A a;
a.m(); // A.M
B &b = a;
b.m(); // A.M - потому что тот же объект
B b1 = a;
b1.m(); // B.M - другой, вновь созданный объект типа B, полученный копированием из a.
В C# для ссылочных типов присваивание работает как для b, а для нессылочных типов - как для b1. И это неочевидно на уровне исходного кода Жаль.

Цитата: x128
По моему всё просто, такая запись:"А а" означает что мы объявляем ссылку на объект типа А или всех его подклассов, а если А - интерфейс то
то объект всех классов которые его реализует. Вот и всё.
Это эквивалентно множественности типов ссылок и единственности типа значения. Такая интерпретация оставлят "за бортом" невиртуальные методы - их выбор определяется типом ссылки, а если типов много, то непонятно, что выбрать. Причём для невиртуальных методов RTTI не используется.

С другой стороны, это моё утверждение можно развернуть наоборот: непонятно, какой из виртуальных методов выборать, если у значения множество типов. Тип значения определяется при конструировании объекта и сохраняется в RTTI. На это я так скажу: значение определяется типом конструктора (технически именно в этот момент заполняется таблица виртуальных функций) - не у значения появляется тип, а появляется значение, соответствующее (тоже чисто технически на уровне общности структуры объекта) одному или более типам (или быть отнесено к нескольким типам, проинтерпретировано разными типами) и содержащее такие методы, которые определяются типом конструктора.
« Последнее редактирование: 23-07-2010 10:26 от Dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #31 : 23-07-2010 10:39 » 

Похоже, ты меня не понял. Я не говорил "появляется ещё один тип", я говорил "есть ещё один тип" - это устанавливается не во время исполнения, а на уровне семантики исходного кода.

Мне кажется, формулировка "экземпляр типа А может быть прозрачно интерпретирован как экземпляр базового типа В" внесла бы меньше путаницы. Тут ни сложностей типа "экземпляр объекта/ссылка на экземпляр объекта/указатель на экземпляр объекта", ни двусмысленности насчет множественности типов, что без подробного истолкования может быть понято превратно. А главное, достаточно близко не только концептуально, но и в части физической реализации.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #32 : 23-07-2010 11:49 » 

Dale, наверно, только выражение "прозрачно проинтерпретирован" тоже неоднозначное Улыбаюсь
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #33 : 23-07-2010 12:01 » 

Скажем так, использован взамен базового без дополнительных действий со стороны программиста и без изменения функциональности. Как-то так.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #34 : 23-07-2010 12:17 » 

Dale, и возникает естественный вопрос: если нужно такое городить с типами, может ну их? Улыбаюсь
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #35 : 23-07-2010 12:54 » 

В смысле совсем ну?

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

Расходимся тихо, по одному, и никому ни слова...
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
baldr
Команда клуба

cy
Offline Offline
Пол: Мужской
Дорогие россияне


WWW
« Ответ #36 : 26-07-2010 08:21 » 

А какое поведение в таком случае будет в C++ и Java?
В плюсах, возможно, повлияет оптимизация в компиляторе, но интересно узнать поведение, всеж...
Записан

Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #37 : 26-07-2010 09:26 » new

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

За Java не скажу, не в курсе.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #38 : 26-07-2010 09:28 » 

baldr, во-первых, C++ имеются заголовочные файлы, изменение которых автоматически влечёт пересборку их использующих частей программы. Во-вторых, в C++ нет понятия assembly. obj- и lib-файлы, собранные с разными версиями h-файла, при сборке могут вызвать недоумение линкера, а в dll ограничения для классов, боюсь, сведут на нет всю эту затею с проверками наследования.

Но самое главное в C++ другое - из-за множественного наследования в нём отсутствуют вызовы типа base и super. Нужно явно указать класс и его метод, который вызывается.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Страниц: 1 [2]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines