Не понимаю...

На .NET Framework не может быть сделана ОС => эмулировать (интерпретировать) будут именно байт-код, а не API. API останется и никакой эмуляции не будет. И вообще не надо пользоваться API, иначе ваши приложения будут не кросплатформенными.

Кстати, что там с .NET в Linux и в MacOS? Мне кажется воняет мертвичиной. Надо переходить на Java. Там реальная кросплатформенность, а не ее подражание. Чего стоит .NET без нее?

Во-во! Правильно говоришь. Я про енто чудо-юдо МелкоНЕТ уже забыл давно.

Цитата из Рихтера: в далеком будущем планируется, что процессор будет поддерживать IL. ЖУТЬ!

Цитата(Denn @ 1.9.2005, 08:08)

Цитата из Рихтера: в далеком будущем планируется, что процессор будет поддерживать IL. ЖУТЬ!

ИМХО не реально. В IL переменные, а не адреса. ЦП не может оперировать данными в такой абстрактной (относительно) форме.

Цитата(neutrino @ 1.9.2005, 09:30)

ИМХО не реально. В IL переменные, а не адреса. ЦП не может оперировать данными в такой абстрактной (относительно) форме.

Что такое переменная ? Адрес в памяти.

Во-первых,

Цитата(neutrino @ 31.8.2005, 23:30)

На .NET Framework не может быть сделана ОС => эмулировать (интерпретировать) будут именно байт-код, а не API.

Не ну можно было почитать немного прежде чем выражать сомнение и непонимание? Не надо называть IL байт-кодом, потому что

• 1) это разные вещи
• 2) байт-код интерпретируется, IL - компилируется! в native

IL - это не p-code из VB6, который интерпретировался при помощи VBRUNx00.DLL.

Во-вторых,
На .NET framework никто ОС писать не собирается. Вы слышали про такое понятие "уровень абстракции" ? Вы писали бизнес-приложения для платформы Windows, которые бы работали с COM+, SQL Server, BizTalk и другими серверными платформами?

API - метрв. Он не будет расширяться и дорабатываться. Он останется, как режим совместимости для старых программ. MFC, VCL и проч. упрощали работу с WinAPI, за что им большое спасибо. Как сейчас помню программы из тысяч строк кода на C, которые окно отрисовывали и мышкой в нем линии выводить позволяли под Win 3.0.

Нельзя бесконечно тюнинговать Запорожец - рано или поздно это перестанет приносить выгоду. Так же и в программировании.

А решать умозрительные задачи, типа реализовать синглтон без статиков, это пусть на олимпиадах студенты делают, алгоритмизацию свою прокачивают. В реальном мире, где программер зарабатывает созданием бизнес-приложений, это не нужно. Нужно уметь в сроки укладываться и программы стабильные выпускать. Так вот такой уровень абстракции над сервисами ОСи и дает эту возможность.

Вот.

Цитата(arilou @ 1.9.2005, 11:48)

API - метрв. Он не будет расширяться и дорабатываться. Он останется, как режим совместимости для старых программ.

Это возможно, но только не в ближайшем будущем. Для того, чтобы .NET стала действительно стОящей системой, ее еще развивать и вазвивать. Я год пишу под нее и слишком много обнаруживаю недоделок, багов, тормозов... Ждем .NET framework 2.0, можт будет по-лучше.

Цитата(Denn @ 1.9.2005, 13:28)

Я год пишу под нее и слишком много обнаруживаю недоделок, багов, тормозов...

Да ню?
Списочек пожалуйста

Я не говорю, что .НЕТ идеален, но всё-таки пока реальных недостатков я не видел.
Добавлено @ 12:38

Цитата(neutrino @ 1.9.2005, 00:30)

Не понимаю...

Точно подмечено.

Цитата(neutrino @ 1.9.2005, 00:30)

На .NET Framework не может быть сделана ОС => эмулировать (интерпретировать) будут именно байт-код, а не API. API останется и никакой эмуляции не будет. И вообще не надо пользоваться API, иначе ваши приложения будут не кросплатформенными.

У Windows есть такая вещь как ядро, которое выставляет наружу свой интерфейс -- WinAPI.
Теперь интерфейсом к ядру будет .NET.
По-моему, очевидно

Цитата

Списочек пожалуйста

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

Тормозит. MFC очевидно быстрее в большинстве случаев.

В C# нет некоторых вещей - шаблонов, например, вроде как есть 2.0.

Некоторые исключения не ловятся - например, обращение по null указателю иногда продолжает выполнение.


Продолжу позже... Когда всплывет очередное...

Цитата(Denn @ 1.9.2005, 14:27)

Некоторые исключения не ловятся - например, обращение по null указателю иногда продолжает выполнение.

Хмм... Маловероятно.

Единственное, где я видел, что исключения не ловятся вообще -- так это в обработчике событий ActiveX объекта. Помню долго не мог найти этот глюк, а потом пришлось принять как факт.

Цитата(Denn @ 1.9.2005, 14:27)

В C# нет некоторых вещей - шаблонов, например, вроде как есть 2.0.

Вот именно. Будет. Они особо-то и не нужны. Типизированные контейнеры делаются очень легко и без них

Цитата(Denn @ 1.9.2005, 14:27)

Тормозит. MFC очевидно быстрее в большинстве случаев.

Это совсем разные вещи. Нечего сравнивать.

Цитата(Denn @ 1.9.2005, 14:27)

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

Переустанавливаем драйвера рук и головы -- всё будет Ок
Добавлено @ 13:34
По поводу последнего.
Загляни Windows Form Designer Generated Code и посмотри внимательно каким именно способом в .NET создаются формы. Тогда и поймёшь

Цитата

Хмм... Маловероятно.

Что не было такого - отлаживаешь строчка за строчкой, а на строке, где указатель null отладка прерывается и выполнение приложения продолжается?

Цитата

Вот именно. Будет.

Мда ждем...

Цитата

Это совсем разные вещи. Нечего сравнивать.

А почему бы и не сравнить скорость выполнения однотипных приложений?

Цитата

Загляни Windows Form Designer Generated Code и посмотри внимательно каким именно способом в .NET создаются формы. Тогда и поймёшь

Я понимаю как создаются формы. А ты пробовал когда-нить менять этот сгенеренный код? Лучше не пытаться. И не редактировать имена сгенеренных переменных в начале исходника.

Цитата(Denn @ 1.9.2005, 15:31)

Я понимаю как создаются формы. А ты пробовал когда-нить менять этот сгенеренный код? Лучше не пытаться. И не редактировать имена сгенеренных переменных в начале исходника.

А мне это никогда не было нужно
Зачем извращаться-то. Наоборот, я как-то долго матерился, когда увидел, что один из моего проекта вручную отредактировал сгенерённый код.
Вообще надо стараться не злоупотреблять дизайнером форм, а генерировать в рантайме.

Цитата(Denn @ 1.9.2005, 15:31)

А почему бы и не сравнить скорость выполнения однотипных приложений?

Заказчика волнует больше скорость разработки, а не скорость выполнения. Тут MFC нельзя сравнивать с .NET


Что-то мы наоффтопили тут...

Это сообщение отредактировал(а) Дрон - 1.9.2005, 14:40

Цитата(Denn @ 1.9.2005, 13:27)

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

Много раз так делал и никогда не было проблем.

Цитата(Denn @ 1.9.2005, 14:31)

где указатель null отладка прерывается и выполнение приложения продолжается?

Что такое указатель ? Ты имеешь ввиду ссылку? Тож не видел. Скорее всего, сырцы были модифицированы, но не было перекомпиляции.

Цитата(Denn @ 1.9.2005, 14:31)

А ты пробовал когда-нить менять этот сгенеренный код?

А вот этого никогда не стоит делать. На то код и сгенерированный. Если тебе надо что-то поменять в сгенерированном классе - наследуешься от него и меняешь. Вот так вот.

Кстати, и в MFC лезть руками в сгенерированный код - себе дороже выйдет.

Цитата

Заказчика волнует больше скорость разработки, а не скорость выполнения

Согласен.

Цитата(arilou @ 1.9.2005, 16:49)

Много раз так делал и никогда не было проблем.

Это вылазит иногда, если форма нагружена контролами.

Цитата(arilou @ 1.9.2005, 16:49)

Что такое указатель smile ? Ты имеешь ввиду ссылку? Тож не видел. Скорее всего, сырцы были модифицированы, но не было перекомпиляции.

Да, ссылка. Скомпиленные, конечно. В run-time такое видно, как если бы функция не отработала.

Цитата(arilou @ 1.9.2005, 16:49)

А вот этого никогда не стоит делать. На то код и сгенерированный. Если тебе надо что-то поменять в сгенерированном классе - наследуешься от него и меняешь. Вот так вот.

Я знаю, что не надо. А зачем тогда этот код, сгенеренный компилятором, лежит в исходнике? Пусть тогда в .resx будет.

Цитата(Denn @ 1.9.2005, 20:12)

Я знаю, что не надо. А зачем тогда этот код, сгенеренный компилятором, лежит в исходнике? Пусть тогда в .resx будет.

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

Цитата

Что не было такого - отлаживаешь строчка за строчкой, а на строке, где указатель null отладка прерывается и выполнение приложения продолжается?

Если и бывают подобные проблемы - всё дело в том, что в директории с исполняемой программой отсутствуют PDB-файлы для исходников, в которых возникло исключение. Лечится сие выставлением опции "отлавливать все .NET-исключения" (сочетание клавиш Ctrl+Alt+E, поставить красный крестик напротив "Common Language Runtime Exceptions"), и "подкидыванием" pdb-файлов для всех длл-ок в директорию с программой. В этом случае, если уж приаттачишься к процессу - точно не пропустишь ни одного исключения.

З.Ы. приаттачитсья к процессу можно с пом. Ctrl+Alt+P.