Там какое-либо время выполнения наверху к только для чтения?
В Swift 2 beta 4 вы можете получить информацию через объект типа:
let className = "\(String.self)" // gives: "Swift.String"
или, если у вас есть экземпляр:
let s = "Hello World"
let className = "\(s.dynamicType)" // gives: "Swift.String"
Вы получите Module.Class результат, например:
Swift.String
ABC.MyGenericClass<Swift.Int>
Достаточно забавно, что возвращаемый объект Type не соответствует протоколу CustomStringConvertible. Следовательно, у него нет свойства 'description', хотя шаблон "" по-прежнему работает правильно.
П.С.: До b4 то же самое можно было бы выполнить с помощью рефлекса (obj.dynamicType) .summary.
3 ответа
Вы должны смотреть на это с той же точки зрения, что и модификаторы доступа. Модификаторы доступа существуют в IL, но действительно ли они являются проверкой во время выполнения? (1) Я не могу напрямую назначать частные поля во время компиляции, (2) Я могу назначать их с помощью отражения. Пока что это не похоже на проверку времени выполнения, вроде только для чтения .
Но давайте рассмотрим модификаторы доступа. Выполните следующие действия:
- Создайте сборку A.dll с открытым классом C
- Создайте сборку B.exe, которая ссылается на A.dll. B.exe использует класс C.
- Создайте две сборки. Запуск B.exe работает нормально.
- Rebuild A. dll, но установите для класса C значение internal. Замените A.dll в каталоге B.exe.
Теперь запуск B.exe вызывает исключение времени выполнения.
Модификаторы доступа также существуют в IL, верно? Так в чем их цель? Цель состоит в том, чтобы другие сборки, которые ссылаются на сборку .Net, должны знать, к чему им разрешен доступ и к чему им не разрешен доступ, как во время компиляции, так и во время выполнения.
Похоже, что Readonly имеет аналогичную цель в IL . Он сообщает другим сборкам, могут ли они писать в поле определенного типа. Однако readonly , похоже, не имеет той же проверки времени выполнения, что и модификаторы доступа в моем примере выше. Кажется, что только чтение - это проверка во время компиляции и не выполняется во время выполнения. Взгляните на пример производительности здесь: Сравнение производительности только для чтения и const .
Опять же, это не означает, что IL бесполезен. IL в первую очередь гарантирует, что ошибка времени компиляции возникнет. Помните, что при сборке вы строите не код, а сборки.
Если вы используете стандартную переменную экземпляра, readonly будет работать почти так же, как обычная переменная. Добавленный IL становится проверкой времени компиляции, но в значительной степени игнорируется во время выполнения.
Если вы используете статический член только для чтения, все немного по-другому ...
Поскольку статический член только для чтения устанавливается во время статический конструктор, JIT «знает», что значение существует. Дополнительной памяти нет - только чтение просто предотвращает установку этого параметра другими методами, но это проверка времени компиляции.
Если JIT знает, что этот член никогда не может измениться, он становится «жестко закодированным» во время выполнения, поэтому конечный результат точно так же, как и значение const. Разница в том, что это займет больше времени в течение самого времени JIT, поскольку компилятору JIT требуется дополнительная работа для жесткого подключения только для чтения ' значение s на место. (Хотя это будет очень быстро.)
Эксперт C ++ / CLI Маркуса Хеги дает достаточно хорошее объяснение этому.
Даже если только чтение действует только во время компиляции, все равно необходимо сохранять данные в сборке (то есть в IL). CLR - это общий язык среда выполнения - классы, написанные на одном языке, могут использоваться и расширяться другими языками.
Поскольку каждый компилятор для CLR не умеет читать и скомпилировать любой другой язык, чтобы сохранить семантику полей только для чтения , эти данные должны храниться в сборке, чтобы компиляторы для других языков уважали их.
Конечно, тот факт, что поле помечено только для чтения означает, что JIT может делать другие вещи, такие как оптимизация (например, встроенное использование значения) и т. д. Независимо от того, что вы использовали отражение для изменения значения поля,