Предлагаю не стандартный опросник по .Net
сегодня в 11:53
Предлагаю не совсем стандартный опрос по платформе .Net. Спойлерами раскрыты ответы на вопросы, но все-таки прошу сначала самим ответить на опросник, после чего идти и смотреть ответы :)Когда вызывается статический метод, то JIT… JIT компилирует вызов прокси-метода, который делает безусловный переход на компилятор необходимого и тот заменяет адрес перехода в прокси на новое тело метода. Это делается по нескольким причинам.Изначально, когда методы компилируются, все точки вызова других методов указывают не на скомпилированное тело, а на кусочек ассемблерного кода фиксированной длинны и содержащий одни и те же инструкции для любого метода. По сути меняется только адрес, на который происходит jmp. До того как метод скомпилирован, адрес указывает на компилятор этого метода (потому при первом вызове происходит компиляция). Далее, когда компиляция закончена, аргумент команды jmp меняется с адреса компилятора на адрес целевого, уже скомпилированного метода. Плюсы очевидны: т.к. прокси — содержит одно и те же инструкции, то группу методов можно рассматривать как таблицу с двумя полями: Код и Адрес Перехода с одной стороны и не менять адреса у инструкции вызова метода — с другой.
Что происходит при кастинге к классу Приведение типа к базовому — не происходит ничего, приведение к отнаследованному — для начала проверяется возможность приведения и работа с объектом будет идти по той же таблице виртуальных методов, что и раньшеПриведение к типу — синтаксический сахар языка, который не имеет почти ничего общего на уровне строения объекта в памяти. Поскольку объект состоит из полей + SyncBlockIndex + MethodsTablePtr, где MethodsTablePtr отвечает за указатель на описание типа объекта, то при помещении указателя на объект в переменную другого типа с объектом не происходит ничего (тип объекта же не меняется). Вызывается доп проверка при приведении вверх, т.к. на этапе компиляции заранее не известно, что вверху, какие типы. Необходимо проверить. Проверка осуществляется через уход в таблицу методов и проход по цепочке указателей ParentClassMethodsTable, пока не встретится либо Object (тогда кастинг не возможен) либо пока не встретим указатель, равный тому, который мы ищем. Как осуществляется вызов виртуального метода, хорошо описано тут: Wiki
Что происходит при приведении типа к интерфейсу В таблице типов существует ссылка на словарь интерфейсов и для проверки возможности приведения надо обойти ее всю. По базовым типам идти не надо, т.к. все они также присутствуют в словаре. Если соответствие найдено, в регистр загрузится адрес таблицы виртуальных методов интерфейса, а не типа объектаПоскольку интерфейсы могут появиться в типе прямо посередине наследования как в одном типе, так и в другом, для них общая схема с таблицами виртуальных методов работать не будет. Вместо этого, в таблице виртуальных методов есть ссылка на вторую таблицу — словарь интерфейсов. По сути, это список ссылок на таблицы виртуальных методов каждого из них. При приведении типа осуществляется поиск необходимой таблицы методом бинарного поиска, поскольку поиск осуществляется по равенству указателя на необходимый (среди списка ищется наличие нужного нам указателя на таблицу виртуальных методов). Если он найден, в регистр грузится указатель на эту таблицу и далее вызов метода идет через нее (при этом таблица содержит адреса методов в классе. Потому для каждой имплементации интерфейса список методов присутствует в таблицах всех классов, которые имплементируют интерфейс, а также всех наследниках классов и интерфейсов)
В чем разница между Implicit и Explicit интерфейсами? И те и другие выделены в словарь интерфейсов, однако Explicit методы не находятся в таблице виртуальных методов класса, только в словаре интерфейсовИ действительно, поскольку методы implicit интерфейсов являются частью иерархии наследования класса и могут быть вызваны отдельно от приведения к типу интерфейса, они должны присутствовать в таблице виртуальных методов класса. Однако, есть еще и Explicit реализации, когда методы отделены от класса. Такие методы не присутствуют в таблице виртуальных методов класса. Однако для обоих случаев мы имеем право кастить к интерфейсу и работать через него. А это значит что в карте интерфейсов обоих типов они присутствовать будут, причем вместе со всеми базовыми типами — интерфейсами.
Потоки в .Net являются платформенными потоками MS Windows, потому цена переключения между потоками равна общей цене по WindowsТут, в общем, без комментариев. GC не может встревать в общий процесс обслуживания многопоточного кода. Приложения .Net работают как обычные приложения Windows
Generic типы JIT создает никак не связанные между собой классы под каждый параметр типаПоскольку JIT не может ничего знать о логике приложения, он не может строить доводов что
IEnumerable
Value и Reference типы. В чем разница? Value типы лежат и в стеке и в куче, а Reference — только в куче. Отличаются тем, что value — передаются по значению, а Reference — по ссылкеОгромный процент разработчиков на собеседованиях говорят первый вариант ответа. Причем на самом деле он их не устраивает, поскольку если Value тип является полем класса, в рабочем стеке его значение находиться ну никак не может, поскольку при выходе из метода, который его создал фрейм, его содержащий перестал бы быть валидным с правильными данными. Поле класса (даже если это Value тип) всегда находится в куче. Разница между Value и Ref типами в том, что при копировании у Ref типов копируется ссылка, а у Value — полностью вся структура. Второе отличие: у незабокшенных Value типов отсутствует поле MethodsTable и SyncBlockIndex.
Где лежат статические переменные? Лежат во внутренних массивах и обращение идет по ссылке на массив + индексуЭто просто сакральное знание. Просто сделано так и все.
Как вызываются виртуальные методы? JIT создает для типа таблицу виртуальных методов, через которую идет вызов с заранее подсчитанным индексомПри наследовании и наличии виртуальных методов получается так: от класса к классу они могут только прибавляться в наличии, не пропадая в никуда. причем в каждом последующем классе гарантированно будут присутствовать все методы всех базовых. С одним отличием — при наследовании метод можно переопределить. Потому при построении таблицы методов для какого-то класса, методы базового класса должны находиться по тем же индексам, что и в таблице базового класса. Если метод не переопределен, то и адрес тела метода в таблице будет совпадать с адресом этого метода в таблице базового класса. Если метод переопределен, то значение будет другим. После всех методов базовых классов будут находиться методы ткущего класса. А сам вызов будет происходить так: Загрузить адрес таблицы вирт методов. Сместиться до начала списка методов взять адрес метода по индексу (например) 1 Вызвать его. Причем поскольку при наследовании на этом месте всегда будет находиться метод ToString (), то даже переопределяя его в наследниках, будет вызван именно метод ToString (), только не базового класса, а наследника.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
—
686
24
Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.
