Интересно было бы услышать действительно исчерпывающий ответ.
Что это за платформа?
Для чего предназначена?
Что такое .NET Framework?
Отличия от Windows 95/98/Me/NT/2k/XP
На чем писать?
Работают ли приложения написанные в VS.NET на системе, где нет .NET и .NET Framework?
Заранее спасибо.
С уважением, Алексей
23.10.03 11:19: Перенесено модератором из '.NET' — TK
Re: Что такое .NET
От:
Аноним
Дата:
26.09.03 12:24
Оценка:
Здравствуйте, Столетний Алексей, Вы писали:
СА>Интересно было бы услышать действительно исчерпывающий ответ.
исчерпывающий ответ в форуме ???
об этом уже КНИГИ написаны
их список (достаточно большой) можешь найти поиском
Книги — книгами, а вкратце:
СА>Интересно было бы услышать действительно исчерпывающий ответ.
Это вряд ли, сам на нем сижу всего 2 недели
СА>Что это за платформа? СА>Для чего предназначена?
Вообщем идея такая — одна IDE для любого языка. Для этого специально есть некий стандарт (IDL). Выбираешь язык и используя .NET Framework runtime (кажись) пишешь проги. Что-то вроде того, как ты пишешь проги под winAPI или еще какую-нибудь либу, только много удобств, задумок, ну и должно быть глюков (а значит ждем патчей от microsoft).
СА>Что такое .NET Framework?
Это набор библиотек (только они как-то по другому зовутся, но как говориться "лопата — она и в африке лопата"). По всей видимости он реализован для всевозможных платформ (например у меня под 98 начал уникод рисоваться! правда, к сожалению, не всех контролах, но мне понравилось), его обязательно дистибутировать со своими приложениями (плюс кристал рэпорт, джет и т.д. — смотря что ты используешь), но я думаю — это не проблемая, в крайнем случае — кормишь юзера урл-ями, где это все лежит..
СА>Отличия от Windows 95/98/Me/NT/2k/XP
Да это не совсем операционка, как бы, но она использует свой формат exe (вроде бы) и управляет динамически подключением сборок, которые ты используешь (что-то вроде com или ole). FrameWork ставится под все вышеперечисленное и отлично работает.
СА>На чем писать?
На том языке, на котором ты писал раньше. Хотя я не знаю, где взять паскаль, но наверное где-то можно. А лучше — выбери C#, помесь C++,VB и явы.. симпатичная надо сказать.. особенно мне нравится динамическое выделение памяти.
СА>Работают ли приложения написанные в VS.NET на системе, где нет .NET и .NET Framework?
Нет однозначно, другой формат exe, как я уже говорил. Но инсталлянт FrameWork (по крайней мере тот, что у меня) занимет всего 20 Мб.
Вообщем это лучшее, что есть из того, что 1) доступно, 2) документировано, 3) будет развиваться..
Здравствуйте, Sinatr, Вы писали:
СА>>Что это за платформа? СА>>Для чего предназначена?
S>Вообщем идея такая — одна IDE для любого языка. Для этого специально есть некий стандарт (IDL). Выбираешь язык и используя .NET Framework runtime (кажись) пишешь проги. Что-то вроде того, как ты пишешь проги под winAPI или еще какую-нибудь либу, только много удобств, задумок, ну и должно быть глюков (а значит ждем патчей от microsoft).
1. Не иде, а среда выполнения.
2. Не идл, а мсил
СА>>Отличия от Windows 95/98/Me/NT/2k/XP
S>Да это не совсем операционка, как бы, но она использует свой формат exe (вроде бы) и управляет динамически подключением сборок, которые ты используешь (что-то вроде com или ole). FrameWork ставится под все вышеперечисленное и отлично работает.
3. Как бы е совсем свой формат exe.
4. Кажется официально под вынь 95 не ставится.
СА>>На чем писать?
S>На том языке, на котором ты писал раньше. Хотя я не знаю, где взять паскаль, но наверное где-то можно. А лучше — выбери C#, помесь C++,VB и явы.. симпатичная надо сказать.. особенно мне нравится динамическое выделение памяти.
5. Увы, выделения динамического можно сказать что нет. Но есть динамическая сборка.
СА>>Работают ли приложения написанные в VS.NET на системе, где нет .NET и .NET Framework?
S>Нет однозначно, другой формат exe, как я уже говорил. Но инсталлянт FrameWork (по крайней мере тот, что у меня) занимет всего 20 Мб.
6. Формат не другой, но фреймворк однозначно нужен.
Привет!
L>5. Увы, выделения динамического можно сказать что нет. Но есть динамическая сборка.
Как же так? В до-диезе вообще нет delete! Одни new — получается, что динамическое выделение..
S>>Нет однозначно, другой формат exe, как я уже говорил. Но инсталлянт FrameWork (по крайней мере тот, что у меня) занимет всего 20 Мб. L>6. Формат не другой, но фреймворк однозначно нужен.
Другой! Настолько же, насколько PE отличается от MZ Ну заглушка есть, но дальше вызывается фрейворковский..ммм.. менеджер? и уже от его лица продолжается загрузка, линковка и даже выполнение (частично)..
Здравствуйте, Sinatr, Вы писали:
S>Как же так? В до-диезе вообще нет delete! Одни new — получается, что динамическое выделение..
Динамическое -- это когда оно само делает. Если ты вызываешь new -- то уже не днамическое.
S>Другой! Настолько же, насколько PE отличается от MZ Ну заглушка есть, но дальше вызывается фрейворковский..ммм.. менеджер? и уже от его лица продолжается загрузка, линковка и даже выполнение (частично)..
Да не другой.
Far.exe : MZP -- это фар
BA.exe : MZР -- это Net-овское приоложение.
Здравствуйте, Столетний Алексей, Вы писали:
СА>Интересно было бы услышать действительно исчерпывающий ответ. СА>Что это за платформа? СА>Для чего предназначена? СА>Что такое .NET Framework? СА>Отличия от Windows 95/98/Me/NT/2k/XP СА>На чем писать? СА>Работают ли приложения написанные в VS.NET на системе, где нет .NET и .NET Framework?
Почитай http://www.gotdotnet.ru/default.aspx?s=doc&d_no=32&c_no=10
Это API и компонеты для работы в среде .NET Framework полностью использующие ООП (только классы). Это целый мир. Вин Апи и все иже с ними и рядом нестояло.
Основные отличия
1. GC сборщик мусора и сним проблемы старого мышления.
2. Так как происходит компиляция на этапе загрузки программы, компиляция происходит с учетом архитектуры процессора. Динамическое создание классов и их использование.
3. Огромные возможности RTTI.
4. Защита, и отсутствие Ада DLL.
5. Продумманная иерархия классов и структур.
Итд,итп
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>1. GC сборщик мусора и сним проблемы старого мышления. S>2. Так как происходит компиляция на этапе загрузки программы, компиляция происходит с учетом архитектуры процессора. Динамическое создание классов и их использование.
Ну это ты загнул по поводу архитектуры процессора. Может компилиться, а де-факто --
S>3. Огромные возможности RTTI. S>4. Защита, и отсутствие Ада DLL.
Я бы сказал возможность избежать его.
S>5. Продумманная иерархия классов и структур. S> Итд,итп
Здравствуйте, Lloyd, Вы писали:
L>Ну это ты загнул по поводу архитектуры процессора. Может компилиться, а де-факто --
"Вы можете откомпилировать IL в native код определенного компьютера, и при запуске вы уже не будете иметь надстройки в виде JIT компиляции. Мы также предоставляем вам возможность запускать и компилировать код динамически — JIT компиляция. И конечно, присутствие IL добавляет возможностей, например, допустимость переноса на разные архитектуры процессора и предоставление проверки во время типовой защищенности, а далее построение системы безопасности поверх всего этого. "
"Для небольшой платформы у нас есть EconoJIT, мы назвали его так, потому что это очень простой JIT [Прим. ред.: .NET Compact — это подмножество среды .NET, созданная для переноса на другие устройства и платформы.]. Для desctop версии мы создали более полный JIT, и у нас есть даже JIT, который дает такие же результаты как наш C++ компилятор. Так как он требует больше времени, вы могли бы использовать его во время установки ПО. "
Это достаточно старая сиатья. Но лиха беда начала. Главное есть возможность и производители процессоров в этом очень заинтересованы оссобенно когда на горизонте уже появились многоядерные процессоры . Век Native компиляторов уходит в Лету. В конце года появится Net под линукс.
и солнце б утром не вставало, когда бы не было меня
Что-то эта ветка напомин мне разговор и "того самого Мюнхаузена" где товарищи обсуждали какие подвги совершил Мюнхаузен: "Да нет стрелял он не в оленя, а в утку, но через печную трубу...".
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А как насчет МС++? Тоже менеджед, а ведь и без классов прекрасно работает?
S> Вин Апи и все иже с ними и рядом нестояло.
А ничего, что он на этом АПИ основан? И что позволяет его взывать?
S>Основные отличия S>1. GC сборщик мусора и сним проблемы старого мышления.
Ну, еще проблемы детерменированной финализации.
S>2. Так как происходит компиляция на этапе загрузки программы, компиляция происходит с учетом архитектуры процессора. Динамическое создание классов и их использование.
Ну, есть ngen да и что называть динамической загрузкой...
S>3. Огромные возможности RTTI.
Да и не RTTI — это. Все же в RTTI R — это рантайм. А информацию о типмх в дотнете можно читать и не будучи в рантайме.
S>4. Защита, и отсутствие Ада DLL.
Гы. Кудаж он денется то? Тут-та он. По проще стало. Но всегда можно на старые грабли нарваться.
S>5. Продумманная иерархия классов и структур.
Иногда не до конца.
S> Итд,итп
Вот именно. И-т-д.
Так дотнет описать тяжело. Тут нужно или здоровую статью делать, или сказать в двуъ словах: большая библиотека, великолепный рантайм, удобные и простые сзыки, множество языков, хорошая ИДЕ (студия). В общем, комплекс и з положительных и не очень черт.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Спасибо за помощь. Очень благодарен.
Насколько я понял в Delphi 7 тоже можно писать для .NET
Кстати, в MS VS.NET если написать обычный Win32 Project, он тоже не будет работать без .NET Framework 1.1?
Я все думаю: покупать или нет, 8 дисков все-таки.
Еще раз спасибо.
С ув. Алексей
Здравствуйте, Столетний Алексей, Вы писали:
СА>Спасибо за помощь. Очень благодарен. СА>Насколько я понял в Delphi 7 тоже можно писать для .NET СА>Кстати, в MS VS.NET если написать обычный Win32 Project, он тоже не будет работать без .NET Framework 1.1? СА>Я все думаю: покупать или нет, 8 дисков все-таки. СА>Еще раз спасибо. СА>С ув. Алексей
Будет, ещё есть MFC и ATL продвинутые, и работать в новой студии удобнее, если привыкнуть, в общем студия ништяк, покупай не пожалеешь, можно делать всё, даже низкоуровневые (с точки зрения Windows) штучки, в общем всё, что можно было делать в VS6 можно делать и в новой, плюс естесственно .NET. Новая студия прекрасно уживается со старой на одном компьютере, хотя лично у меня такое уживание уже закончилось, и старой студии я сделал окончательеый UNINSTALL. По поводу .NET вообще есть разные мнения — кому нравиться, кому нет ( мне кстати не очень, в качестве платформы для настольных приложений), но это будущее (я так понимаю) и если в будущем ты хочешь писать под Windows , то ты будешь писать под .NET независимо от того нравиться тебе это или нет, так что покупай студию, книжку, запасайся терпением, временем, кофе и вперёд.
Здравствуйте, Столетний Алексей, Вы писали:
СА>Насколько я понял в Delphi 7 тоже можно писать для .NET
Нет, нельзя. Там есть отдельный компилятор под дотнет, но он еще очень сырой.
СА>Кстати, в MS VS.NET если написать обычный Win32 Project, он тоже не будет работать без .NET Framework 1.1?
Почему не будет? Будет.
СА>Я все думаю: покупать или нет, 8 дисков все-таки.
Это злобные пираты DVD-версию продают, чтобы денег поболе содрать. Инетная версия 4 диска вместе с MSDN.
Здравствуйте, beretta, Вы писали:
B>Здравствуйте, Столетний Алексей, Вы писали:
СА>>Спасибо за помощь. Очень благодарен. СА>>Насколько я понял в Delphi 7 тоже можно писать для .NET
B>Насколько я тоже понял, да.
СА>>Кстати, в MS VS.NET если написать обычный Win32 Project, он тоже не будет работать без .NET Framework 1.1?
B>Не будет, но счастье не за горами, в win2003 он уже часть ОС.
C чего ты взял? На седьмых плюсах можно прекрасно писать 100%-нативные приложения, которым никакой .НЕТ на фиг не нужен.С другой стороны у тебя есть возможность писать. скажем, приложения на основе МФС _и_ использовать управляемые расширения — тогда без .НЕТа не обойтись, но никто же этого делать не заставляет.
Здравствуйте, Столетний Алексей, Вы писали:
СА>Насколько я понял в Delphi 7 тоже можно писать для .NET
Там альфа компилятора командной строки. Работать серьезно невозможно.
СА>Кстати, в MS VS.NET если написать обычный Win32 Project, он тоже не будет работать без .NET Framework 1.1?
С чего бы? Framework требуется только для управляемых приложений. На С++ можно создавать unmanaged-код который будет требовать или unmanaged-рантайм (crt, mfc) или вообще не требовать никакого рантайма.
СА>Я все думаю: покупать или нет, 8 дисков все-таки.
Сама студия в сжатом виде лезет на один диск. У пиратов такие даже есть. Еще три диска это MSDN. Так что можно найти вариант на 4 дисках. Кстати, MSDN есть смысл брать свежий.
Ну, а стоит не стоит решать тебе. Я лично считаю, что изучение новых технологий — это 100%-ная польза и даже нечего думать. Но...
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, beretta, Вы писали:
СА>>Кстати, в MS VS.NET если написать обычный Win32 Project, он тоже не будет работать без .NET Framework 1.1? B>Не будет, но счастье не за горами, в win2003 он уже часть ОС.
Это же почему не будет? Про C++, MFC, ATL, WTL слышал?
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
B>>Не будет, но счастье не за горами, в win2003 он уже часть ОС.
ВВ>C чего ты взял? На седьмых плюсах можно прекрасно писать 100%-нативные приложения, которым никакой .НЕТ на фиг не нужен.С другой стороны у тебя есть возможность писать. скажем, приложения на основе МФС _и_ использовать управляемые расширения — тогда без .НЕТа не обойтись, но никто же этого делать не заставляет.
Здравствуйте, Столетний Алексей, Вы писали:
СА>Спасибо за помощь. Очень благодарен. СА>Насколько я понял в Delphi 7 тоже можно писать для .NET СА>Кстати, в MS VS.NET если написать обычный Win32 Project, он тоже не будет работать без .NET Framework 1.1? СА>Я все думаю: покупать или нет, 8 дисков все-таки. СА>Еще раз спасибо. СА>С ув. Алексей
В Delphi 7 только Превью. Настоящий выйдет только в конце года. Есть только С# Builder. В любом случае знать С# придется. Т.к. считается стандартом и в большинстве статьях используют его. Удачи. Можешь попробовать поискать на DVD. Всего 1 диск.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
VD>А как насчет МС++? Тоже менеджед, а ведь и без классов прекрасно работает?
статические методы тоже аналоги обычных процедур. Но подход должен быть единообразным. VD>А ничего, что он на этом АПИ основан? И что позволяет его взывать?
Пока Net надстройка над этим Апи. Но грядут новые Оси. S>>Основные отличия VD>Ну, еще проблемы детерменированной финализации.
Опять же нет проблем, просто в отличие от автоматических addref и release придется ручками это делать. А GC как раз и решает проблемы с минимальными нагрузками, т.к. для слежения за областью видимости удачно созданных объектов и добавлением соответствующего кода терялась эффективность. Но для слежения за системными ресурсами придется больше ручками программировать.
VD>Ну, есть ngen да и что называть динамической загрузкой...
Emit, CodeDom. Сборки загружаются по мере надобности. S>>3. Огромные возможности RTTI.
VD>Да и не RTTI — это. Все же в RTTI R — это рантайм. А информацию о типмх в дотнете можно читать и не будучи в рантайме.
Опять же динамически описанные и созданные объекты. S>>4. Защита, и отсутствие Ада DLL. VD> Гы. Кудаж он денется то? Тут-та он. По проще стало. Но всегда можно на старые грабли нарваться.
Если использовать Native код
S>>5. Продумманная иерархия классов и структур.
VD>Иногда не до конца.
Смотря с чем сравнивать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> статические методы тоже аналоги обычных процедур. Но подход должен быть единообразным.
Никому никто не должен. Просто не нужно путать исполняющую стреду и языки с их парадигмами.
S> Пока Net надстройка над этим Апи. Но грядут новые Оси.
И будут новые надстройки. Писать ядро на менеджед-коде вряд ли кто решится в ближайшее время.
VD>>Ну, еще проблемы детерменированной финализации. S> Опять же нет проблем, просто в отличие от автоматических addref и release придется ручками это делать. А GC как раз и решает проблемы с минимальными нагрузками, т.к. для слежения за областью видимости удачно созданных объектов и добавлением соответствующего кода терялась эффективность. Но для слежения за системными ресурсами придется больше ручками программировать.
То есть, проблем нет хотя конечно они достают.
VD>>Ну, есть ngen да и что называть динамической загрузкой... S> Emit, CodeDom. Сборки загружаются по мере надобности.
Ну, Emit еще куда не шло. Длли с отложеной загрузкой были за сто лет до дотнета. Ну, а CodeDom вообще никакого отношения к загрузке не имеет. Он используется исключительно средсвами разработки и исключительно в дизайнтайме.
S> Опять же динамически описанные и созданные объекты.
Не идеализируй. Метаинформация вещь статическая и к сожалению не доступная в компайл-тайме. В общем, вещь несомненно полезная, но не панацея. Мне бы, например, хотелось бы иметь эту информацию в компайл-тайме, чтобы можно было генерировать нужный код.
S> Если использовать Native код
С обычный. Забей номер версии жестко (вручную, без звездоче) и получи весь кайф. А ведь иногда (например, при использовании КОМ+-а без этого никак). Можно из без ручника. Измени интерфейс как следует не изменяя версии и вуаля.
В общем, смотри на жизнь реалистичнее. Вот тебе для поднятия настроения цитата одного неглупого человека (Ron-а Burk-а бывшего главреда WDJ):
История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.
Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
VD>>Иногда не до конца. S> Смотря с чем сравнивать.
Зачем с чем-то сравнивать, чтобы понять, что где-то иерархия классов хромает? Тут, например, АВК еще года два назад плевался по тому поводу, что во всем дотнене нет классов преализующих списки и деревья. И таких случаев пруд пруди (тот же Ремаутинг зияет дырами...). Другое дело что для многих применений более чем достаточно.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>[/q] Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
Около двух лет тому назад прочитал про Российский процессор Эльбрус, который дай бог памяти стековый и много ядерный. Они для него научилить из исходного кода генерить свой код для перераспределения нагрузки на ядра. Помоему 16-64 операции за такт. Сейчас IBM,Intel,AMD Trasmeta идут тем же путем. Но архитектурные различия все равно будут велики. Но IL код практически уже создан под них. И тогда или ось писать под каждый процессор или для каждого процессора свой JIT компилятор. Благо Intel в этом плане впереди планеты всей.
Можно говорить лишь об преждевременном на данном этапе появлении Net. Но задел нужно сохдавать уже сейчас.
VD>Зачем с чем-то сравнивать, чтобы понять, что где-то иерархия классов хромает? Тут, например, АВК еще года два назад плевался по тому поводу, что во всем дотнене нет классов преализующих списки и деревья. И таких случаев пруд пруди (тот же Ремаутинг зияет дырами...). Другое дело что для многих применений более чем достаточно.
Ну эту то дыру очень легко заткнуть. Все зависит от количества людей переориентированных на Net. Всему свое время. А проблем у Net должно быть ооочень мног. Слишком молодая она. Но ооочень перспективная.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Около двух лет тому назад прочитал про Российский процессор Эльбрус, который дай бог памяти стековый и много ядерный.
Смешно. Не прошло и 45 лет (http://www.optim.ru/cs/1999/1/e2k2/e2k2.asp).
S> Они для него научилить из исходного кода генерить свой код для перераспределения нагрузки на ядра. Помоему 16-64 операции за такт. Сейчас IBM,Intel,AMD Trasmeta идут тем же путем. Но архитектурные различия все равно будут велики. Но IL код практически уже создан под них. И тогда или ось писать под каждый процессор или для каждого процессора свой JIT компилятор. Благо Intel в этом плане впереди планеты всей.
Это ты о Эльбрус 2000 говоришь. Так он только на бумаге остался.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Это ты о Эльбрус 2000 говоришь. Так он только на бумаге остался.
Принцып развития процессоров заложен давным давнно. х86 уже сколько держатся. И этому анахронизму помогает жить только Native код. В Delphi вообще нет оптимизации под процессор ориентируются на усредненный. В линуксе еще есть возможность даже ядро компилировать под процессор. Заменил камень и опять все поновому???? Или новый компилятор вышел, и ....
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год. VD>[/q]
Жил да был Winforms, который хотел исправить фатальные недостатки MFC и ActiveX, вместе взятых. Но вскоре группа Windows решила написать Avalon... Да, и Longhorn API — это удар ниже пояса по BCL. История продолжается!
Здравствуйте, AndrewVK, Вы писали:
S>> Принцып развития процессоров заложен давным давнно. х86 уже сколько держатся.
AVK>Да ничего там давно уже не держится и оставлено только для совместимости. А процессоры архитектурно уже совсем-совсем другие.
То есть Native код произведенный например на Delphi учитывает эти особенности????
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>Да ничего там давно уже не держится и оставлено только для совместимости. А процессоры архитектурно уже совсем-совсем другие. S> То есть Native код произведенный например на Delphi учитывает эти особенности????
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Да ничего там давно уже не держится и оставлено только для совместимости. А процессоры архитектурно уже совсем-совсем другие. S>> То есть Native код произведенный например на Delphi учитывает эти особенности????
AVK>Конечно.
Например??? Если не использовать ASM код?????
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>> Например???
AVK>Блин, да у меня Дельфи на машине нет. Можешь посмотреть генерацию кода для циклов с включенной оптимизацией.
S>> Если не использовать ASM код?????
AVK>Типа прикалываешься?
Абсолютно не прикалываюсь. Это плохо что у тебя нет Delphi.
Запихивают счетчики в регистры. При вызове типа Register тоже запихивают переменные в регистры.
Но их (регистров) количество ограничено и поэтому постоянные PUSH и POP.
Но с FPU сначала все переменные запихивают в стек , а уж затем перекидывют в стек FPU. А интересно поддержка ММХ хоть есть??? не говоря о AMD NOW, SSE и SSE2.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alexkro, Вы писали:
A>Жил да был Winforms, который хотел исправить фатальные недостатки MFC и ActiveX, вместе взятых. Но вскоре группа Windows решила написать Avalon... Да, и Longhorn API — это удар ниже пояса по BCL. История продолжается!
Не не так. "Но группа разработчиков Виндовс нашла в ВинФормс фатальный недостаток... ну, вы сами знаете какой..."
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Ну, Emit еще куда не шло. Длли с отложеной загрузкой были за сто лет до дотнета. Ну, а CodeDom вообще никакого отношения к загрузке не имеет. Он используется исключительно средсвами разработки и исключительно в дизайнтайме.
Да только ты получал ссылки на функции, в отличие от obj файлов и при этом никакой информации опараметрах. Особенно при переводе описаний функций API с C++ на Delphi. Сборки ближе к OBJ файлам. S>> Опять же динамически описанные и созданные объекты.
VD>Не идеализируй. Метаинформация вещь статическая и к сожалению не доступная в компайл-тайме. В общем, вещь несомненно полезная, но не панацея. Мне бы, например, хотелось бы иметь эту информацию в компайл-тайме, чтобы можно было генерировать нужный код.
Очень хорошая статья в MSDN №9(21) сентябрь 2003. "Перезапись MSIL кода "на лету" с помощью .Net FrameWork Profiling API" Александр Микунов.
" Основная идея: Клгда CLR загружает класс и выполняет его метод,IL- код метода транслируется в машинный код в процессе JIT компиляции Profiling позволяет перехватить этот процесс и вставить свой код. Так же через интерфейсы IMetaDataEmit можно создавать свои маркеры метаданных "на лету".
По поводу CodeDom. ICodeConpiler.CompileAssemblyFromSource можно получить скомпилированную АссемБЛЮ и получать доступ к типам это ассембли Например http://www.codeproject.com/csharp/matheval.asp
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Да только ты получал ссылки на функции, в отличие от obj файлов и при этом никакой информации опараметрах.
В обжах тоже не дофига информации.
S> Особенно при переводе описаний функций API с C++ на Delphi. Сборки ближе к OBJ файлам.
Сборки ближе к КОМ-объектам с ТЛБ-хами. Это компонентная среда с исчерпывающими метаданными. Это не сомненно большое достоинство, но как я уже сказал был КОМ... не так крут, но все же.
S> Очень хорошая статья в MSDN №9(21) сентябрь 2003. "Перезапись MSIL кода "на лету" с помощью .Net FrameWork Profiling API" Александр Микунов. S>" Основная идея: Клгда CLR загружает класс и выполняет его метод,IL- код метода транслируется в машинный код в процессе JIT компиляции Profiling позволяет перехватить этот процесс и вставить свой код. Так же через интерфейсы IMetaDataEmit можно создавать свои маркеры метаданных "на лету".
Это все здорово, но это хак. А нужно бы иметь стандартные средства, да еще с простой отладкой.
S> По поводу CodeDom. ICodeConpiler.CompileAssemblyFromSource можно получить скомпилированную АссемБЛЮ и получать доступ к типам это ассембли Например http://www.codeproject.com/csharp/matheval.asp
И какое отношение имеет ICodeConpiler.CompileAssemblyFromSource к CodeDom? Можно конечно и с CodeDom-а компилироваться, но это кроме тормозов ничего не даст. В общем, это из другой оперы.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Выставка наверное закончилась. Поздравляю. S>> Да только ты получал ссылки на функции, в отличие от obj файлов и при этом никакой информации опараметрах.
VD>В обжах тоже не дофига информации.
Только для правильной линковки и компиляции.
S>> Особенно при переводе описаний функций API с C++ на Delphi. Сборки ближе к OBJ файлам.
VD>Сборки ближе к КОМ-объектам с ТЛБ-хами. Это компонентная среда с исчерпывающими метаданными. Это не сомненно большое достоинство, но как я уже сказал был КОМ... не так крут, но все же.
С точки зрения метаданных да. С точки зрения компиляции виртуальная стыковка, без которой можно обойтись. Еще раз повторю для каждого Сом объекта (не класса) генерится своя VMT с функциями заглушками с передачей This в реальные методы. Не есть хорошо. В отличие JIT компиляции. Пляс языковая совместимость на такм уровне удручает. S>> Очень хорошая статья в MSDN №9(21) сентябрь 2003. "Перезапись MSIL кода "на лету" с помощью .Net FrameWork Profiling API" Александр Микунов. S>>" Основная идея: Клгда CLR загружает класс и выполняет его метод,IL- код метода транслируется в машинный код в процессе JIT компиляции Profiling позволяет перехватить этот процесс и вставить свой код. Так же через интерфейсы IMetaDataEmit можно создавать свои маркеры метаданных "на лету".
VD>Это все здорово, но это хак. А нужно бы иметь стандартные средства, да еще с простой отладкой.
Согласен, но всетаки информация не статична. S>> По поводу CodeDom. ICodeConpiler.CompileAssemblyFromSource можно получить скомпилированную АссемБЛЮ и получать доступ к типам это ассембли Например http://www.codeproject.com/csharp/matheval.asp
VD>И какое отношение имеет ICodeConpiler.CompileAssemblyFromSource к CodeDom? Можно конечно и с CodeDom-а компилироваться, но это кроме тормозов ничего не даст. В общем, это из другой оперы.
ICodeConpiler.CompileAssemblyFromSource относится к System.CodeDom.Compiler. Присутствует аналогичное сходство????
Один раз откомпилировав и используя интерфейсы и делегаты даст хороший выход при частом использовании.
При всем идеи Net очень прогрессивны, а вот реализация надстройки хромает (тот Же SortedList).
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> С точки зрения метаданных да. С точки зрения компиляции виртуальная стыковка, без которой можно обойтись. Еще раз повторю для каждого Сом объекта (не класса) генерится своя VMT с функциями заглушками с передачей This в реальные методы. Не есть хорошо. В отличие JIT компиляции. Пляс языковая совместимость на такм уровне удручает.
Никто не спорит, что в дотнете это сделано лучше. Если бы было хуже, то я бы дотнетом не занимался.
S> При всем идеи Net очень прогрессивны, а вот реализация надстройки хромает (тот Же SortedList).
Хромают чьи-то знания в области алгоритмов . Да и прогрессивность дотнета во многом сомнительна. Гонка за рантаймом и компонентностью иногда доходит до маразма. О компайл-тайме тоже нужно думать.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> С точки зрения метаданных да. С точки зрения компиляции виртуальная стыковка, без которой можно обойтись. Еще раз повторю для каждого Сом объекта (не класса) генерится своя VMT с функциями заглушками с передачей This в реальные методы. Не есть хорошо. В отличие JIT компиляции. Пляс языковая совместимость на такм уровне удручает.
VD>Никто не спорит, что в дотнете это сделано лучше. Если бы было хуже, то я бы дотнетом не занимался.
S>> При всем идеи Net очень прогрессивны, а вот реализация надстройки хромает (тот Же SortedList).
VD>Хромают чьи-то знания в области алгоритмов . Да и прогрессивность дотнета во многом сомнительна. Гонка за рантаймом и компонентностью иногда доходит до маразма. О компайл-тайме тоже нужно думать.
Компонентность нужна однозначна. Я как старый Батерфляист это заявляю. Рантайм вспоминая скорость компиляции в Delphi ничтожно мала. А вот из-за GC некоторые вещи непонятны. Так у Робинсона написано, что при использовании UNsafe при записи содержащей ссылки но Object и ccылочные типы вариант Move не проходит.
Я проводил эксперименты все проходит на ура, но как запретить GС в этот момент запретить сборку мусора????
В принципе все упирается (для меня лично) в управлением GC и привычные быстрые методы работой с памятью.
Например http://www.rsdn.ru/Forum/Message.aspx?mid=390648&only=1
Здравствуйте, Serginio1, Вы писали:
S> Компонентность нужна однозначна.
Опять так я не против. Но не считаю, что из-за этого должна страдать производительность и отсуствовать метапрограмминг.
S>А вот из-за GC некоторые вещи непонятны. Так у Робинсона написано, что при использовании UNsafe при записи содержащей ссылки но Object и ccылочные типы вариант Move не проходит. S> Я проводил эксперименты все проходит на ура, но как запретить GС в этот момент запретить сборку мусора????
Если пиннуть указатель, то он не будет трогаться ЖЦ. Но при этом в текущей версии он похоже перекидывается в другой хип.
S> В принципе все упирается (для меня лично) в управлением GC и привычные быстрые методы работой с памятью. S> Например http://www.rsdn.ru/Forum/Message.aspx?mid=390648&only=1
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Компонентность нужна однозначна.
VD>Опять так я не против. Но не считаю, что из-за этого должна страдать производительность и отсуствовать метапрограмминг.
S>>А вот из-за GC некоторые вещи непонятны. Так у Робинсона написано, что при использовании UNsafe при записи содержащей ссылки но Object и ccылочные типы вариант Move не проходит. S>> Я проводил эксперименты все проходит на ура, но как запретить GС в этот момент запретить сборку мусора????
VD>Если пиннуть указатель, то он не будет трогаться ЖЦ. Но при этом в текущей версии он похоже перекидывается в другой хип.
При пинне Я так понял создается копия. GC.Alloc???? S>> В принципе все упирается (для меня лично) в управлением GC и привычные быстрые методы работой с памятью. S>> Например http://www.rsdn.ru/Forum/Message.aspx?mid=390648&only=1
. S>> Заранее благодарен за ответ.
VD>Ну, это скорее пережитки. Меня уже даже не тянет заниматься таким.
Netовские филды удовлетворяют??? при этом происходит переупаковка реальных данных в БД в Нетовские.
Не большие ли это потери??? Хотя боксинг и унбоксинг интежеров на 1 мил. всего 0,2 сек.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> При пинне Я так понял создается копия. GC.Alloc????
Это можно увидить только в исходниках ротора. Желания этим заниматься у меня нет.
S> Netовские филды удовлетворяют??? при этом происходит переупаковка реальных данных в БД в Нетовские. S> Не большие ли это потери??? Хотя боксинг и унбоксинг интежеров на 1 мил. всего 0,2 сек.
По сравнению с доступом к БД — это фигня. Датасет вообще по скорости меня удовлетворяет. Кстати, нафиг там боксинг я так ни не понял. Могли бы сделать типизированный доступ.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
S>На том языке, на котором ты писал раньше. Хотя я не знаю, где взять паскаль, но наверное где-то можно. А лучше — выбери C#, помесь C++,VB и явы.. симпатичная надо сказать.. особенно мне нравится динамическое выделение памяти.
А что имено ты шашел особенного в выделении памяти с помощью C#?
Про C++, MFC, ATL, WTL слышал?
. Да и прогрессивность дотнета во многом сомнительна. Гонка за рантаймом и компонентностью иногда доходит до маразма. О компайл-тайме тоже нужно думать.
