Здравствуйте, Столетний Алексей, Вы писали:
СА>Спасибо за помощь. Очень благодарен. СА>Насколько я понял в 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).
и солнце б утром не вставало, когда бы не было меня
