ясное дело->close();
Рекламы и восторгов я и по телеку насмотрюсь...
http://www.rsdn.ru/res/book/net/nagel3.0.xml
Чесно говоря мне этот .Net напоминает попытку мелкософта убежать от собственноручно разведенного невообразимого зоопарка и бардака в своих инструментах..
Смотреть там же, начиная с "Для чего подходит C#".

> Неужели есть критичная разница по скорости что проверять на безопасность свойство или поле?
> И мне казалось что JIT должен работать уже после всех проверок по безопасности.

public поле это просто public, а public свойство это уже private метод, т.е. дополнительная проверка а имеет ли вызывающий код доступ к этому private.
При пересечении стеком вызова границ сборок происходит еще одна проверка,  напрмер используя в программе в цикле список List реализованный в основной библиотеке Framework'а будет постоянная проверка при каждом обращении к его методам, если предварительно скопировать все во временный массив, то проверок в цикле можно избежать.
Ктому же JIT к этому отношение не имеет, т.к. компилит в каждый момент только одну функцию не зная ничего о других. Ведь FIle.Open() может вызывать как код из интернета которому это запрещено, так и опосредством IsolatedStorage, через который это разрешено.

> XML .Net-а всего лишь обёртка к MS XML если я не ошибаюсь.

в .Net она полностью заново написана на C# и стала даже еще быстрее чем MS XML, быстрее я пока не встречал
Впрочем в Qt тоже появился аналогчиный нетовскому QXmlStreamReader

> Ты уверен, что спецификаторы доступа как-то влияют на время выполнения?

Я не знаю насколько именно влияют, но то что проверки идут в рантайме это точно. Ведь на .NET используются и языки которые не проверяют типы/моификаторы доступа, да и хитрый IL-асемблерный код сгенерить на лету всегда можно - так вот вызов таким способом извне приватного метода объекта выдаст Exception. Этим он и отличается от C++, Delphi и прочих обычных языков где код имеет доступ куда только пожелает.

> А если ты таки имеешь в виду, что доступ к полю это просто чтение памяти а доступ к свойству - вызов метода, то как бы, подобные тривиальные методы
> доступа инлайнить умели даже престарелые Delphi ещё до появления .Net.

JIT автоматически инлайнит функции размером не более 32 байт кода, все что больше остаются обычным вызовом. А учитывая как много в исходниках .NET всяких проверок параметров  в теле функций они легко превышают этот рубеж.

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

Я не знаю почему проектировщики .NET выбрали другой метод проверок доступа, наверняка были причины.

> Пусть я что-то загрузил извне, проверил его доступы/разрешения.
> Они что, могут поменяться после подгрузки динамически?

Как ты можешь это проверить в момент загрузки? Как ты можешь быть уверен что код не поменяется по ходу выполнения, ведь код может подгружать новый код, даже на лету в памяти компилить и выполнять C# код можно, не гворя уже о простой прямой генерации нового IL кода.

> Вроде защитники JIT-а утверждали что он может инлайнить и потом оптимизировать через границы сборок.
> Врут?

Между границ обычных сборок да, но когда какая-то сборка устанавливается в GAC (как например самая основная сборка mscorlib), она системой обрабатываются ngen'ом для ускорения их выполнения, при этом они компилятся в нормальный нативный код и сохраняются в кеше. Код такой сборки уже не может быть так просто заинлайнен JIT'ом.

В общем я делал тест, большой список объектов точка Point { double X,Y; }, в цикле значения координат точки увеличиваются на какое-то значение и точка пишется обратно в список,
- в первом случае X,Y свойства вида { get { return x; } set { x = value } } и точки хранятся в List<Point>,
- во втором случае X,Y просто публичные поля и точки хранятся в Point[].
В режиме Release со всеми включенными оптимизациями первый код дольше второго в 3-4 раза (из них в 1.5 раза медленнее это доступ к свойствам X,Y, в 2.5 раза медленнее доступ к индексатору List[]), в режиме Debug и отключенной оптимизации первый код дольше второго в 12 раз! С тех пор у меня все алгоритмы геометрии работают только с подобным типом точек и массивами.

> Доступы ему назначаются 1 раз

Доступы ты можешь запрашивать и изменять динамически из программы.

А какие там факты появились, что то не пойму. Своя IDE появилась? Так сначала бы integration для VS до ума довели бы, а потом о своей IDE думали. Хотя возможно для MacOS/Linux эта IDE и важна.

Кому ненужен, линксоидам?

Is Qt Creator a replacement for Visual Studio?
Qt Creator is not a Visual Studio replacement, but instead a lightweight IDE designed specifically for cross-platform Qt development. We developed Qt Creator to provide our users with options. If a developer is comfortable with Visual Studio, we highly encourage them to continue using it. We will certainly continue to develop and improve our Visual Studio integration.

Это не есть обходимая вещь. Я пишу под вендой в студии, интегратор неюзал ниразу. А зачем он?