Delphi 8 - Первые впечатления , Шаг вперёд - два шага назад?

2 SPrograMMer

Цитата

а есть ли документация для C# на РУССКОМ?

Я не думаю что, есть перевод на русский официального стандарта _http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c036768_ISO_IEC_23270_2003(E).zip.
Я тут упоминал о такой книге: Рихтер Дж. Программирование на платформе Microsoft .NET Framework. - 2 изд., испр. - М.: "Русская редакция", 2003. - 512 с.
Мне она понравилась тем, что это практически единственная книга, которая, в полной мере излагает концепцию .NET. (Если нужны подробные описания работы с конкретными технологиями библтиотеки классов FCL - тут нужны другие книги, например, одноименная книга Дж. Просиза. Хотя и у Рихтера есть несколько подробных примеров).

Дело в том, что кроме перечисленного книга Рихтера дает практически все, что нужно знать о C#.
Можно почерпнуть и описание принципов ООП. Хотя лучше последовать совету автора, и начать читать его книгу, предварительно вооружившись представлением о таких понятиях, как абстрагирование данных, инкапсуляция, наследование и полиморфизм.

Читать вначале же книги, которые названы типа "Программирование на C#", для изучения C#, я бы не советовал, т.к. изучение C# желательно производить одновременно с изучением .NET.
Это уже потом, для глубокого изучения деталей, можно и почитать такие книги.

2 mike

Цитата

Если .Net Framework не отвечает вашим реальным требованиям (а это в основном Web-приложения), то спокойно продолжайте использовать WinApi и Delphi 1-7.

mike, Web-приложения - это одна областей, где преимущества .NET проявляются сильнее всего.
Это, конечно, не значит, что я призываю немедленно переделывать существующие Web-приложения под .NET.

Цитата

.Net является оболочкой для того же

Цитата

уродливого WinApi

Это Microsoft .NET Framework 1.1 является оболочкой для WinAPI.
.NET же как таковая - открытый набор спецификаций, который можно реализовывать где угодно.
Другое дело, если в какой-то операционной системе не будет технологий, которые предусматриваются в .NET, то разработка .NET выльется в разработку Pure-NET.-ОС. Пожалуй, такая .NET будет самой полноценной.

Цитата

Хотелось бы знать: а что выпустила сама Майкрософт с использованием .NET Framework кроме Visual Studio. Из прикладного ПО, оффиса, игр?

Мне думается, что свои .NET-продукты MS будет писать под .NET 2.0. Как бы ни была хороша .NET, следует признать, что версия 1.1 - для переходного периода.

Всем, кто интересуется .NET
Еще несколько слов об "архитектурном уровне" .NET, которые некоторых почему-то "запарили".
Обращаю внимание, что с момента выхода Microsoft .NET Framework 1.1 прошло 1,5 года, и за это время не вышло ни одного обновления для нее.
Если саму качественную архитектуру нельзя пощупать (видимо, поэтому некоторых и раздражают мои слова об "архитектурном уровне"), то вот следствие такой архитектуры налицо: беспрецедентная стабильность.
P.S. А сколько за последние 1,5 года вышло патчей для других продуктов MS, кто-нибудь считал?..

Цитата

Когда большинство разработчиков стали программировать под Windows на ООП-языках (Object Pascal, C++, etc... ), стало не с руки общаться написанным программам с помощью процедур/функций, а объектно они общаться на могли, т.к. в каждом языке своя объектная модель.
Появилась необходимость в объектной надстройке над платформой WinAPI, чтобы Windows-программы общались объектным образом. Так родился COM.

1. Две программы никогда не общались через процедуры или функции. Наверное всё-таки имелись в виду функции, экспортируемые из DLL.
2. COM - это не надстройка над WinAPI. COM - Component Object Model - модель, стандарт, спецификация.
3. До появления COM было вполне возможно использовать компонентную модель. Реализация COM для Windows не дает никаких базовых функций, без которых невозможно было бы использование компонентов, а содержит ряд вспомогательных функций для компонентного программирования, например для использования информации о компонентах, установленных в системе, а также предоставляет функции для маршалинга, которыми при желании можно не пользоваться.
3. COM, в отличие от .Net, не накладывает никаких ограничений на язык программирования. Можно использовать хоть Delphi, хоть Си, хоть ассемблер. Всё, что требуется - это машинный код, указатели на методы объектов и несколько внешних функций. Компилятор может даже не знать о существовании COM.
4. Можно делать компоненты не только для Windows, хоть для DOS, только потребуется писать свой загрузчик Dll (или чего-то подобного) в системах, где нет динамических библиотек.
5. COM не появился сам по себе. Сначала появилось OLE. В OLE был использован компонентный подход, который позже Microsoft отделила от OLE.
6. Возможно использование компонентов COM без использования функций, предоставляемых COM. Поэтому COM и WinAPI в общем ничего не связывает кроме этих самых функций, которые являются API.

Так что не факт, что .Net использовать более выгодно, чем COM (в компонентном отношении).

.Net не является оболочкой над WinAPI, однако библиотека классов является (за небольшим исключением).

Я согласен, что использование .Net при программирование бизнес-логики и Web может быть выгодно. Но не надо перекладывать на .Net всё остальное.

Sanek

Цитата

.Net не является оболочкой над WinAPI, однако библиотека классов является (за небольшим исключением).

А разве это не самое основное? Что останется от .Net без библиотеки классов?

2 mike[/B

Цитата

]

Цитата

Net не является оболочкой над WinAPI, однако библиотека классов является (за небольшим исключением).

А разве это не самое основное? Что останется от .Net без библиотеки классов?

Основное в .NET - это [B]архитектура, в соответствии с которой построена и FCL в том числе.

Andr опять теги не закрываешь!

2 Andr

Цитата

Web-приложения - это одна областей, где преимущества .NET проявляются сильнее всего.

А где еще?

Цитата

Это, конечно, не значит, что я призываю немедленно переделывать существующие Web-приложения под .NET.

Хотелось бы, чтобы Микрософт первой показала пример. Хотя бы начиная с .NET 2.0.

Цитата

Это Microsoft .NET Framework 1.1 является оболочкой для WinAPI.

А все-таки хорошо, что признал. Раньше ты заявлял, что

Цитата

Поэтому мнения, что .NET - ООП-обертка для WinAPI - безосновательны.

И еще:

Цитата

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

Вот поэтому Микрософтовская реализация .NET пока будет сильно привязана к WinApi и к самой операционной системе. Замены WinApi пока нет и еще долго не будет.

2 mike
Области наиболее эффективного применения .NET-приложений (где они выгодно отличаются от C#) по крупному делятся на:
1. Интернет-приложения всех типов (технология ASP.NET).
2. Приложения с графическим интерфейсом пользователя (технология Windows Forms).
3. Любые приложения работы с базами данных (технология ADO.NET).
4. Все приложения, которым нужна функциональность, предоставляемая библиотекой FCL. Библиотека FCL богаче любой API и при этом полностью объектно-ориентированная.

Если в какой-то задаче (вдруг!) нехватит возможностей FCL, то можно вызывать внешний неуправляемый код (например, функции WinAPI или ActiveX-объекты).

Цитата

Цитата

Это Microsoft .NET Framework 1.1 является оболочкой для WinAPI.

А все-таки хорошо, что признал. Раньше ты заявлял, что

Цитата

Поэтому мнения, что .NET - ООП-обертка для WinAPI - безосновательны.

Давайте разберемся с этим:
1. .NET и FCL в частности - открытые спецификации.
2. MS реализовала .NET для Windows и так уж совпало (?), что некоторые классы из спецификации FCL похожи на объекты WinAPI. Реализовать эти классы действительно было проще как обертку некоторых функци WinAPI. Но это ничуть не умаляет достоинств .NET/FCL.

Другое дело, что в своей реализации языка C# и FCL MS чуть вышла за рамки открытой спецификации.
В рузультате мы имеем некоторые (преодолевавемые) трудности с переносимостью MS-.NET-приложений на другие .NET-совместимые платформы (ex.: Mono), но зато имеем возможность создавать системные приложения. Это выгодно отличает .NET от платформы Java, которая очень ограничивает разработчика в типе создаваемых приложений.

2 Sanek

Цитата

1. Две программы никогда не общались через процедуры или функции. Наверное всё-таки имелись в виду функции, экспортируемые из DLL.

Это я и имел в виду:) Но не конкретизировал, т.к. хотел сказать о другом: общаться через экспортируемые функции было несложно, т.к. согласовать нужно было немного:
1) Способ передачи параметров. Эта проблема решалась тем, что большинство языков умеют использовать различные способы (с помощью директив).
2) Типы передавамых данных были простые: целые числа, указатели, булевы значения. Нужно было только учитывать размерности типов целых чисел и внутренний формат булевых типов.

А если ООП-программы, написанные на разных языках, хотели общаться объектно, то это было затруднительно из-зи различий объектных моделей языков. Потому родились COM и ему подобные.

Я не спорю, что COM - это тоже набор спецификаций. Но тем не менее COM - это надстройка, решающая проблемы используемой платформы. А .NET - это платформа, решающая проблемы.
Разница есть? Есть, и заключается она в упрощении/убыстрении разработки ПО и в высокой стабильности разработанного ПО, при программировании под .NET.

Цитата

COM, в отличие от .Net, не накладывает никаких ограничений на язык программирования. Можно использовать хоть Delphi, хоть Си, хоть ассемблер. Всё, что требуется - это машинный код, указатели на методы объектов и несколько внешних функций.

NET тоже не накладывает ограничений на язык.
Просто .NET-языки должны удовлетворять общеязыковой спецификации (CLS) и общеязыковой системе (CTS)типов (хоть IL-ассебмлер, хоть C#/J#/C++ME/Delphi.NET...). Кстати, за рамки CLS/CTS выходить не возбраняется... Самый полный IL-asm, после него - C#.
Разница же только в том, что .NET работает с IL-кодом, а COM - с машинным.

Так вот тут насчет БД проскочило,

Цитата

3. Любые приложения работы с базами данных (технология ADO.NET).

ТАК, а как насчет InterBase, например, он значит, как и WinAPI умирает?
и нет теперь свободы выбора, какая былоа ранее: хочешь BDE, не хочешь, давай ADO, тоже не хочешь, ну уж InterBase точно устроит, а не устроит, так придумаем есчо чего нибудь...( но все это было раньше )
а теперь, только ADO.NET?

Сообщение отредактировано: SPrograMMer - 31.08.04, 07:31

2 SPrograMMer

Цитата

ТАК, а как насчет InterBase, например, он значит, как и WinAPI умирает?
и нет теперь свободы выбора, какая былоа ранее: хочешь BDE, не хочешь, давай ADO, тоже не хочешь, ну уж InterBase точно устроит, а не устроит, так придумаем есчо чего нибудь...( но все это было раньше )
а теперь, только ADO.NET?

Я вижу, те, кто обсужает здесь .NET, не совсем подкованы в теории.

ADO.NET предствляет собой универсальный механизм доступа к любым БД посредством провайдера.
Для MS SQL Server в ADO.NET включен специальный провайдер.

Для доступа к другим БД в ADO.NET включен специальный OLE DB Provider. Главное, чтобы БД была совместима с этим провейдером.
Например, Oracle совместима с OLE DB-провайдером ADO.NET.

Если кого-то волнует IB 7.1, то в состав его полного дисрибутива входит набор BDP.NET - ADO.NET-провайдер для доступа к IB 7.1. Так что IB 7.1 можно юзать в любой (в т.ч. не Борландовской) среде разработки .NET-приложений (ex.: VS .NET 2003).

Кроме того, в состав Delphi 8/C#Builder входит набор BDP для доступа к IB 7.1, MS SQL, Oracle, IBM DB2.

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

Цитата SPrograMMer @ 31.08.04, 12:30

Цитата

ТАК, а как насчет InterBase, например, он значит, как и WinAPI умирает?

Насчет Interbase и Firebird можно не переживать:
http://www.ibphoenix.com/main.nfs?a=ibphoe...download_dotnet

Firebird .Net Data Provider

The .NET Data Provider/Driver is written in C# and provides a high-performance, native implementation of the Firebird API.
...

----------------------------------------------------------------------------
Вопрос в необходимости перехода к другой технологии доступа к БД.
Например, решил я перейти к программированию на C# и хочу при этом
использовать технологию dbExpress - можно ли это реализовать ?

Andr, раз уж ты так хорошо знаешь .NET, то может расскажешь, какие приложения стоит писать с помощью .NET с точки зрения производительности.

Для приложений мне нужна не только красивая и прочная архитектура. Хотелось бы, чтобы они еще и быстро работали (тем более если мне ставят такие условия).

Я уже читал на этом форуме, что для приложений, связанных с базами данных и Веб-приложений скорость ограничивается другими факторами. Согласен. Поэтому меня интересуют следующие пункты:

Цитата

...
2. Приложения с графическим интерфейсом пользователя (технология Windows Forms).
...
4. Все приложения, которым нужна функциональность, предоставляемая библиотекой FCL. Библиотека FCL богаче любой API и при этом полностью объектно-ориентированная.

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

to mike

Цитата

... какие приложения стоит писать с помощью .NET с точки зрения производительности.
...
Хотелось бы, чтобы они еще и быстро работали (тем более если мне ставят такие условия).

Исполняемый файл .NET содержит IL-код.
Каждый метод перед своим первым вызовом компилируется (и остается в скомпилированном виде в ОЗУ до завершения программы) в машиный код, оптимизированный под систему команд того процессора, под управлением которого в данный момент выполняется. Например, если это P4, то скомпилированный метод будет использовать все преимущества P4.
Кроме того, сам формат IL-кода позволяет производить компиляцию в более эффективный машинный код, чем напрямую из исходного текста.

Естественно, в результате мы можем получить в производительности выигрыш в разы.

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

А вот Delphi <= 7 компилирует исполняемые файлы в базовом наборе инструкция i80386. Если мы возьмем любой справочник по ассебблеру x86, то увидим, что в i486 и Pentium даже для целочисленных операций введены более быстрые команды.

А как на практике?
Мне самому интересно привести опыт, еще руки не дошли. Но в ближайшее время обязательно сделаю.
Однако на форумах (возможно, даже на этом - не помню) встречал высказывания о проведенных опытах, что Visual Basic .NET-программы стали выполняться в 2 раза быстрее, чем теже программы, но скомпилированные в простом Visual Basic.

Однако я сам все проверю на D7<->D8, а также сравню c производительностью тех же алгоритмов на C#.

Цитата

4. Все приложения, которым нужна функциональность, предоставляемая библиотекой FCL. Библиотека FCL богаче любой API и при этом полностью объектно-ориентированная.

Естественно, что библиотека содержит ряд дополнительных классов. Однако вот пример. Допустим нужен список для использования несколькими потоками с атомарным доступом. Понятно, что реализовать такое можно только на системном уровне. В Windows XP/Server 2003 есть функции для работы с такими списками, в остальных - нет. С появлением новых функций ОС, появляются/изменяются классы FCL (должны). Т. е. возможности библиотеки ограничены возможностями системы (это касается классов, так или иначе связанных с системными объектами). В этом отношении FCL не может быть богаче Windows API.

Цитата

В рузультате мы имеем некоторые (преодолевавемые) трудности с переносимостью MS-.NET-приложений на другие .NET-совместимые платформы

Сомневаюсь, что преодолимые. Точнее я почти уверен, что отдельные классы FCL перенести не удастся. Я уже об этом говорил.

Цитата

Я не спорю, что COM - это тоже набор спецификаций. Но тем не менее COM - это надстройка, решающая проблемы используемой платформы. А .NET - это платформа, решающая проблемы.

Я пытаюсь объяснить то же, что ты отностиельно .Net и .Net Framework для Windows. COM - спецификация, весь код - конкретная реализация для Windows. Есть аналоги для других ОС. Сам COM не сложно портировать для других ОС (естественно, что придется хранить сведения о компонентах не в реестре).

Цитата

NET тоже не накладывает ограничений на язык.

А это что:

Цитата

Просто .NET-языки должны удовлетворять общеязыковой спецификации (CLS) и общеязыковой системе (CTS)типов (хоть IL-ассебмлер, хоть C#/J#/C++ME/Delphi.NET...)

Из-за этого "просто" искаверкали Delphi до неузнаваемости. Помимо этой самой спецификации (интересно, какие языки без изменения ей удовлетворяют), есть ещё одно существенное ограничение: требуется наличие транслятора в IL.

Цитата

Каждый метод перед своим первым вызовом компилируется (и остается в скомпилированном виде в ОЗУ до завершения программы) в машиный код, оптимизированный под систему команд того процессора, под управлением которого в данный момент выполняется. Например, если это P4, то скомпилированный метод будет использовать все преимущества P4.

Об этом уже говорили. Так как компиляция происходит во время выполнения, то на неё должно тратится минимальное количество времени. Вряд ли это будет самый оптимальный код.

Цитата

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

Ну это я уже совсем не понимаю. По-моему сразу логически понятно, что трансляция в IL может лишь уменьшить (может и не уменьшить, но не увеличит) возможность оптимизации кода.

Да это всё без аргументов, уменьшит или не уменьшит. Я писал простую программку, там пара вложенных циклов. (без интерфейса и всяких наворотов). Под .Net проигрыш более чем в 1.5 раза (на моём компе). Ну если уж в циклах такой проигрыш (как они вообще умудрились-то!!!), то что о другом говорить.

Блин... а что с указателями-то делать ?!!
Я в тоске...

Вот и прикинем - мало того что прога станет вдвое тормозить только изза того что она написана под .NET да еще и в неизвестное количество раз станет все хуже изза отсутствия указателей.

Ну ладно, когда .NET будет встроена в ядро ОС, в той же longhorn возможно тормозить будет по сравнению с WINAPI уже не в два раза а только в полтора.

Но указатели то за что?

Я еще пока не разобрался толком, но понял что это изза "автоматического мусорщика" у которого явные проблемы с идентификацией свободен ли кусочек кучи или нет. А если без обиняков - всю эту хренотень наворотили, лишили живительного инструмента в виде указателей только лишь потому, что кое кто забывает после Create сделать Free??
С одной стороны вроде как признают программистов за людей умных, инструменты им создают, язык программирования, фичи разные... Но с другой стороны, какого-то хрена дался им этот Garbage Collector, который, если задуматься, ох как немало тактов проца жрать будет и причем постоянно. Откуда высокой производительности взяться?

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

Добавлено в 01.09.04, 23:47:
Ух ты!!Классную штуку нашел.

Делает "инсталяшку" чтобы .NET прога запускалась на целевой машине без развертывания там .NET framework.
Наверное это можно в ФАК.

http://www.remotesoft.com/linker/

"Salamander .NET Linker and mini-deployment tool allows you to link .NET assemblies together into a single file, and to deploy your application without installation of the whole Microsoft .NET Framework. The linker selectively links MSIL code putting together only the required classes and methods, and it is capable of linking into the Microsoft .NET framework class libraries. The mini-deployment tool then builds a minimum set of the Microsoft .NET runtime to ship with your application. This usually results in installation size of a few mega bytes, rather than tens of mega bytes, and the installation takes much less time without rebooting machines. The mini-deployed application can be launched directly from a CD, absolutely without copying files or adding registry entries."

Сообщение отредактировано: encobalt - 01.09.04, 23:32

2 Andr

Цитата

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

Вот этого я не понимаю. Какая разница из чего делать исполняемый код. IL нужен только для более быстрого создания машинного кода.

Цитата

Visual Basic .NET-программы стали выполняться в 2 раза быстрее, чем теже программы, но скомпилированные в простом Visual Basic.

Микрософт совершенствуется .
По-моему VB никто никогда не считал быстрым и высокоэффективным компилятором.

Цитата

Например, если это P4, то скомпилированный метод будет использовать все преимущества P4.

...

А вот Delphi <= 7 компилирует исполняемые файлы в базовом наборе инструкция i80386. Если мы возьмем любой справочник по ассебблеру x86, то увидим, что в i486 и Pentium даже для целочисленных операций введены более быстрые команды.

Это не такой уж и недостаток Delphi. Благодаря этому обеспечивается высочайшая скорость компилляции. Да и не инструкции главное. Например при работе с графикой используется или GDI, OpenGL или DirectX. Так вот главное, чтобы в библиотеках, содержащих эти функции содержался оптимизированный код под конкретный процессор. Многое также зависит от драйверов. А каким образом будет вызывать эти функции Delphi абсолютно все равно.

А вот для драйверов устройств важно, какие инструкции они используют. Но кто будет писать драйвер устройства с помощью .NET?

Но даже если очень надо, то подключить ассемблерный код под конкретный процессор можно с помощью OBJ-файлов.