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

Сегодня имел возможность ознакомиться с Delphi 8. Впечатления двойственные.

Ну вначале то чего больше нет: а нет всеми любимых WinAPI... Судя по всему теоретически нет так
как сделан новый Дельфи под .net платформу, а посему о Windows имеет только те сведения которые
ему даёт ента самая .net. Может и не всё так страшно и со временем многое прояснится, но пока я
не нашёл возможности вызвать ни одной функции WinAPI.

Дизайн: Борланд ушёл от своего дизайна в сторону MS Visual Studio, а точнее в сторону VB. В
общем большинство кнопок на месте, горячие клавиши вроде тоже, но дизайн изменился. Лучше или
хуже? Не знаю, но для меня пока не привычно. Палитра инструментов переместилась в правый
край (интересно зачем?), форма в дизайне стала очень напоминать форму в VB, инспектор объектов
стал чем-то похожим на соотвесттвующее детище MS. Зачем это сделано - не знаю, ИМХО, к
переходу на .net платформу это всё не имеет никакого отношения, может таким образом
Борланд пытается перетянуть программистов с продуктов MS, облегчив им переход?

Вот как выглядит D8 при загрузке в первый раз без проекта.



А вот какие проекты мы имеем в наличии:



Давайте выберем проект и набросаем на форму компонентов, выглядеть это будет так:



А вот редактор кода, тоже "сдвинутый" в сторону MS обрадовал наличием возможности
навигационного дерева и "скрытия" лишнего кода, а так же подсветкой парных скобок,
кавычек и т.п.:




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

Итог:
- компиляция быстрая, тут ничего не скажешь, компильнул не хуже предыдущих версий, даже
наверное быстрее.

- файл получился размером аж 8 килобайт. Ну это мы проходили, при наличии .net framework
на несколько десятков метров это не удивительно...

- быстродействие - хоть под дебуггером, хоть под средой, хоть в готовом виде скорость
отработки поцедуры практически одинакова (разница порядка 2-3%) и ровно в 2 раза ниже чем
тот же код откомпиллированный в Дельфи 5.

Кстати на Web страничку, открываемую Дельфой по умолчанию мой Norton Antivirus
отреагировал однозначно - особозлобный вирь! Похоже фирма Symantec решила, что пора начинать
борьбу с Борландом, по-видимому они решили реинкарнировать свой C++ под .net платформу
(чем чёрт не шутит?).

Выводы!

Итак на первый взгляд (прошу быть снисходительными - к моменту написания этих строк я видел
эту версию всего пару часов!)

1. Дизайн. Изменился в сторону продуктов MS и сейчас является гибридом дизайна Дельфи и
дизайна VB.

2. Язык. Паскать остался паскалем, в простейших примерах никакой разницы не чуствуется, но
некое 7е чуство мне говорит, что если копнуть глубже простого цикла и кнопки на форме то
отличий будет не просто много, а очень много.

3. Редактор кода. Изменился в лучшую сторону, добавились очень удобные фишки.

4. Компоненты. Боюсь оказаться неправым, но набор компонентов определяется не столько самим
Дельфи, сколько .net framework, и набор этот бледный, т.е. его можно кое-как сравнить с
набором компонентов для Дельфи 1, но по сравнению с Дельфи 5/6/7 выглядит очень тускло,
представлены самые основные, базовые компоненты.

5. Производительность самой среды, скорость компилляции - вполне удовлетворительные, нареканий
нет.

6. Скорость работы сгенерированных исполняемых файлов - в аккурат в 2 раза меньше тех что
основанны на классических WinAPI.


PS. Я пока прикреплю тему, как информационно-новостную. Думаю многим будет интересно.

Сообщение отредактировано: Vit - 13.01.04, 00:03

Видели, видели .. и потом долго плакали!
Эту систему ждали, надеялись что Борланд в очередной раз докажет всем, что пишет лучшие среды для разработчиков, и что мы получили? Visual Studio UltraLite? Стоило ли вообще выпускать этот продукт?
Фанаты Delphi после этих слов закидают меня камнями, но увы время не стоит на месте! VCL как и MFC осталось жить два, максимум три года! После выхода LongHorn и .NET 2.0, MS SQL SERVER YUKON, VCL станет никому ненужным, впрочем как и WIN32 API! В Borland это понимают, и поэтому пытаются заскочить в мчащийся поезд .NET! Но сделала это бездарно и ужасно поздно!
Visual Studio поддерживает .NET уже 2 года! В нем интегрированны практически все необходимые средства разработки: компиляторы 4 языков программирования, MSDN (лучшая и самая полная документация по WINDOWS, кто бы там чего не говорил), Server Explorer, инструменты для создания MSI(инсталляторы), создание Help'ов, инструменты для тестирования приложений, Visual Safe (аналог Borland Star Team) и еще много чего. Не хватает только CASE и RUP, а судя по пресс релизам в VS 2004 CASE средства будут интегрированы в среду! (Прощай Rational Suite!) Более того через полгода (вроде бы к лету выйдет VS 2004), мы получим поддержку AVALON (новый 3D user interface).
И что нам предлагает Borland? Тоже самое, но с отставанием на 2 года?
Перейти с Паскаля на C# проще, чем с любого другого языка! Когда я начал изучать C#, подумал, что Microsoft решила перетащить всех Delphi программеров, и судя по тому, что я увидел в Delphi 8, она добъется этого не напрягаясь. Так что предположение многоуважаемого Vit, что Borland сделала интерфрейс Delphi 8 похожим на VS, что бы заполучить разработчиков, использующих средства от Microsoft - заблуждение! Более того, руководитель проекта .NET - человек, который 10 лет назад руководил созданием Delphi!
Delphi 8 нужна только тем, у кого гигабайты кода на паскале и им лениво его переписывать, хотя D8 и не позволяет простой перекомпиляцией получить управляемый, код, тем не менее, D8 поможет разработчикам плавно перейти на .NET. Насколько я знаю в России крупных проектов на Delphi написано не просто мало, а очень мало! В связи с этим большого спроса на программеров, знающих Delphi не будет. Это еще один гвоздь в гроб Delphi.
Лично мне все равно на чем писать: на C++, на J++, на Паскале или Бейсике, но писать я буду на том, что лучше документировано, имеет большую функциональность, гибкость и распостраненность. Вы много видели книг по .NET, где примеры написаны на паскале? Из 2-х компактов книг по .NET (порядка 400 книг), которые у меня есть ни одной!!!!! Ну и как писать? Программирование это не только увлечение и призвание, но и работа, а работодатель требует результатов. И как выдавать результаты, если к среде разработки надо прикручивать различные дополнительные инстументы, если нет нормальных книг, если среда разработки не имеет большой распостраненности?
Borland нас всех кинула! Delphi больше не лучшая среда разработки и с этим надо смириться!
Аминь.

Ага, исследуем дальше. Оказывается всё не так плохо. Удалось найти как применять WinAPI - оказывается есть модули, отличия небольшие - теперь нет указателей, т.е. вместо PChar используются строки и т.д. Вот так примерно выглядит использованием ShellExecute:

uses ... Borland.Vcl.ShellAPI;
 
procedure TForm2.Button1Click(Sender: TObject);
begin
  ShellExecute(handle, 'Open', 'TOTALCMD.EXE', nil, 'C:\totalcmd\', sw_restore);
end;

А вот так даётся определение самой функции ShellExecute в модуле у Борланда:

function ShellExecute(hWnd: HWND; Operation, FileName, Parameters,
  Directory: string; ShowCmd: Integer): HINST; external;
[DllImport(shell32, CharSet = CharSet.Auto, SetLastError = True, EntryPoint = 'ShellExecute')]

Забавно, не правда ли?


Ещё есть директива компилляции {$Unsafecode On}, которая по логике вещей должна позволять работать с указателями и прочими радостями классического программирования. На деле её применение наталкивается на труднопонимаемые ошибки компилляции, резко усугублённые плохой документацией.

Так скажу сразу - нормального help нет! Т.е. взят некий Html который несомненно содержит некоторые сведения о C#, немного сдобрен статьями по паскалю и это всё! Ни нормальных перекрёсных ссылок, ни привычного и очень любимого "See also", и это даже можно было бы вытерпеть, если бы не страница с мрачным содержимым "No further information is available for this ..." выскакивающая часто и густо на что бы ты не кликнул F1...О примерах кода вообще молчу, кроме нескольких примеров кода на C# ничего не видно, может в сией булке изюм и есть, но у меня не хватило сил доковырять сию булку, что я золушка что-ли?

Вот как выглядит это подобие на help при вызове справки по идентификатору "function":




Можете сами судить - это справка по Дельфи или по С#? Как по мне, то я хоть и привык к примерам везде написанным то на С, то на VB, но хоть родной Дельфи Help радовал тем, что справка всё-таки была по Дельфи, без включения "чужеродных" языков там где в этом не было необходимости.

Сообщение отредактировано: Vit - 13.01.04, 02:19

А какая у тебя версия Delphi 8?

Architect

Сообщение отредактировано: Vit - 13.01.04, 02:07

Build? У меня 7.1.1446.610!

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

Так это Бета, со всеми вытекающими глюками! Тоже самое происходило с Borland C# Builder.
Пока не вышел фмнал, не было ни хелпа, ни кучи настроек, за-то глюки, глюки, глюки.

А что касаемо компонентов, то их уже достаточно много, и я не могу сказать, что чего-то нехватает.
Ставим Component One и полный пекет DevExpress.NET и можно писать почти все, что угодно, более того есть возможность перекомпилировать некоторые компоненты, написанные под D7.

Ага, вот как! Странно, нигде вроде не было написано что это бета... Ладно время расставит всё по своим местам.


Идём дальше. Вот ложка сахара во всю эту бодягу: работа с базами данных не претерпела существенных изменений, по крайней мере BDE и все визуальные контролы для работы с базами данных на месте, простейшее приложение для баз данных удалось склепать мгновенно без каких-либо затруднений:



Одно непонятно, в результате получился exe файл размером 9 килобайт. Так, где-то дурят нашего брата! Опять какие-то библиотеки и пакеты надо поставлять с исполнительным файлом и похоже в большом количестве. Я понимаю что всякие формы и кнопки зашиты в большом количестве в самом .net framework и их вызов это считанные байты, но DBNavigator, до боли знакомый грид, несмотря уже на сам компонент TTable никакого отношения к MS не имеют и никогда не имели. Чудес не бывает, MS наверняка ничего такого в свой framework не включала, а посему пойду изучать всяки там опции компилляции и бродить по многочисленным настройкам.

Сообщение отредактировано: Vit - 13.01.04, 02:41

Ненадо нигде бродить!
Посмотри в uses и все увидишь. Борланд для совместимости создала набор своих неймспейсов, что бы можно было быстро перекомпиливать старые приложения.

Возьми какую-нибудь прогу написанную в D7 и где используется только стандартные, борландовые классы, поменяй в Uses имена модулей на новые неймспейсы по следующему принципу:
модуль Windows заменяем на Borland.Vcl.Windows
модуль ComCtrls заменяем на Borland.Vcl.ComCtrls
и так далее

компилируем
наслаждаемся!

Для того что-бы откомпилированная программа работала на компьютере необходим .NET Framework и все библиотеки. Так что получив exe размером 10К можно туда добавить мегов 60 в которые будет входить:
1. .Net Framework redistributable
2. IE 6 SP1
3. MDAC 2.7
4. Borland .Net framework redistributable
5 библиотеки компонентов сторонних разработчиков

или есть другой вариант, создать сборку в которой будут все необходимые библиотеки, но это не избавляет от необходимости вместе с программой распостранять 1,2,3 пункты, а это все те же 60 мегов

Это понятно (про Uses я уже допёр), непонятно другое (не бить ногами, я в .net новичёк, знаком только с самыми общими концепциями). Эти самые Name Space'ы как я понмаю должны быть где-то установлены, т.е. они суть являются неким подобием пакетов. И полазив по опциям ничего не нашёл - получается включить эти "пакеты" в исполняемый файл нельзя. Теперь возникла куча вопросов:

- Как же распространять тогда программы?

- В каком виде существуют теперь пакеты и как их расапространять?

- Отдельно пункта работы с пакетами теперь нет, хочется понять - поменяна вся идеология, что-то есть в замен, или это временная недоработка в бете?

- Как в отсутствии пакетов устанавливать третьесторонние компоненты?

Добавлено в 13.01.04, 03:05:

Цитата

noiseman, 12.01.04, 21:56
Так что получив exe размером 10К можно туда добавить мегов 60 в которые будет входить:
1. .Net Framework redistributable
2. IE 6 SP1
3. MDAC 2.7
4. Borland .Net framework redistributable
5 библиотеки компонентов сторонних разработчиков

Ну допустим пункты 1..3 apriori не интересуют, поставляются с .Net Framework и естественно что условием работы приложения должна быть установлена эта вся ерунда. Т.е. учитываем, что работаем на будущее и или это будет Longhorn или на имеющейся оси уже будет установлен .Net Framework, который и не захочет ставится не сделав update IE и MDAC, поэтому будем считать что пункты 1..3 есть стандартные. Другое дело пункт 4. Реально есть возможность включить борландовские библиотеки в исполняемый файл? Что-то я такой опции не нашёл. То же самое касается и третьесторонних библиотек, в предыдущих версиях Дельфи они все прекрасно включались в поставляемый файл, что хоть и делало его большим, но заметно упрощало процедуры инсталляции и Update...

Есть книга, которая ответит на 99% твоих вопросов
русское издание: Прогаммирование на платформе Microsoft .NET Framework Автор Джеффри Рихтер
английское издание: Applied Microsoft .NET Framework Programming Author Jeffrey Richter

.NET отличается от MFC и VCL как MFC и VCL от TurboVision! Вроде бы похоже, а ничего общего нет!

Да это возможно! Я не знаю как это делать в Delphi, но в .NET FrameWork SDK есть утилита AL.EXE которая объединяет все необходимые модули в одну сборку!
Неймспейсы лежат по следующим папкам:
%Program Files%\Borland\BDS\2.0\lib
%WINDOWS%\Microsoft.NET\Framework\v1.1.4322
%WINDOWS%\assembly\GAC

Дело не в книге, мне сейчас не краплет... Просто установив новый продукт я сделал быструю и беглую пробежку по разным аспектам, решил тут же поделиться впечатлениями. Я прекрасно понимаю, что .NET сильно и коренным образом отличается от VCL и MFC (про TurboVision вообще молчу), естественно что не смотря на это я вольно или невольно ищу элементы сходства того что есть с тем что было в предыдущих версиях и с тем опытом программирования который у меня есть. Кроме того меня на данном этапе не интересует детальные механизмы реализации всего и вся в .NET, а интересуют вопросы более общего, более абстрагированного от всяких механизмов плана, ответы на которые помогут оценить применимость продукта вообще, всей идеологии .NET в частности и выявить из них, то что поможет обрисовать область применения новых средств и те возможности которые они открывают (или закрывают). Например меня интересуют вопросы:

1) Как распространять приложения написанные на D8?
2) Как писать собственные компоненты и интегрировать их в среду? Какие отличия при разработке компонентов от предыдущих версий дельфи?
3) Насколько легка переносимость созданного .NET приложения на .NET платформу на другой оси, например под Linux?
4) Возможность использования стандартных DLL, ActiveX и т.п. в приложениях на D8 и какие ограничения. Если да, то возможно ли использование .so библиотек под Linux платформой?

1) берем InstallShield DevStudio9 и делаем инсталлятор, правда SP1 интегрируется только с VS, но я думаю что SP2 будет поддерживать Delphi. InstallShield DevStudio9 полностью поддерживает .NET

2) Одним словом здесь не скажешь. Принципиальное отличие состоит в том какой компонент ты пишешь: WindowsForms или ASP.NET! Это разные вещи. Поэтому, что бы понять как надо прочитать вышеуказанную книгу

3) Это по поводу linux http://www.go-mono.com/mono-roadmap.html

4) DLL, ActiveX, DCOM полностью поддерживается .NET но с оговорками. После того как будет реализован .NET под линукс, там будут работать только те прграммы которые написаны под native .NET, а всякие там DLL, ActiveX, DCOM будут в обломе. Что касается .so библиотек под Linux, то я не знаю что это такое

За .NET будущее! Вот сейчас народ парится проблемой: поддерживать AMD64 или нет, а если бы сейчас весь софт был на .NET то и вопроса бы не было

Вообще то вы не правильно ставите вопрос. Бегло глядеть на Delphi 8 безполезно!
Нужно решить пишешь на .NET или нет. Если да, то абсолютно неважно в какой среде и на каком языке.
Теперь можно писать каждый модуль на своем языке. TWinForm1 может быть написан на Delphi, TWinForm2 может быть написан на C#, TWinForm3 - на Cobol .NET, после этого собрать все в один модуль и пользоваться.
Borland написала компилятор Pascal -> IL (Intermediate Language) и накидала среду разработки, а все остальное это .NET Framework. Вот его и надо бегло смотреть.

Я не совсем согласен о полезности/бесполезности. .net framework заняло позицию WinAPI - т.е. некоего низкоуровневого слоя между процессором, железяками и програмной средой. Конечно реализация и идеология .net сильно отлична от WinAPI, да и уровень у этой системы отнюдь не низкий, но в то же время програмная среда остаётся програмной средой и языки программирования пока остаются разными. Даже если функциональность и одинаковая всё равно можно и нужно присматриваться к среде. Вот например есть текстовый файл, его можно создать с помощью edlin, notepad или ultraedit. В конечном итоге будет точно такой же текстовый файл, а работать с помощью ultraedit будет не впрмер приятнее и комфортнее... И щи можно есть алюминевой ложкой и хлебать квас из чугунного котла, а можно серебряной ложкой и чашечку использовать фарфоровую... Удобство инструментов, внутреняя логика языка (во что бы он там не компиллировался в конечном счёте), приятный интерфейс - это нечто гораздо большее чем язык программирования (сухой свод правил, где точку надо ставить и как цикл выглядит), именно поэтому я присматривался и буду присматриваться к различным програмным продуктам, не ограничевая себя сухой констатацией - это .net, значит и смотреть не чего, всё равно всё едино...

Цитата

может таким образом
Борланд пытается перетянуть программистов с продуктов MS, облегчив им переход?

Кабы наоборот не вышло...
(извиняюсь за оффтоп)

Цитата

C300G, 13.01.04, 11:03
Кабы наоборот не вышло...

Известное дело - все хотят как лучше, а получается как всегда...

Сообщение отредактировано: Vit - 13.01.04, 16:41

Ребята Вы долго не думайте, будущее за более удачной архитектурой построения прикладного софта. .нет фрама уже включена как основной компонент в форточки 2003 сервер (котороый у меня и стоит). Лонгхорн это будет более лёгкий релиз той же самой 2003 сервер. Бил Гейтс вовсе не дурак, он собрал себе отличную команду, и уже давно пытается захватить рынок ПО, просто его в 99 году обламали монополией. и он решил действовать по другому принципу.

Цитата

Если Аррарат не идет к Магомету то Магомет пойдет к Горе.

Борланд тоже увидела, что не перейди вовремя на .нет фраму, она кинет сама себя. Вот смотрите простой пример:

Возьмет Микрософт и выпустит следующие форточки без АктивХ, ДКОМ, ВинАпи.

И все Борланд пойдет ко дну вместе с делфи7, Си Бьюлдером в придачу, да ещё и вас с собой потянет как Титаник. Вы не думайте что в Борланд сидят дураки! Они это прикрасно предвидят, просто потом будет намного приятнее писать на старом добром паскале чем на чем-то чужом и незнакомом. И что бы сейчас не возникало обломов типа

Цитата

Нас Борланд КИНУЛА

изучайте .нет фрама.
Я сам всю жизнь работаю с паскалем, потом перешел на делфи сейчас у меня 7-е ентерприз, и за обновлениями я смотрю постоянно. А насчет бьюлда не беспокойтесь официальной презентации, делфи8 исчё не было. А до презентации, нормальных версий не бывает. Была точно такая же история при переходе с д5 на д6-7, много софта не работало, людей охватила паника, ну и выходом оказалось, небольшие исравления сырцом.

Всё что сказано выше мнение лично мое, я не пытаюсь его навязать кому-то, или оскорбить им выше выступавших. Прошу прощение за оффтоп.

Цитата

CeeArrashee, 15.01.04, 05:53
Возьмет Микрософт и выпустит следующие форточки без АктивХ, ДКОМ, ВинАпи.

На счёт этого можно не беспокоится. Я как то пробровал в WinXP запустить виндовую програму написанную для Windows 1.0 (не MS DOS, а именно на WinAPI под первую винду) и она работала! т.е. микрософт продолжает поддерживать API написанные чуть ли не 20 лет назад!

Прочитав это становится не по себе... программировал программировал, а тут раз и рубанули ?..
И вопрос: стоит ли сейчас уже переходить на программирование под .NET платформу, чтобы не остаться позади развития операционок ?
и второй: есть ли уже С# Builder ? и кто его видел ?

Цитата

DeVoid, 17.01.04, 13:16
Прочитав это становится не по себе... программировал программировал, а тут раз и рубанули ?..

Ничего страшного не произошло, как в 1994-1996 годах все перелазили с прерываний DOS на WinAPI - тоже была трагедия, казалось что мир рушится... Теперь надо переползать с WinAPI на .net

Цитата

DeVoid, 17.01.04, 13:16
И вопрос: стоит ли сейчас уже переходить на программирование под .NET платформу, чтобы не остаться позади развития операционок ?

Стоит конечно.

Цитата

DeVoid, 17.01.04, 13:16
и второй: есть ли уже С# Builder ? и кто его видел ?

Есть, я видел. Точно такой-же как этот 8й Дельфи, только язык другой...

Но я думаю С++ остался с++ом ) как бы его не называли, хоть и С# ....

А демо версия, так о чем тогда говорить

Сообщение отредактировано: javas - 19.01.04, 02:03

Цитата

DeVoid, 17.01.04, 17:09
Но я думаю С++ остался с++ом ) как бы его не называли, хоть и С# ....

Вообще-то C# довольно сильно отличается от С++, например отсутстввием указателей.

Самый главный вопрос в том, смогут ли программисты применить свои знания при переходе на .NET платформу.

Цитата

DeVoid, 18.01.04, 06:16
Самый главный вопрос в том, смогут ли программисты применить свои знания при переходе на .NET платформу.

Программист обладает в общем случае следующими знаниями:

1) Знанием синтаксиса языков - очевидно этим пользоваться можно в любой среде
2) Знание конструкций языка - - появление новых конструкций неизбежно, но всё-таки основная часть продолжает быть та что и была
3) Знание алгоритмов и умение их применять, логическое понимание процесса программирования - полностью платформонезависимое знание
4) Знание библиотек, операционной системы, строения и взаимодействия элементов платформы - вот тут основной удар, хотя кое что и остаётся....

Ребята существует проблема! При установке просит установить фраму 1.1, а у меня форточки сервер 2003 там сразу в поддержке стоит фрама 1.1. а установщик д8 прётся с меня и всё равно требует поставить фруму 1.1. качнул с Микрософта, установил, а он всё равно просит фруму 1.1, а без неё ставиться не хочет!

M

Замечание не по теме, здесь обсуждаем не конкретные проблемы, а впечатление от новой версии Delphi 8.

Сообщение отредактировано: Vit - 19.01.04, 13:54

1. Мы отходим от темы: Delphi 8 - первые впечатления
2. .NET это будущее и Delphi 8 реализация среды разработки для .NET
3. Все Delphi 8, которые вы видели - это Беты!!! Со всеми вытекающими
4. Что бы заниматься разработкой под .NET надо знать как минимум следующие языки: C#,C++,VB,J#! Почему?
а) потому, что все они реализованы в VS .NET, а это основная среда разработки приложений .NET на данный момент
б) потому, что теперь компоненты могут быть написаны на любом языке и они будут работать в любой среде, только вот из-за различий в семантике языков есть сложности во взаимодействии компонент написанных на разных языках (пример: перегрузка операторов есть в C#,C++,J#, а в VB и Delphi 8 её нет).
в) 90% примеров в книгах написаны на C#
5. Если сравнивать VS и Delphi 8 Beta, то VS.NET лучше(я пишу на Delphi c 1995 года и у меня не возникло проблем с переходом)!
6. Вернусь ли я к Delphi? Скорее да, но при огромном количестве "но" к Delphi 8!

Цитата

CeeArrashee, 19.01.04, 06:55
Ребята существует проблема

Я обратил внимание, у этой беты нет нормальной документации по deploy... Скорее всего ещё не озадачились. В релизе всё должно быть нормально.

2 Vit

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

Спасибо за отклик.

Цитата

CeeArrashee, 20.01.04, 01:50
Я извиняюсь за нарушения закона форума но какие могут быть впечатления если она ... не ставится.

Я тоже с этим уже ознакомился. Delphi 8 ставится только на Win 2000/XP и более новые. При этом должны нормально пройти ещё:
1) Udpate IE
2) Установка или update .net

Delphi8 аналог C#Builder только паскалевский синтаксис, и наверное будет борландовская добавка неймспейсов, чего нету у C#Builder'a.

Цитата

Technos, 21.01.04, 16:27
Delphi8 аналог C#Builder только паскалевский синтаксис, и наверное будет борландовская добавка неймспейсов, чего нету у C#Builder'a.

Выглядит очень похоже, но C#Builder, если мне не изменяет память, не подерживает VCL

Это как так? А все VCLные классы в билдере реализованы в MFC? Быть не может..

В том то и дело - это не C Builder, это C# Builder и никаких VCL классов он вообще не поддерживает, там есть только классы .net

Понял Сорри

Открепляю тему, вроде все уже прочитали и высказались

Вопросы по Дельфи 8 возникают с завидной регулярностью, народ спрашивает, а что это? а как? а зачем? и т.п. В общем я прикрепляю топик и прошу все общие вопросы по Дельфи 8 обсуждать здесь

первое впечатление...установил я Д8 и жутко она у меня тормазит...(у меня Р3-1000)
...вернулся обратно на Д7...пока новый комп не куплю...

Цитата

И что нам предлагает Borland? Тоже самое, но с отставанием на 2 года?

Где-то краем уха слышал (не могу вспомнить), что .NET - разработка Borland, перекупленная M$ с уловием, что Borland, не сможет ею воспользоваться в течении 2 лет... (или что-то типа того)

2 All
Какие системные требования у Delphi8?
Ск-ко мегов требует на диске?
ПОд какими ОС запускаеться?

А вместе с 7-ой Делфи можно ставить 8-ую??Конфликта не будет?

Цитата

Delphist, 9.04.04, 21:32
Ск-ко мегов требует на диске?

Не много.

Цитата

Delphist, 9.04.04, 21:32
ПОд какими ОС запускаеться?

2000/XP

Цитата

KRUTO, 9.04.04, 23:36
вместе с 7-ой Делфи можно ставить 8-ую??Конфликта не будет?

Нет

А проги такие же большие получаются или нет???

Маленькие. Но запускаться будут только там где установлен NET.

а мне говорили якобы без Net можно и размер 65кб

Цитата

Andrey_Kun, 11.04.04, 11:22
а мне говорили якобы без Net можно и размер 65кб

А когда говорили, случайно не первого апреля?

Чудес не бывает, такого не может быть.

платформа .NET ...платформа .NET...
что енто за штука? Что она даёт?
...И что в неё такого револьюционного?

Цитата

Генерал, 12.04.04, 08:20
...И что в неё такого револьюционного?

Пойди почитай на форуме по .net - лень клавиатуру зря топтать, этот вопрос поднимается чуть ли не каждый день... Может и ничего революционного, так же как WinAPI - самые обычные API - за 20 лет до их появления уже вовсю использовались API самых разных продуктов, но всё программирование под Win базируется именно на WinAPI. Сейчас грядёт революция - всё программирование под Win в недалёком будущем будет базироваться на .net, а так ничего особенного, основные воплощённые идеи были сформулированны более 20ти лет назад, я ещё в 9м классе читал о моделях очень сходных с современным .net (это был 1984 год)

про .NET нашел интересную ссылку:
http://suburg.web.ur.ru/DotNet/index.htm

Цитата

так ничего особенного, основные воплощённые идеи были сформулированны более 20ти лет назад

а сейчас какие есть идеи?...ну чтобы узнать, что нас ждёт через 20 лет? B)

Ещё какаянибудь очередная Net API и прочее

Цитата

Генерал, 12.04.04, 23:23
.ну чтобы узнать, что нас ждёт через 20 лет?

Меня бы вполне устроила и гораздо более приближённая к нам информация, например сводка биржевых нововстей на завтра

Ну вообщем переходить не стоит???

Цитата Andrey_Kun @ 13.04.04, 16:50

Ну вообщем переходить не стоит???

Чего разрабатывать то хочешь? Определишься, вот тогда и решать. По задаче и инструмент.

Цитата

Vit

Цитата

Delphist
ПОд какими ОС запускаеться?

2000/XP

Все XP?
(Professional/Home)

Сообщение отредактировано: Delphist - 17.04.04, 04:44

Все операционные системы с 2000 и новее

А что слышно не про Achitect edition??? На сайте они там не только его расписывают.
А продукт и вправду сырой очень, чего стоит только его установка на несвежую машинку.Пришлось всю информацию в риалтайм в regedit вычёсывать и про фрым-ворк и про ИЕ6.0, хотя на этой тачке уже стоит Студиа-ДотНет и вроде всё уже ставилось.

Цитата

А что слышно не про Achitect edition??? На сайте они там не только его расписывают.

Леший его... Они все денежку стоят, даже Personal . Пиратский покупать не хочется, опять будет сырая бета, как во времена D5. А Architect бери не хочу с сайта, триал на месяц.

Цитата

А продукт и вправду сырой очень, чего стоит только его установка на несвежую машинку.Пришлось всю информацию в риалтайм в regedit вычёсывать и про фрым-ворк и про ИЕ6.0, хотя на этой тачке уже стоит Студиа-ДотНет и вроде всё уже ставилось.

Бывает, что машину до такого состояния доводит Windows Update, который упорно даунгрэйдит версии отдельных компонентов системы по неизвестной науке причине. У меня на 2000 Pro/2000 Server/2003 Server ставилось без проблем.

И немного оффтопика и личного:
1. Стартует на гигагерцовом процессоре и винчестере на 7200RPM долго до неприличия. Как и остальные .NET IDE, впрочем.
2. Памяти кушает порядочно. 256Мб для комфортной работы явно недостаточно, а если ещё в лучших наших традициях на этой же машине держать MSDE...
3. С переходом на .NET пропала возможность загрузки из DFM-ресурсов, теперь весь мусор по установке свойств болтается в коде. Правда, можно свернуть.
4. ECO не оценил. Абсолютно. Только модулей поддержки UML и не хватало, и так рантайм пухнет со страшной силой.

Кстати, почему все молчат про ECO? Кто пользовался, кто собирается?

не понимаю логики borland... dfm хранить в коде... зачем?..
люди! что это вы сырые бетки юзаете?!
подождите месяц, а то и два... и купите пиратский d8 architect...

Цитата

EViL, 5.05.04, 00:20
люди! что это вы сырые бетки юзаете?!

Мы не "юзаем" - мы пробуем, мне например, надо определиться с перспективами разработки некоторых продуктов на пару лет вперёд, поэтому надо присмотреться к средам программирования и определиться со стратегией, причём это напрямую касается того что я делаю сегодня...

Цитата

не понимаю логики borland... dfm хранить в коде... зачем?..

Захотелось им в стиле java/c#...

Цитата

люди! что это вы сырые бетки юзаете?!

Почему сырые бетки? Октан вышел официально в конце декабря, а Architect Trial появился на сайте только ближе к марту. Вероятно, уже вылизанный...

Сообщение отредактировано: sector - 05.05.04, 12:40

ну а вообще, как считают "опробовавшие", стоит ли восюмую покупать?

Цитата

EViL, 6.05.04, 07:07
ну а вообще, как считают "опробовавшие", стоит ли восюмую покупать?

Если собираешься переходить на .net то да.

Три вопроса:
-Как заставить работать в Delphi 8 BreakPoint?(При этом пошагово трассирует,отлаживает)
-Где в настройках можно изменить месторасположение папки "Borland Studio Projects"? Чтоб при Open, он начинал с неё.
-Кто подскажет офицальный номер версии(полной) Delphi 8.

С BreakPoint - разобрался(руские буквы в путях не понимает).
А что по поводу двух оставшихся вопросов?

Во-первых, КАКИЕ БЕТЫ? Д8 официально вышла на Рождество.

У меня стоит (стоял!) Enterprise, но никакого хелпа там нет и в помине! На данный момент она снесена нафиг за ненадобностью (в принципе!). Позорище Борландовское.


VS.NET 2003 рулит однозначно по всем параметрам (даже C#Builder отстой!).

Я не ограничился знакомством с Д8 тырканьем пару часов во все, что попало, а попытался написать новый проект, благо было несрочное ТЗ. Ну, млин, скажу я вам... Во-первых, у меня очень много вопросов к разработчику, начиная с простейшего: а зачем это надо? Но сначала комментарии:
1. Сразу скажу - лично меня, работавшего в делфях с десяток лет во всех версиях, очень раздражает ИДЕ. Тупая привязка к выровненным панелям просто убивает, очень давит на психику задавленность окна кода панелями слева-справа. Не понимаю, зачем занимать огромную область экрана списком компонент, когда раньше все это прекрасно умещалось сверху пиктограммами. И зачем огромный фон для пришитой к нему формы окна? В общем, целиком согласен с теми, кто высказался, что приятные новшества есть только в редакторе кода.
2. Сама библиотека компонент просто изумляет своим набором. Кастрированно-расширенная - самое подходящее определение. От версии к версии в Делфях первое, на что я смотрел - это на умение оптимизировать код компилятором, и всегда тихо радовался, увидев, что сделанный в Д7 экзешник на несколько килограмм легче, чем в Д6. В Д8 же размер файлов чуть ли не в 2 байта далеко не радует, сразу давая понять, что для его поддержки на компах понадобится туева хуча мелкософтовского ПО, которое и будет возмещать "убытки" размера. А оно надо - ставить сотни метров Фреймворков и прочей ерунды ради базы данных? Так что можно забить, пока мелкософт не распространит операционку, в которой все это будет зашито.
3. Тормоза... У меня весьма нехилый третий пень, обожравшийся от оперативки и ресурсов, но даже примитивное действия типа выбора компоненты и установки ее на форму вызывает заметный напряг системы. Что за нафиг?! Что будет, если в проекте полсотни юнитов задействовано, на которых и Д7 начинает подтормаживать? Тут кто-то писал, что скорость нормальная, расскажите конфигурацию своей машины?
4. О самом языке. Фактически, паскалевскими остались только операторы, все остальное взято из ВБ. Сразу возникает подозрение, что мелкософт просто реанимировал вымерший язык, подрубив к нему новую технологию. Так что безработные вэбэшники могут радоваться, а нам остается плакать, потому как прощай интеллектуальные технологии ООП и да здравствует тупой шаг1..шаг10 (утрирую, конечно). И учтите при этом, что человеческого хелпа с примерами на Д7 там нету, подразумевается, что С и ВБ вы уже знаете (ладно с С, как-то часто приходилось, но Бейсик???). Строку превратили в объект, и я долго пытался вообразить логику кода в сравнении с прежним Делфи. Ну, например, если мы объявим переменные а, в, затем а:=10, в:=а, то это будут все равно разные переменные. А если мы создадим два экземпляра объекта с переменными А и В, а затем В:=А, то они будут оба указывать на одно и то же. Возникает вопрос: если строка теперь стала объектом, то по какому механизму происходит присвоение в:=а? По трассировке - как у переменных типов, а по описанию, как у объектов... И подобных неясностей очень много. Сразу обращает на себя внимание стиль интернет-программирования - пользователям дается то, чего хочет программист, а не максимум интерфейса. Классический пример визуализации ведения лога: вставляется ЛистБокс, ему назначается метод на рисовку итемов, для того, чтобы добавляемые строчки отображались в виде "11.02.2004 12:41 | Запуск...ОК", то есть дата/время отделялось вертикальной линией, а все остальное шло за ней. В Д7 такую фигню делают не глядя в пять строчек ручного кода, из которых пару занимает разрезка строки. А в .Нет заметно, что его на это и не рассчитывали - попотев полчаса с непривычным обращением с типом string, мучаешься еще час с заменой старой доброй канвы, а затем выгружаешь Д8 и возвращаешься к старому доброму Д7.
В общем, посношавшись около часа с простейшей программой, отказавшись от целого ряда любимых примочек и привычного стиля, я в конце концов зашел в полный тупик с переделкой своих потомков от стандартного TStream (думаю, таких потомков, умеющих читать/писать строки простым ReadString/WriteString, делал каждый третий делфист). Ну не могу я привыкнуть, что строка нынче - это набор вордов, а не байтов! Юникод - я понимаю, это хорошо, но мне нужна работа на байтовом уровне, а меня ее фактически лишили, оставив парочку тупых ToByteArray! С ВинАпи вообще напряг жестокий, и можешь умереть, пытаясь найти аналоги любимым функциям ожидания и т.д.
А знаете, как я в конце концов вывернулся? Я просто создал новую библиотеку, объявил в ней все классические функции работы со строками и прочими типами, внутри которых, тщательно переводя хэлп на человеческий язык, сделал нетовские вызовы, и теперь код более/менее напоминать нормальный. Возникает вопрос: а какого икса сам Инпрайз этого не сделал? Дел-то на один день.
5. В общем, поняв, что дальше "Хэлло, ворлд" в Делфи 8 писать что-либо бессмысленно, я ее закрыл и забыл, благо с Д7 она никак не перекликается и вместе их держать вполне можно. Простите, но не для уровня моих задач, не для многопоточности, TCP, , сокетов, MIDAS, комплексных запросов к ДБ и красивого интерфейса. Слишком все ограничено. Не для нас это, не для делфистов.

Итак, ключевые соображения:
1. Бессмысленен вопрос типа "А чем Д8 лучше Д7". Это не новая версия, это версия к другой технологии, своеобразной надстройки над Актив-Х. Для тех, кому приходилось писать АХ-библиотечки по просьбе веб-программистов, будет очень понятно. Я такое делал неоднократно, видимых преимуществ не обнаружил. Просто зарегистрированный в системе оле-объект. Хотя, разумеется, правильнее сказать, что для управления сервисами, для тех, кто создавал Сервис-аппликэшны. Хотя для меня хрен редьки не сладе - как показывает практика, даже борландный scktsrvr.exe далеко не сладко работает на некоторых машинах, если его из программы средствами ВинАпи пускать и стопить как сервис.
2. Не нервничайте по поводу устаревания своих знаний. В худшем случае поголовно все нужное для работы нетовских программ будет на всех операционках только через несколько лет, а в лучшем, мнится мне, что и не будет ничего.
3. А мнится мне истчо, что это просто большая афера Мелкософта (или интервенция, правильнее сказать) на оживление Бейсика. Простите, но о какой новой технологии или новом стандарте идет речь, если этот стандарт под ВБ и не имеет ничего близкого к тому, на чем сделана сама Винда? Зато до смешного напоминает работу с интерфейсами в библиотеке типов, аж руки чешутся сравнить с МИДАС или КОРБА (кстати, для тех, кто писал сокетные трехзвенки - в Д8 остался только DCOM со всеми вытекающими проблемами разруливания доступов и т.д.).
4. Безусловно, для Веб-программеров получился большой шаг вперед по компонентам и возможностям. У нас те сотрудники, что занимаются сайтами, просто тихо попискивают от восторга. Предпочитают работать в нетовских Сях, хотя особых различий между ним и средой Д8 не наблюдают (в Д8 можно делать все то же). Ну а для нас, пишуших более сложные проги, .Нет - это прямая кастрация. В нашей фирме роль сайтов - это не слишком удобные в сравнении с возможностями классических программ приемщики информации, за которыми стоят гигантские механизмы, написанные на Делфях. Соотношение примерно 3% к 90% (еще 7% хранимые процедуры на SQL-сервере).

Вот такая вот фигня.

Могу посоветовать книгу "C# для профессионалов" (красный двухтомник, авторы С. Робинсон, О. Корнес, Дж. Глинн). Там очень хорошо в начале 1-го тома описаы особенности С# в .NET Почти все справедливо и для D8. ОЧЕНЬ МНОГО ПОЛЕЗНОЙ ИНФЫ

Спасибо Aleksandr. - очень хороший анализ

Столкнулся с интересной штукой:

Создаю новый проект /File/New/VCL Forms Application
Получаю проект с пустой формой.
Сохраняю его.
Собираю /Project/Build Project1
После сборки заглядываю в папку проекта и вижу:

Project1.exe 1,348,096

Добавляю на форму кнопку (TButton).
Сохраняю, собираю, заглядываю в папку проекта и вижу:

Project1.exe 8,192

Кто-нибудь знает, почему размер файла резко сократился ?
И какого лешего он вообще изначально 1,3 мега "весил" ?

Да, и в самом деле имеет место быть. Очевидно, связано с тем, что просто форма VCL не требует поддержки .Net, а потому все исполняемые вызовы включаются в проект. При добавлении же Net-совместимых компонент вызовы перекладываются на фреймворковское ПО.

Где в настройках можно изменить месторасположение папки "Borland Studio Projects"? Чтоб при Open, он начинал с неё

Ну, для начала измените переменные среды Делфи.

Ну, для начала...

Прежде чем задать вопрос в форуме, я уже все изменил и настроил.
И нет ни где в переменных среды ссылки на %HomePath%\Мои документы\*.....*

Ну, для конца...

Delphi 8, упорно пытается:
а)открыть проект(и т.д и т.п) по пути
%HomePath%\Мои документы\Borland Studio Projects
б)сохранить проект(и т.д и т.п) по пути
%HomePath%\Мои документы\Borland Studio Projects
в)захломить папку
%HomePath%\Мои документы\Borland Studio Projects

Если не трудно Александр, подскажи(а не прикалывайся).

Цитата

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

Можно изменить раскладку окон со студии на "Classic undocked". Впрочем, у меня в 1152х864 всё очень даже нормально влезает

Цитата

И зачем огромный фон для пришитой к нему формы окна?

Это к M$ Designer из состава .NET, борланд просто юзает готовый.

Цитата

У меня весьма нехилый третий пень, обожравшийся от оперативки и ресурсов, но даже примитивное действия типа выбора компоненты и установки ее на форму вызывает заметный напряг системы. Что за нафиг?! Что будет, если в проекте полсотни юнитов задействовано, на которых и Д7 начинает подтормаживать?

Памяти надо поллитра минимум этой игрушке, это точно.

Цитата

Строку превратили в объект, и я долго пытался вообразить логику кода в сравнении с прежним Делфи.

Билдеровцам это не в новинку, не самое страшное.

Цитата

А в .Нет заметно, что его на это и не рассчитывали - попотев полчаса с непривычным обращением с типом string, мучаешься еще час с заменой старой доброй канвы, а затем выгружаешь Д8 и возвращаешься к старому доброму Д7.

Значит, опять тащить внешние компоненты, но какать теперь придётся в GAC.

Цитата

Простите, но не для уровня моих задач, не для многопоточности, TCP, , сокетов, MIDAS, комплексных запросов к ДБ и красивого интерфейса. Слишком все ограничено.

Как сказать... BDE-то есть, сетевые компоненты подождём внешние... Хотя то, что мелкософт со своим .NET пытается упростить работу со своими технологиями (читай: DCOM etc) и напакостить всем остальным, радовать не может.

Цитата

Простите, но о какой новой технологии или новом стандарте идет речь, если этот стандарт под ВБ и не имеет ничего близкого к тому, на чем сделана сама Винда?

Просто ещё один слой абстракции.

Цитата

Вот такая вот фигня.

Весьма неприятно, но хоронить я не стал бы.

Цитата

Aleksandr.

Хочу сказать на счет ВБ.НЕТ (мое личное мгнение) - это уже не старый добрый бейсик (не тот который шаг1..шаг10 ), а неудачный гибрид ВБ, конечно прибавились и "+", но...........
Скорее .НЕТ быстрее умертвит, а не оживит ВБ (и кто сказал, что Бейсик умер?).
А на счет интерфейса, как у Бейсика, так это ж хорошо .

И интересно, кто это сказал Микрософту, что нужны интернет технологии .
Лучше бы: "Котлеты отдельно, мухи отдельно"(или как там?).

Меня волнует вопрос, Д8 умеет работать с unicode? В частности chr() & ord()?

Так а какую версию надо ставить, чтоб там все было?
Architect, интерпрайс...
У меня 1-я и та же версия, что и обсуждалась в начале форума, чего купить то?

Самая полная версия Architect. И не забудь скачать Update 2 for delphi 8.:-)

Да в 8-ой версии Борландовцы сделали полную лажу, правда я ее до конца не изучил

Цитата Garret @ 11.07.04, 11:58

Да в 8-ой версии Борландовцы сделали полную лажу, правда я ее до конца не изучил

Ну не знаю как там Delphi 8 ведет себя при работе в vcl приложениях, а вот при работе с asp.net - просто супер. Я до этого использовал isapi - потом пересел на 7-ю студию и вот с выходом 8 делфей вернулся на родной паскаль. Та же VS только - Delphi . После сервис паков практически никаких глюков не осталось, так - мелочевка одна(куда ж в Delphi без них, неинтересно работать будет ).

Честно разочаровался, прога заточена под .НЕТ и тут недавно купил справочник для Делфи8, так вот на старых окнах есть проблемы с совместимостью.

Цитата

Pred@tor.(07), 15.07.04, 06:09
Честно разочаровался, прога заточена под .НЕТ и тут недавно купил справочник для Делфи8, так вот на старых окнах есть проблемы с совместимостью.

Естественно! Программы под Win95 почему-то не работают под Win 3.1... Странно не правда ли?

На самом деле никто возможность вызыова Win32API не запрещал. В .Net есть такая же подборка программных средств, которая была и в VCL и в MFC. Предположетельно этого хватает. Практически, естественно, нет. Vit приводил кусок кода импортирующий ShellExecute из ShellAPI. Точно также можно импортировать и всё остальное. Так же можно описывать стпуктуры типа SYSTIME и LOGFONT. Проблема в данном случае у меня возникла именно с CALLBACK'ами. Пытался описать структуру WNDCLASSб но тут на этом и запоролся. Теоретически тут должно проёти что-то типа delegate, но попробывать я так и не удосужился...
Слегка эта тема задета в MSDN. Искать надо по слову Invoke.

Цитата

BlackShadow, 16.07.04, 04:47
На самом деле никто возможность вызыова Win32API не запрещал.

На самом деле снимаю шляпу перед ребятами из MS! Я о совместимости... Недавно взял хохмы ради калькулятор из поставки Windows 1.0 и он прекрасно заработал на Windows XP! Прошло 20 лет, сменилось минимум 7 поколений операционной системы, а старые API работают! В своём роде довольно уникальная система... Исходя из этого можно надеятся что ещё лет 20 эти самые WinAPI протянут...

Получается, что .NET - это что-то вроде интерпретатора для IL ? То есть, Delphi8 компилирует в IL, а потом полученный код запускается под интерпретатором, установленным в системе ? Давным-давно (со времён появления первых компиляторов) известно, что откомпилированная программа работает в несколько раз быстрее. Странно, что получилось только в 2 раза, а не больше.
Есть такие области прикладного программирования, в которых хочется выполнить код как можно быстрее. Например, область вычислительного программирования (моделирование физических процессов, поиск делителей чисел Ферма, ресурсоёмкие вычисления в криптографии и т.д.). Неужели кто-то будет использовать код для .NET, когда можно "на халяву" ускорить программу в 2 раза, применив стандартный компилятор ? Поэтому мне кажется, что не стоит говорить о том, что .NET-программирование ПОЛНОСТЬЮ заменит классическое. .NET хорош для тех задач, когда кроссплатформенность (или размер EXE-шника) важнее остального. Но это далеко не 100% всех задач.
Ещё один момент - удобство программирования. Лично мне кажется, что указатели - очень мощный инструмент программиста. Когда я в 1990, имея опыт только в Бейсике, впервые попробовал вкус Паскаля - я однозначно признал указатели самым существенным и удобным отличием (хотя было ещё много чего удобного), и больше про Бейсик никогда не вспоминал. И что теперь ? Return to innocence ?
А что даёт кроссплатформенность ? Возможность одной программы без изменения кода работать на 32-разрядных, 64-разрядных процессорах, телевизионных игровых приставках и программируемых калькуляторах ? На фига это нужно, если и так платформа PC с системой Windows является фактически стандартом де-факто из-за того, что распространена намного более остальных ?
А что делать разработчикам софта, рассчитанного на работу с конкретным hardware-девайсом ? Таких ведь тоже немало. Они пишут прикладную программу плюс кучу драйверов для каждой ОС отдельно и в таком виде распространяют это юзерам. Какой толк им от кроссплатформенности ? Их девайс не будет работать с игровыми приставками и программируемыми калькуляторами. Да и как им вообще вписаться в .NET, если платформо-независимость подразумевает и отсутствие прямой связи с железом ?
А как же разработчикам компьютерных игр ??? Их творения вообще тесно связаны с достижениями индустрии видеоускорителей и быстродействием процессора ? Неужели самой популярной игрой будущего станет Тетрис ?
Конечно, это хорошо, что программа, написанная на PC, сможет работать без изменения кода на каком-нибудь железе типа сотового телефона, но не слишком ли большую цену мы за это платим, отказываясь от многих преимуществ классического программирования ?

WinAPI forever !

(Извиняюсь, если я в чём-то неправ, т.к. опыта в .NET не имею)

to Aleksandr и всем, кто высказывает мнения наподобие этого:

Цитата

Сама библиотека компонент просто изумляет своим набором. Кастрированно-расширенная - самое подходящее определение.

Господа!
Вы просто не поняли, что нельзя сравнивать D8 и D<=7.
D8 - не более, чем просто текстовый редактор для платформы .NET (ну, и еще, транслятор Delphi->IL).

На палитру компонентов вынесены тока визуальные компоненты. Все остальное (многопоточность, TCP, мощнейшие технологии работы с БД и т.д) - находится в библиотеке классов .NET Framework); и все это гораздо мощнее библиотек Delphi<=7!!!

Вывод: прежде, чем программировать под .NET, надо в первую очередь изучать .NET, и только во вторую - конкретную среду программирования (например, D8, C#Builder, или MS Visual Studio .NET 2003).

to CD_Eater
Каждый метод (процедура) .NET перед первым своим вызовом компилируется ПОД КОНКРЕТНЫЙ ПРОЦЕССОР
в ОЗУ, а заетм вызывается неограниченное число раз!!!

Ну а по поводу от отказа от классического программирования... Если так рассуждать, программировать надо даже не на Win32API и C++, а на Asm x86 или вообще в машинных кодах...
Но логика развития неумолима...
Читайте Рихтера и Просиза!

Гость Andr

Ну, если система ещё будет в реалтайме компилировать код перед его вызовом...
Это будет компиляция наспех и без должной оптимизации. К тому же сам язык IL вряд ли поможет процессу оптимизации, т.к. дополнительно наложит свои ограничения. Наверное, Вы слышали, что в новых 64-битных Интеловских процессорах, (которые вот-вот должны заменить современные 32-битные) вся работа по ускорению обработки потока инструкций снята с железа (процессора, то есть) и целиком возложена на компилятор. Я думаю, Вы не будете оспаривать факт, что классический вариант (с исходника Delphi-программы в инструкции процессора при значительном запасе времени на компиляцию) даст заметно более быстрый код, нежели компиляция в реалтайме (изначально имея исходник, искажённый синтаксисом IL, да ещё с добавлением времени компиляции к времени исполнения кода).

А насчёт C++, Asm и машинных кодов - Вы в корне не правы.
Во-первых, всё равно на чём из перечисленного программировать - всё равно программа сводится к вызовам WinAPI-функций, а язык исходника - дело вкуса и удобства.
Во-вторых, Delphi(version <= 7), например, никак не ограничивает возможности программирования на ассемблере. Хочешь - пиши хоть всю программу внутри оператора asm..end. Правда, реально прибегать к ассемблеру есть смысл лишь при написании "узких мест" (обычно - написание своих элементарных графических операций или процедур работы с большими числами). И машинные коды тоже приходилось применять (помню, Delphi 3 неправильно кодировал инструкцию cmpxchg для 32-битных аргументов).

to CD_Eater

Цитата

Ну, если система ещё будет в реалтайме компилировать код перед его вызовом...
Это будет компиляция наспех и без должной оптимизации. К тому же сам язык IL вряд ли поможет процессу оптимизации, т.к. дополнительно наложит свои ограничения.

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

Цитата

А насчёт C++, Asm и машинных кодов - Вы в корне не правы.
Во-первых, всё равно на чём из перечисленного программировать - всё равно программа сводится к вызовам WinAPI-функций, а язык исходника - дело вкуса и удобства.

Видимо, Вы не поняли меня. Я хотел сказать, что .NET - это следущая ступень эволюции программирования на лестнице "машинные коды->ассебблер->структурные языки высокого уровня->объектно-ориентированные языки высокого уровня".
Если же мы пишем на ассебблере, то вызывать функции WinAPI мы уж никак не будем (какой смысл вызывать с помощью асм-ра функции, написанные на структурном языке C?). А вот прерывания вызывать - будем. И это будет быстрее, чем C+WinAPI.
Но это ж не повод отказываться от С+WinAPI!
Поэтому логично предположить, что только ради экономии ресурсов не стоит отказываться от .NET в пользую устаревшей платформы WinAPI.

P.S. IL-язык особых ограничений не наложит - в нем не более 30 типичных ассемблерных иснтрукций. Такой код как раз проще оптимизировать под конкрентный процессор.
Кстати, когда мы компилируем модуль в D<=7, то ведь он сначала компилится в промежуточный объекный код (думается, что он весьма похож на IL), и только потом - в x86.

А эти бесконечные Warnings: Unit 'Borland.Vcl.Forms' is specific to a platform...
Ну понимаю я что Borland.Vcl.Forms специфична... Но если надо! разрабатывать приложения VCL так что ж мне постоянно в Uses`ах писать

 
{$WARNINGS OFF}
uses ...;
{$WARNINGS ON}?

И тот пример со стороками от Aleksandr`а...

И есчо много чего непонятного на первый взглад, особенно в файле .dpr, когда все "+" раскрутить на "-"...

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

to SPrograMMer
VCL. NET создана только для того, чтобы в среду .NET можно было переносить созданные ранее приложения.
А новые приложения надо создавать на базе чистой .NET и, Windows Forms для GUI-приложений, в частности.

И не будет никаких specific to platform...

to SPrograMMer
P.S.
Попробуй {$WARN UNIT_PLATFORM OFF}
А юзать без надобности VCL.NET не надо - она построена, как и прежде на чистом WinAPI.
Это уже не настоящее .NET-приложение, когда вся его библиотека, в том числе и визуальная, постронена на WinAPI...

Delphi, где твои крылья, которые так нравились мне...

В своё время Borland сделала невозможное. Она создала приятную и удобную оболочку для WinAPI. VCL. Она была куда удобней в использовании и надстройке, чем MFC.

Теперь на смену WinAPI пришла .NET. Хотя пришла ли? Спорный вопрос. Не знаю, чем .NET удобней, чем та жа WinAPI+VCL и почему надо ей пользоватся. Меня лично в этом надо ещё убедить.

Но в любом случае D8 ничего нового в .NET не привнесла. И зачем она тогда нужна --- непонятно. RIP. Хотя я думаю надо подождать D9. Как-то так повелось, что нечётные версии у них гораздо приятней и удобней. А на чётных я вообще ничего серъёзного писать не мог.

По поводу .NET. Года три назад к нам в университет приходил Дон Бокс читать лекцию ко концепции .NET. Мне тогда с одной стороны, конечно, понравилось, с другой стороны я понял, что .NET --- одно большое шоу. Это КРАСИВО и ничего больше. На той лекции он всё скакал и сравнивал концепцию .NET с концепцией фильма "Матрица". И у меня сложилось впечатление, что вся .NET спроектирована по мотивам и как дань уважения этому фильму (это не так конечно, но что-то в этом было), чего стоят одни только названия, GarbageCollector там и т.п. Кстати, он тогда недвусмысленно намекнул, что VB --- для дураков, а настоящие индейцы пишут на C#, C++ в крайнем случае.

Так вот, среди всего, что он обещал было быстродействие, которое достигалось как раз JIT-компилятором с MSIL'а. И когда я поработал на VS.NET я понял какая это брехня. Да и всю эту .NET туда же:
Сначала о железе:
Мой AXP-1700+ c 512 метрами памяти за секунду решает довольно сложные м/задачи: может построить интерполяцию куб. сплайнами по 1000 контрольных точек. По крайней мере в секунду это точно укладывается. Проверено. Винчестер за две-три минуты перекидывает фильм с одного своего куска на другой.
Так вот:
Почему, когда я в VS.NET добавляю, например, новую форму в проект, у меня это происходит в течении двух секунд. Что этот мегаоптимизированный-под-мой-процессор код делает?

To BackSlash

Цитата

Delphi, где твои крылья, которые так нравились мне...
В своё время Borland сделала невозможное. Она создала приятную и удобную оболочку для WinAPI. VCL. Она была куда удобней в использовании и надстройке, чем MFC

Да, Дельфи прославилась тем, что сделала самую удобную оболочку для WinAPI.

Цитата

Но в любом случае D8 ничего нового в .NET не привнесла.

И не могла привнести ничего - по определению самой платформы .NET.
D8 нужна только для поддержки старых Delphi-проектов (VCL.NET) и для создания новых теми разработчиками, которые не хотят переучиваться на C#. Правда, они не понимают, что переучиваться все равно придется - т.к. Object Pascal 8 изменен в соответствии с требованиями общеязыковой исполняюшей среды...
Так что уж лучше последовать примеру крутых перцев и программировать на C#.

Цитата

По поводу .NET. Года три назад к нам в университет приходил Дон Бокс читать лекцию ко концепции .NET. Мне тогда с одной стороны, конечно, понравилось, с другой стороны я понял, что .NET --- одно большое шоу.

Ну презентации-лекции у MS всегда попсовые...
Если есть желание действительно изучить .NET и понять, чем же она круче связки WinAPI+VCL, советую почитать следующие книги:
1. Рихтер Дж. Программирование на платформе Microsoft .NET Framework (2-е издание). – «Русская Редакция», 2003. – 512 с.
2. Просиз Дж. Прогрраммирования для платформы .NET . - "Русская редакция", 2003. - 700 с.

P.S. Если напрягает, что в исполняемых .NET-файлах получается промежуточный код, можно скомпилировать их в машинный утилитой NGen.exe из состава .NET Framework SDK (!).

А кто выигрывает при таком развитии событий?

Новая технология!
Завтрашний день!

Кому это нужно?

Не надо сравнивать переход DOS = Win с этой таксказать борьбой WinAPI-.Net

В первом случае- это всетаки шаг вперед, а во втором замена одного другим, причину которой на мой взгляд никто толком не знает. Главная причина, вроде, "Win32Api стал старый и скоро умрет" поэтомы Вы должны купить новую ОС и новый компьютер. Я не могу, МакДональдс какой-то...

Сообщение отредактировано: H.Iglesias II - 28.07.04, 14:44

Цитата Гость Andr @ 28.07.04, 19:32

D8 нужна только для поддержки старых Delphi-проектов (VCL.NET) и для создания новых теми разработчиками, которые не хотят переучиваться на C#. Правда, они не понимают, что переучиваться все равно придется - т.к. Object Pascal 8 изменен в соответствии с требованиями общеязыковой исполняюшей среды...
Так что уж лучше последовать примеру крутых перцев и программировать на C#.

одной из фишек .Net, в которую прямо носом тыкают, является то, что она дает возможность программистам работать над одним проектом и при этом писать на том языке, на котором они привыкли (был бы для него Net-компилятор). Так что насчет необходимости переучиваться на C# это довольно необдуманное заявление.
А насчет крутых перцев, которые программируют только на C#, так это просто

to andrey_pst
Действительно, одно из преимуществ .NET - то, что общая языковая среда (CRL) выдвигает требования к структуре языка, а не к синтаксису, и тогда модули одной и той же программы модно писать на разных языках, и эти модули наконец-то смогут общаться объектно-ориентированно без посредников в лице COM+. То же самое касается и общения различным программ между собой.

Но: C# изначально спроектирован под CRL, а также учитывает всесь негативный и положительный опыт развития остальных языков программирования. Поэтому он концептуально строен.
А другие языки (Delphi, C++, VB, etc.) были изменены в соотвествии с требованиями CRL, а все негативное наследение, связанное с обеспечением обратной совместимости, в них осталось.

Поэтому, на мой взгляд, под .NET оптимальнее программировать на C#.

to H.Iglesias II

Цитата

Не надо сравнивать переход DOS => Win с этой так сказать борьбой WinAPI-.Net
В первом случае - это все-таки шаг вперед, а во втором замена одного другим, причину которой на мой взгляд никто толком не знает.

Переход DOS => Win шагом вперед считают потому, что это очевидно - радикально изменился пользовательский интерфейс.

При переходе WinAPI => .NET принцип организации пользовательского интерфейса остался прежним, но этот переход еще бОльший шаг вперед, т.к. теперь радикально изменена в лучшую сторону внутренняя струтура среды выполнения (аналог ОС) и программного обеспечения.

Цитата

а во втором замена одного другим, причину которой на мой взгляд никто толком не знает

Повторюсь: читайте литературу и документацию, прежде чем делать скоропалительные выводы.

Цитата Гость Andr @ 29.07.04, 11:59

При переходе WinAPI => .NET принцип организации пользовательского интерфейса остался прежним, но этот переход еще бОльший шаг вперед, т.к. теперь радикально изменена в лучшую сторону внутренняя струтура среды выполнения (аналог ОС) и программного обеспечения.

Цитата

а во втором замена одного другим, причину которой на мой взгляд никто толком не знает

Повторюсь: читайте литературу и документацию, прежде чем делать скоропалительные выводы.

Вот это и напрягает.

Программы разве работают плохо, чтобы им выполняться лучше?

Что значит ЛУЧШЕ? Фильмы можно будет смотреть быстрее? Больше расходовать ресурсов будут?

Зачем программы должны теперь исполняться в аналоге ОС, а не ОС?

Согласен, что кому-то из разработчиков это очень даже и клево, здесь даже упоминались конкретно, но большинство кроме геморра очередного не получат ничего. Крупные воротилы от IT срубят бабки,





А ПРОГРАММЫ К СО-ЖА-ЛЕ-НИ-Ю СТАНУТ ХУУУУУУЖЕ!!!!!!!!!!!!!



Я, наверно, ламер в этом вопросе. НО.
А докумментацию пишут по .NET кто?
А продвигает NET кто?
А продает NET кто?
Или ШТО?

Совершенно понятно, что в документации меня будут убеждать, что ЭТО просто СУПЕР-ПУПЕР.

Кто-нибудь в докумментации по MFC встречал описание неправильности этой библиотеки?

Согласен.
Всё это нужно только что бы срубить побольше бабок с конечных пользователей.
Ресурсов всё будет требовать больше --- факт.
Скорость работы не увеличится, ибо никакой JITCer не знает лучше меня как оптимизировать мою программу под конкретный процессор, а при переводе на MSIL теряется куча информации для этого необходимой (имхо).

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

Программировать на .NET надо уметь. Правильно это делать --- сложно. Зато будет полно всяких умников, которые будут считать, что это они делать умеют. => программы действительно станут хуже.

Сообщение отредактировано: BackSlash - 29.07.04, 11:33

Странно слышать заявления типа "WinAPI умрет".
Скажите мне аналог функции WinAPI CreateIoCompletionPort на Net или вообще аналог порта. Или ReadFileEx.
Или AllocateUserPhysicalPages

Моё мнение, где место Net. В России очень распространен продукт 1С Предприятие. Посмотришь на него и задумываешься, зачем он вообще нужен. Вот Net как раз и будет заменять такие продукты. Может быть.

P.S По идее WinAPI должно было умереть, когда изобрели визуальную среду программирования. Сколько лет прошло?

Да и вообще как WinAPI может умереть? Без WinAPI не будет Windows. В WIndows XP/Server 2003 включено приличное количество ноых функций. ЗАявления типа "WinAPI умрет" бессмыслены.

Сообщение отредактировано: Sanek - 31.07.04, 18:35

to H.Iglesias II

Цитата

Я, наверно, ламер в этом вопросе. НО.
А докумментацию пишут по .NET кто?
А продвигает NET кто?
А продает NET кто?
Или ШТО?

Беседуя таким образом, мы можем зациклиться на чистых эмоциях. И ни WinAPI, ни .NET здесь уже будут ни при чем...

to BackSlash

Цитата

Скорость работы не увеличится, ибо никакой JITCer не знает лучше меня как оптимизировать мою программу под конкретный процессор, а при переводе на MSIL теряется куча информации для этого необходимой (имхо).

По этому поводу я опять же советую почитать официальную документацию и хорошие книги по этой теме. Утверждается, что, наоборот, это должно повысить производительность. Хотя на практике это бывает не всегда.
Ну, а если не убедил, то повторюсь (опять зацикливаемся!):

Цитата

to BackSlash
P.S. Если напрягает, что в исполняемых .NET-файлах получается промежуточный код, можно скомпилировать их в машинный утилитой NGen.exe из состава .NET Framework SDK (!)

Цитата

Программировать на .NET надо уметь. Правильно это делать --- сложно. Зато будет полно всяких умников, которые будут считать, что это они делать умеют. => программы действительно станут хуже.

Под какую бы платформу ни программировать, действительно, это надо уметь. Сейчас есть много умников, которы считают, что они умеют программировать под Windows (в частности, полно умников, которые умеют кидать кнопки на формы - и считают, что больше ничего не надо).
Под Windows программировать сложно.
А .NET создан для того, чтобы облегчить программирование! Писать под него программы проще. Но, конечно, придется перед этим напрячься - почитать новые книги, документацию... Ничего совсем уж лего не бывает!

to Sanek

Цитата

Скажите мне аналог функции WinAPI CreateIoCompletionPort на Net или вообще аналог порта. Или ReadFileEx.
Или AllocateUserPhysicalPages

Ну, во первых библиотека классов (FCL) .NET очень и очень богата (более 7000 классов!) - богаче, чем WinAPI, VCL, etc. вместе взятые.
Так что ищущий да найдет. Я не говорю о 100%-х аналогах - платформы-то принципиально разные - относятся к различным поколениям.
Ищущий найдет в FCL средства решения всех возникающих при программировании задач.

Цитата

По идее WinAPI должно было умереть, когда изобрели визуальную среду программирования. Сколько лет прошло?

Визуальное программирование-то изобрели, но оно было не очень естественной надстройкой над WinAPI (VCl, MFC).
Теперь (.NET) визуальное программирование является неотъемлемой частью платформы, и это правильно!:))

Цитата

Моё мнение, где место Net. В России очень распространен продукт 1С Предприятие. Посмотришь на него и задумываешься, зачем он вообще нужен. Вот Net как раз и будет заменять такие продукты. Может быть.

Ну, 1С вообще-то нужен, как и любые другие ERP-системы, для управления предприятием...Другое дело, что такие продукты (как и большинство остальных) лучше делать на .NET'е...

Цитата Гость Andr,2.08.04, 08:44

Ну, во первых библиотека классов (FCL) .NET очень и очень богата (более 7000 классов!) - богаче, чем WinAPI, VCL, etc. вместе взятые.
Так что ищущий да найдет. Я не говорю о 100%-х аналогах - платформы-то принципиально разные - относятся к различным поколениям.
Ищущий найдет в FCL средства решения всех возникающих при программировании задач.

вот именно это и есть полное дерьмо, в которое мы должны вляпаться. 7000 классов. Я представляю сколько там ошибок!
Кому-нибудь надо 7000 классов? Опять же система расчитанная на гипотетический худший случай

Цитата

H.Iglesias II, 2.08.04, 07:46
вот именно это и есть полное дерьмо, в которое мы должны вляпаться. 7000 классов. Я представляю сколько там ошибок!
Кому-нибудь надо 7000 классов?

Помнится был у меня калькулятор Б3-21 - 30 комманд, 4 регистра, стек на 6 комманд и память в 64 полубайт... И никаких ошибок! И на фиг нужны эти новомодные навороты начиная с Z80 с офигенным количеством регистров и комманд...

Да, надо! Мне платят деньги за написанные программы, если есть класс который реализует нужную функциональность то мне выгоднее потратить 2 минуты на его включение в код, чем 2 дня писать самому. Если я буду писать сам то получится быстрее? компактнее? - несомненно, но современные системы не требуют быстродействия! Основные задержки времени - это ожидание выполнения запроса в базе данных, ожидание ответа от удалённых серверов, лимиты сетевого трафика и т.д. Я тестировал свою систему, получилось что ~50% времени тратится на SQL запросы, ~50% времени тратится на ожидание трансфера данных с удалённых (в других городах и странах) серверов, только 1% времени тратится на выполнение моих сотен тысяч строк кода... На фиг мне его оптимизировать, ну перепишу я всё на ассемблере, потрачу не один год и получу выигрыш в быстродействии в пол процента? Добавление нужного индекса к таблице или небольшое кэширование запросов может дать сразу выигрышь в 10%-20%... А вот если будут готовые классы для реализации той или иной функциональности, то я готов их применять в ущерб быстродействию дабы увеличить скоторость разработки, читабельность кода и т.п. "Кому это надо" говорят обычно люди которые считают высшим пилотажем программирования написать бесполезную демку в 64K и впихнуть туда как можно больше спецэффектов, если же заниматься серьёзными программами для бизнеса, а не утилитами, то применение третьесторонних библиотек, классов, уже готовых решений и т.п. насущная необходимость, а не блаж

Сообщение отредактировано: Vit - 02.08.04, 14:33

to Vit

Цитата

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

Несомненно!

H.Iglesias II
вот именно это и есть полное дерьмо, в которое мы должны вляпаться. 7000 классов. Я представляю сколько там ошибок!
Кому-нибудь надо 7000 классов?
Vit правильно считает, что сторонние компоненты нужны...
И гораздо логичнее, если эти компоннеты имеют единую структуру, идеологию. Это .NET!
Гораздо хуже, когда мы имеем WinAPI, надстройку VCl над WinAPI, сетевые компоненты в Delphi сторонние (Indy) и множество других библиотек, несовместымых между собой и имеющих разную идеологию! Общее количество классов там будет тоже 7000. Вот где ошибок, как говна!
Уж лучше единая библиотека .NET, имеющая единую идеологию.
А если будут ошибки там... Библитека классов .NET - это еще не среда выполнения. Ошибки в библитеке легче исправлять, если она единая, бабай!

Цитата Гость Andr,2.08.04, 18:20

to Vit

Цитата

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

Несомненно!

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

Я не вижу смысла в том универсализме, который мне обещают.

Цитата

H.Iglesias II, 2.08.04, 14:05
Я не вижу смысла в том универсализме, который мне обещают.

Смысл есть... Например VCL высвобождает огромное количество времени при разработки приложений, вместо рисования кнопок можно сосредоточится на алгоритме... Ничего плохого в том что подобная библиотека сделана на системном уровне не вижу, хотя реализация мне и не очень нравится. Ещё этот универсализм позволит выполнять один и тот же исполняемый файл и в Win и в Lin и в Mac и на больших машинах, тоже ничего плохого в этом нет... Да для написания системных утилит и драйверов такая библиотека на фиг не нужна, но 95% программирования это не утилиты и драйвера, а клиент-серверные приложения для баз данных и разработка Web приложений и сервисов, и как раз их написание при использовании .net облегчается

Я вижу, что насчет .NET каждый остается пока при своем мнении.

Подведем резюме:

1. Тема о Delphi 8 for .NET свелась к обсуждению .NET.

2. Из этого следует одно из преимуществ .NET - независимость разрабатываемых программ от среды разработки. И это правильно!

3. D8 нужна для:
3.1. поддержки старых проектов;
3.2. создания новых разработчиками, которые не хотят переучиваться на новый язык;
3.3. для использования в новых проектах Borland'овских разработок (ECO, BDP.NET, ETM, etc.)

Модераторам: наверное, пора закрывать тему...

Значит так, "СТРАШНО" ужаснувшись что "WinAPI умрет" начал изучать это самое .Net ...
Впечатление не очень хочу сказать. Там действительно ( в книге ) говориться, что тепереь С программисты и VB программисты смогут объединиться не переучиваясь писать совместные проекты благодаря... Ну мы отвлеклись. Насчет структуры языка и вообще чтот можно при программировании использовать было сказано следующее: (основной упор давался на VB, т. к. там такого раньше не было) появились стуктуры (по паскалевски - записи), перечисления и прочее... Смотрю и думаю, действительно VB программистам (коим я сам был 4 года назад) придется подзадуматься над этой самой структурой языка, НО В DELPHI, а точнее в Паскале все это было уже давным давно, все эти клссы, с наследованием, полиморфизмом и инкапсуляцией, и т. д. и т. п. В общем из этой области я ничего нового не узнал. Поехали далее: простанство имен. Вот эти самые 7000 классов и с одной стороны попугивают чутка. Хотя многое из них (если не всё) есть в WinAPI. Получается, что это просто старый пирог, завернутый в новую оболочку. И какой из этого + ???
Другая сторона медали. Я понимаю, что теперь я могу например с С прогаммером писать один проект... Может быть и плюс... Но вот быстродействие, как уже было сказано выше, не ухти.
В общем мое сугубо личное, ни кого никуда не втаптывающее, мнение таково:

на каком языке писали, на том и продолжайте писать. Действительно WinAPI не умрет, а эти новые технологии .Net еще надо подумать новые ли они...
Про D8 я временно забываю, возвращаясь к D7...
Всем удачи!!!

SPrograMMer

Хотелось бы пополемизировать по поводу последнего поста.

Понятно, что и раньше было в природе ООП, записи и т.д.
Дело не в этом, а в том, что в существующие языки эти прогрессивные штуки вписывались с теченеим времени, зачастую нарушая логику языка.
А в C# все это объединено очень и очень логично и стройно.

Цитата

на каком языке писали, на том и продолжайте писать.

в Delphi 8, например, в соответствиями CRL поянвились такие штуки, как:
- перегрузка операторов (!);
- записи со свойствами и методами (!);
- секции strict private и strict protected в классах (традиционные секции private и protected в Object Pascal не соответствуют принципам ООП в том смысле, что доступ к их элементам может получат кто угодно, находящийся в том же модуле);
- многое другое.

Вывод: на мой взгляд, лучше изучать спроектированный с учетом всего опыта программирования новый язык C#, чем изучать все нововведения в Delphi language, VB, etc...

Цитата

Поехали далее: простанство имен. Вот эти самые 7000 классов и с одной стороны попугивают чутка.

Понятие пространства имен - это одно (модульность), а 7000 классов - это другое (библиотека типов платформы).

Цитата

Хотя многое из них (если не всё) есть в WinAPI. Получается, что это просто старый пирог, завернутый в новую оболочку. И какой из этого + ???

+ в том, что библиотека типов (FCL) в отличие от WinAPI, развивавшейся по принципу латания дыр, спроектирована с нуля, с учетом накопившегося опыта. И она объекно-ориетированная.
И еще: в платформу включено понятие исключительных ситуаций (exception).

Теперь не будет неестественных ситуаций, когда, программируя на Delphi, надо обрабатывать exception при использовании VCL, и обрабатывать код ошибки при использовании API-функций.

Цитата

а эти новые технологии .Net еще надо подумать новые ли они...

Действительно, стоит подумать... Что такое Delphi 2-7? Не совсем естественная объекно-ориентированная (в том числе визуальная) надстройка над уродливой WinAPI.
Этим-то и прославилась Delphi, что это самая лучшая настройка (это действительно так)...
В Мелкософте подумали над этим и фактически создали платформу разработки и выполнения программ, не требующую надстройки от сторонних производителей.
На мой взгляд, в это нет ничего прохого, наоборот, это хорошо!

Цитата

Гость Andr, 4.08.04, 21:39

Цитата

перегрузка операторов (!);

Возможно + даже большой! Хотя Паскаль такой как он есть такового не видывал, хотя если это надо бы было для него это могло появиться еще с незапямятных времен, т. к. в с++, это есть стандард, ну так чего ж тогда этого не было раньше!? - строной С попахивает

Цитата

записи со свойствами и методами (!);

И на кой ... они появились, чем теперь Record отличается от Object и Class?
----------------
То что .Net объектно-ориентированная - немного радует, поддержка Exception - вроде тоже, но все же изучать заново, то что уже есть...

To SPrograMMer

Цитата

Цитата

записи со свойствами и методами (!);

И на кой ... они появились, чем теперь Record отличается от Object и Class?

Паскаль, как и большинство языков программирования претерпевал изменения, добавление новых возможностей, и т.д.

И сейчас то же самое, только в случае с D8 нововведения надо рассматиривать не с точки зрения необходимости добавить что-либо в Паскаль, а с точки зрения приведения Паскаля к требованиям общеязыковой исполняющей среды .NET.

В .NET все данные - объекты (в качестве первоначального предка выступает System.Object). По крупному все типы объектов делятся на 3 группы:
1. Фундаментальные типы данных (целые и вещественные числа, булевы переменые, строки и т.д.). Они определены в пространстве имен System разработчиками .NET.
2. Классы. Тут все понятно - ООП в классическом виде.
3. Если есть необходимость иметь "статический" объект без необходимости наследования, можно использовать структуры (struct и record в терминологиях C-подобных языков и Pascal соответственно). Так у структур (записей) появились свойства, методы, секции private и public.

И все это очень логично... если использовать специально разработанный под это дело язык C#. Или VB.NET (это на самом деле не Basic и даже не VB, а урезанный C# с синтаксисом VB).

В случае с Delphi действительно возникает много вопросов из-за неестественного объединения идеологий Delphi и .NET в одном флаконе.
Из этого следует:
1. Если планируется писать программы под .NET, то сначала надо изучать .NET, и только потом - конкретные среды разработки и языки программирования.
2.

Цитата

D8 нужна для:
- поддержки старых проектов;
- создания новых разработчиками, которые не хотят переучиваться на новый язык (но, как видим, переучиваться придется!);
- для использования в новых проектах Borland'овских разработок (ECO, BDP.NET, ETM, etc.)

Другое дело, насколько перспективна сама .NET. На мой взгляд, есть основания считать, что .NET в ближайшие годы станет основной платформой разработки и выполнения ПО.

Цитата

Если я буду писать сам то получится быстрее? компактнее? - несомненно, но современные системы не требуют быстродействия! Основные задержки времени - это ожидание выполнения запроса в базе данных, ожидание ответа от удалённых серверов, лимиты сетевого трафика и т.д. Я тестировал свою систему, получилось что ~50% времени тратится на SQL запросы, ~50% времени тратится на ожидание трансфера данных с удалённых (в других городах и странах) серверов, только 1% времени тратится на выполнение моих сотен тысяч строк кода...

Несомненно в этом случае на быстродействие надо обращать мало внимания. А ты не задумывался, что за теми 50% тоже прячется код, от которого как раз требуется быстродействие и пренебрегать этим не стоит. Как говориться, по задаче свой инструмент.

2 Гость Andr: какая разница, как развивался язык? Непонятно, чем С# логичнее Delphi. Что такого в C# очень стройного и логичного? Если посмотреть с другой стороны - так это на самом деле урезанный С++)

Кстати, я порылся в библиотеке, и нашел порт завершения i/o: System.Threading.ThreadPool.
Вот функция:

 
public static bool BindHandle(
   IntPtr osHandle
);

Цитата

osHandle - An IntPtr that holds the handle. The handle must have been opened for overlapped I/O on the unmanaged side.

Что бы это значило: "must have been opened on the unmanaged side"? И где нам создавать этот хэндл?

Цитата

+ в том, что библиотека типов (FCL) в отличие от WinAPI, развивавшейся по принципу латания дыр, спроектирована с нуля, с учетом накопившегося опыта. И она объекно-ориетированная.
И еще: в платформу включено понятие исключительных ситуаций (exception).

Во-первых, WinAPI развивалось не по принципу латания дыр, а по принципу добавления новых возможностей в систему. И ЛЮБАЯ система будет так развиваться (если вообще будет). Пройдет время, добавятся новые классы в FCL. И что, библиотека станет хуже? Во-вторых, "с нуля" библиотеку проектировать просто не могли, так как опирается она на тот же WinAPI, что заметно по присутствию классов-оберток системных объектов. В-третьих, исключения в Windows существуют давно. SEH, по-моему, был в Windows 95, так что ничего нового здесь нет.
Короче, как сказали выше, Макдональдс сплошной. Просто ещё одна большая библиотека.

to Sanek

Цитата

какая разница, как развивался язык? Непонятно, чем С# логичнее Delphi. Что такого в C# очень стройного и логичного? Если посмотреть с другой стороны - так это на самом деле урезанный С++

Чтобы с исчерпывающей ответить на эти вопросы, не хватить места здесь. Надо научную статью писать. Почитай лучше литературу и другие источники (лучше побольше - для возможности сравнивать).
Замечу только, что C# - это не урезанный C++. По синтаксису C# на 60% - C++, на 35% - Java, на 5% - Pascal.
Но это синтаксис. Важна же структура языка. И с этой точки зрения C# - новый язык, строектированый с учетом всего опыта и свободный от негативного груза обратной совместимости.

Цитата

Во-первых, WinAPI развивалось не по принципу латания дыр, а по принципу добавления новых возможностей в систему.

Добавление новых возможностей - это само собой...
WinAPI проектировалась не очень структурированно и без учета того, что возможно, будет добавлено в нее после.
В итоге в результате развития слишком много ерунды в угоду обратной совместимости (как и в Delphi language, кстати).

Цитата

Во-вторых, "с нуля" библиотеку проектировать просто не могли, так как опирается она на тот же WinAPI, что заметно по присутствию классов-оберток системных объектов.

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

Цитата Гость Andr @ 10.08.04, 12:44

to Sanek

Цитата

.NET предусматривает реализацию не только под Windows, а во многих системах.

В каких ?

to andrey_pst

Цитата

Цитата

NET предусматривает реализацию не только под Windows, а во многих системах.

В каких?

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

В будущем MS на целена на выпуск Pure .NET-операционок.

Вообще MS планировала открыть полную спецификацию на .NET после окончательной доработки и передать все права широкой общественности. Не знаю произошло ли это уже. Скорее всего это произойдет после выхода .NET 2.0.

ссылку на "mono" можете дать ?

to andrey_pst

http://www.mono-project.com

Цитата

What is Mono?™
Mono is a comprehensive open source development platform based on the .NET framework that allows developers to build Linux and cross-platform applications with unprecedented productivity.

Mono's .NET implementation is based on the ECMA standards for C# and the Common Language Infrastructure.

Sponsored by Novell and led by Miguel de Icaza, the Mono project has an active and enthusiastic contributing community. Mono includes both developer tools and the infrastructure needed to run .NET client and server applications.

Mono includes a compiler for the C# language, an ECMA-compatible runtime engine (the Common Language Runtime, or CLR),and class libraries. The libraries include Microsoft .NET compatibility libraries (including ADO.NET and ASP.NET), Mono's own and third party class libraries.Gtk#, a set of .NET bindings for the gtk+ toolkit and assorted GNOME libraries can be found in the later. This library allows you to build fully native Gnome application using Mono and includes support for user interfaces built with the Glade interface builder. Furthermore, Mono's runtime can be embedded into applications for simplified packaging and shipping. In addition, the Mono project offers an IDE, debugger, and documentation browser.

If you have questions about the project, read the project launch statement or visit our list of Frequently Asked Questions.

For details on the project's future direction, read the roadmap, and download Mono 1.0.

Цитата

Чтобы с исчерпывающей ответить на эти вопросы, не хватить места здесь. Надо научную статью писать. Почитай лучше литературу и другие источники (лучше побольше - для возможности сравнивать).
Замечу только, что C# - это не урезанный C++. По синтаксису C# на 60% - C++, на 35% - Java, на 5% - Pascal.
Но это синтаксис. Важна же структура языка. И с этой точки зрения C# - новый язык, строектированый с учетом всего опыта и свободный от негативного груза обратной совместимости.

Много красивых слов и всё. Найдите хотя бы на 35% отличий Java от С++

Цитата

WinAPI проектировалась не очень структурированно и без учета того, что возможно, будет добавлено в нее после.

Голословное утверждение. И, по-моему, не правильное. Если часто работать с WinAPI, то можно заметить, сколько там параметров "reserved", а также множество параметров-флагов, в которых пока-что можно определить только один флаг. Так что WinAPI - не просто набор функций, слепленных на голую руку.

Цитата

В итоге в результате развития слишком много ерунды в угоду обратной совместимости (как и в Delphi language, кстати).

И что? Ну лежит там где-то функция OpenFile в библиотеке, и что, от этого тяжко что-ли.

Цитата

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

Ок. Смотрим класс System.Threading.Thread.
Методы Suspend, Resume. Интересно, как они это будут реализовывать в системах, где нет приостановки потоков (если я отстал от жизни, и в Posix включили приостанов потоков, то сразу так и скажите).
Так же непонятно, как будут синхронизироваться процессы через mutex'ы, и куда денется System.ServiceProcess нэймспэйс, и где же всё-таки создавать на unmanaged side дескриптор с флагом OVERLAPPED например в Linux? Там ещё ОЧЕНЬ много такого. Интересно бы на всё это посмотреть, но качать mono нет возможности.

.NET изначально проектировался под Windows. Несмотря на все заверния, что это не так.

P.S. Откройте .NET Framework SDK и посмотрите любой класс или метод. Внизу надпись: Requirements. Как эту библиотеку можно назвать независимой от WinAPI, когда отдельные методы классов зависят от версии Windows.

Сообщение отредактировано: Sanek - 10.08.04, 19:38

Цитата

Гость Andr, 10.08.04, 11:08
Вообще MS планировала открыть полную спецификацию на .NET после окончательной доработки и передать все права широкой общественности.

Ага. Конечно. Она это очень любит.

.NET --- это хорошо. Это идея, не новая, но реализация которой необходима была уже давно. НО НЕ ОТ Microsoft! Для них это деньгогребущая машинка.
Эту вещь должен был разрабатывать некий консорциум типа W3C.

Цитата

Гость Andr, 8.08.04, 07:37
В .NET все данные - объекты (в качестве первоначального предка выступает System.Object). По крупному все типы объектов делятся на 3 группы:
1. Фундаментальные типы данных
2. Классы. Тут все понятно - ООП в классическом виде.
3. структуры

У меня вопрос:
Есть ли в ней метаклассы (типа TClass) и массивы?

to BackSlash

Цитата

Есть ли в ней метаклассы (типа TClass) и массивы?

Все массивы неявно порождаются от типа System.Array, который является наследником System.Object:

Цитата

Array Class
Provides methods for creating, manipulating, searching, and sorting arrays, thereby serving as the base class for all arrays in the common language runtime.

For a list of all members of this type, see Array Members.

System.Object
System.Array

[C#]
[Serializable]
public abstract class Array : ICloneable, IList, ICollection,
IEnumerable

© .NET Framework SDK Documentation version 1.1.0.

Кстати, перечисляемые типы там тоже есть (в отличие от Java).
Еще интересная особенность: в .NET есть класс для реализации битовых флагов. Кроме битовых флагов это еще и прекрасная альтернатива множествам.
На счет метаклассов не знаю.

to Sanek

Цитата

P.S. Откройте .NET Framework SDK и посмотрите любой класс или метод. Внизу надпись: Requirements. Как эту библиотеку можно назвать независимой от WinAPI, когда отдельные методы классов зависят от версии Windows.

Это справка по Microsoft .NET Framework 1.1 - конкрентная версия под Windows.
Это не доказательство, что .NET проектировалась тока под Windows.

Меня эта тема сильно задела, потому что в последнее время люди часто стали пользоваться псевдоуниверсальными продуктами, облегчающими написание программ. Например, у нас на фирме пытались сделать программу с многооконным интерфейсом и панелями инструментов с помощью Macromedia Director. И ничего, кроме головной боли это не принесло. На Дельфи это проще и быстрее.

С .Net мне кажется тоже самое. Оно предназначено для довольно узких и специфических задач (вроде бухгалтерских приложений). Это тоже самое, что писать HTML с помощью визуального редактора. Может на распечатке оно выглядит точно также, но для интернет-сайтов такого никто (насколько мне известно) не делает.

Мои выводы таковы:

1) Warcraft с помощью .Net не напишеш
2) для Микрософт это в первую очередь бешеные бабки, поскольку заменить стандартное API было бы гораздо сложнее и оно придумало надстройку к нему
3) .Net многим пригодится, но это не значит что API умрет и нужно быстро переучиваться. Думаю, что переучиваться пока вообще не нужно.
4) если Микрософт рискнет выпустить систему, где с API работать будет невозможно или трудно (полностью от него к счастью избавиться невозможно), то это приведет к гибели ОС Windows (она перестанет быть массовой, а главное домашней), и по-этому оно этого не сделает.

... ну и ПК соответствующий нужен?
я думаю, что П3 700Мгц х 256МБ ОЗУ уже не пойдет

The Next Delphi Release (9.0) - "DiamondBack" Codename
http://bdn.borland.com/article/0,1410,32499,00.html

А еще насчет Delphi8 for .Net framework:
D6-D7 (не знаю насчет D5) было такое ЗАМЕЧАТЕЛЬНЕЙШЕЕ свойство как ссылка, на объявление, т. е. подводишь курсор мыши к идентификатору, например TControl, нажимаешь клавишу Ctrl жмешь мышой и,... о чудо волшебства, перед нами есть объявление этого самого TControl`а, а при желании можно посмотреть еще и его реализацию...
Ну так вот такое волшебство в D8 вроде бы сохранилось, но только в пределах собственных модулей и программ. Как реализован, тот же самый LinkLabel например - ???? (хотя вроде бы понятно, что от Label`а и т. д. и т. п.) Но все же у Microsoft снова политика закрытости кода - усе у DLL и фиг чего от ниг дабъешьси, кроме названия ф-ции, даже параметры помоему не вытащишь...

to SPrograMMer

Цитата

D6-D7 (не знаю насчет D5) было такое ЗАМЕЧАТЕЛЬНЕЙШЕЕ свойство как ссылка, на объявление, т. е. подводишь курсор мыши к идентификатору, например TControl, нажимаешь клавишу Ctrl жмешь мышой и,... о чудо волшебства, перед нами есть объявление этого самого TControl`а, а при желании можно посмотреть еще и его реализацию...

Эта прекрасная возможность появилась еще в D4. (Сам с начал программировать с D3).

Действительно, это очень круто. Меня эта возможность помогла в двух вещах:
а) в понимании работы VCl/RTL (соответственно грамотно использовал эти библиотеки);
б) написанию своего кода в хорошем тоне (в стилистике Borland).

Цитата

Ну так вот такое волшебство в D8 вроде бы сохранилось, но только в пределах собственных модулей и программ. Как реализован, тот же самый LinkLabel например - ???? (хотя вроде бы понятно, что от Label`а и т. д. и т. п.) Но все же у Microsoft снова политика закрытости кода - усе у DLL и фиг чего от ниг дабъешьси, кроме названия ф-ции, даже параметры помоему не вытащишь...

Ну, никто же не возмущается, что Microsoft долгое время не открывала исходники Win32 API... (сейчас открыта только часть, и то очень условно).
Так нечего возмущаться, что и исх. код .NET закрыт. Достаточно того, что есть открытая спецификация на .NET. А на C# вообще есть международный стандарт - ссылка на стандарт здесь: C# - стандарт

И еще. Повторюсь, но Ваше замечание, to SPrograMMer лишний раз подтверждает мысль, что изучать D8 саму по себе не следует. Если при программировании на D8 использовать только библитотеку классов .NET, и не использовать VCL.NET (для поддержки старых проектов), то все рано придется изучать .NET и то, как Object Pascal 8 приведен к требованиям общеязыковой спецификации .NET. Уж гораздо проще изучить сразу .NET/C#.

Не хотелось бы никого обидеть, но на мой взгляд, те, кто критикует .NET, просто неспособны (или не хотят) изучить внимательно новую платформу (почитать хорошую литературу - Рихнера, например, или в справку заглянуть) и понять действительно ее прогрессивность и актуальность не только для сегоднящнего дня, но и для всего программировнаия в целом.

Интересно как реализовывать защиту от копирования под .NET. Нужно же будет получить от компушки, на пример, заводской номер HDD и BIOS. Что будет с упаковщиками EXE? Непонятно...

2 To be or .NET to be?

Цитата

Интересно как реализовывать защиту от копирования под .NET. Нужно же будет получить от компушки, на пример, заводской номер HDD и BIOS. Что будет с упаковщиками EXE?

Если эти вопросы действительно интересны, то займись ими и изучи. А не задавай вопросы типа:

Цитата

Непонятно...

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

Цитата Гость Andr @ 19.08.04, 00:53

И еще. Повторюсь, но Ваше замечание, to SPrograMMer лишний раз подтверждает мысль, что изучать D8 саму по себе не следует. Если при программировании на D8 использовать только библитотеку классов .NET, и не использовать VCL.NET (для поддержки старых проектов), то все рано придется изучать .NET и то, как Object Pascal 8 приведен к требованиям общеязыковой спецификации .NET. Уж гораздо проще изучить сразу .NET/C#.

Нет уж, я как-то пробовал C изучать, очень это было давно, и неправда, но тем не менее я еще не знал что Delphi существует, ну так вот еще простейшее C (не С++, нет) уже настолько ГЛУМНОЕ оказалось, что недавно пробовал что-то программить уже на C++ с использованем ООП, см. темы в разделе C, около месца назад, ну так вот ТО ЧТО КОНСТРУКТОРЫ И ДЕСТРУКТОРЫ в С++ (наверное и в С#) вызываются авторматом (черная магия прям!!!), и еще много чего, чего в паскале было очень просто и более понятно в С++ настолько заглумлено!!!, хотя не утверждаю, что Паскаль лучше, если в этом всем разобраться, то может быть С (С#) и лучше, но тем не менее в С (C#) все, или почти все и не только в синтаксисе... ну очень заглумлено.
В общем моё мнение таково: несмотря на появление новой технологии .Net и соответственно "нового" языка для этой технологии, несмотря на это (и я уже в этом убедился) можно усе перевести с одного языка на другой (лишь бы ДОКУМНТАЦИЯ была по РУССКИ!!! (для меня это почти, что основное требование... , к сожелению...)). Многоие примеры из книги, написаной для VB`шников и C#`шников по .Net, удалось мне перевести на Delphi №8...

Сообщение отредактировано: SPrograMMer - 23.08.04, 10:43

Цитата

>> Конечно, когда появляется новый продукт, прежде чем делать выводы, надо его изучить. А если нет желания/возможности/способности его изучить, то и нечего хаять...

Слушай, Andr, я и не думал хаять свой любимый Delphi . Но прежде чем отдавать за него кучу денег, хотелось бы разобраться, что там случилось с D8. Посмотри какие здесь о нем нелестные высказывания! Такого не было даже с D4.

Цитата To be or .NET to be? @ 24.08.04, 04:25

Слушай, Andr, я и не думал хаять свой любимый Delphi. <...> Посмотри какие здесь о нем нелестные высказывания! Такого не было даже с D4.

ТОЧНО!!!
и я свой любимый D не брошу, несмотря на

Цитата

Изучайте C#!!

2 SPrograMMer
Все равно, что я бы сказал, учась в 5-м классе
"Ну и что, что все уже программят на MS VC++, все равно я свой Basic4.5 не брошу"
Нужно программить на том, чего требует время. Если ВСЕ будет построено на .Нет, то в любом случае придется программить под него. Если дельфя все-таки отдастся со временем микрософту, то придется программить на C#. Тут уж никуда не деться... если конечно не хочешь оставить эту профессию

Цитата

Voice, 24.08.04, 08:23
Нужно программить на том, чего требует время.

Не так всё грустно, технологии и языки не умирают так уж быстро. Ещё можно встретить работу и не алголе, фортране или коболе, а ведь это языки начала семидесятых...

Ето точно! Я с ребятами до сих пор развиваем несколько программ для DOS. Оказывается есть еще такая потребность. А что, простота и надежность DOS великолепны.

Цитата

"Нужно программить на том, чего требует время. Если ВСЕ будет построено на .Нет, то в любом случае придется программить под него. Если дельфя все-таки отдастся со временем микрософту, то придется программить на C#. Тут уж никуда не деться... если конечно не хочешь оставить эту профессию "

Фи, чихал на C# и всю гребаную новую моду. Я сам ставлю заказчику условия, четко их обосновывая. Под .NET я буду работать если посчитаю, что это действительно так удобно и надежно. Здесь кто-то настойчиво предлагает купить и почитать книжки про эту хрень, но, если это такая хорошая идея, то и без них в общих чертах должна быть понятна ее идея. Конкретно: какую популярную программу уже перевели под .NET и что это дало хорошего?

Цитата

To be or .NET to be?, 24.08.04, 19:33
Конкретно: какую популярную программу уже перевели под .NET и что это дало хорошего?

Тут могу возразить

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

2) .net удобен для разработки нового, так как предоставляет довольно много удобств, по крайней мере если сравнить например написание простейшего оконного приложения на WinAPI и .net - на .net это делается проще.

3) Область применения. Не в популярных программах дело.... Как-то сложилось впечатление что если на языке программирования нельзя написать драйвер или вложить навороченную графику в 64 Kb, или для утилитки типа калькулятора надо придавать framework офигенного размера то это уже неправильный язык. Реалии таковы, что львиную долю програмиской работы составляет отнюдь не написание драйверов, операционок и програм для смены обоев на десктопе, а бизнес приложения и работа с базами данных - вот именно на эти задачи и нацелен .net - а популярных програм в этой области не сыскать... по крайней мере на домашний комп их мало кто ставит

Цитата Vit @ 25.08.04, 06:06

Тут могу возразить

12) .net удобен для разработки нового, так как предоставляет довольно много удобств, по крайней мере если сравнить например написание простейшего оконного приложения на WinAPI и .net - на .net это делается проще.

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

Тут могу возразить

п.2 можно подумать, что кроме .Net или Win32API альтернативы разработки оконного приложения Net. На асемблере тоже можно оконное приложение написать под Win - еще неудобнее. По первым впечатлениям в .Net ничем не удобнее чем в Билдере||Делфи оконное приложение писать. А Если с асмом или Фортраном77 на больших машинах сравнивать, то Net и впрямь революция.

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


Многоплатформенность - мда, в понимании MS это Windows на ПКП, мобильниках, холодильниках, кофеварках и т.д, а не Unix или MacOS.

резкая дружба MS, Borland, IBM лишний раз убеждает в том, что у отрасли не лучшие времена и надо устраивать революцию и косить капусту. Дружба эта не ради мира, а против нас

можно писать на разных языках один проект. В этом месте я обычно плачу. Не стало исключением и это мгновение... Простите. Продолжим.


писать программы стало проще. УРА! Для меня проще писать программы тогда, когда есть нормальная документация по используемому инструментарию, качественный дебагер, в редакторе грамотная подсветка синтаксиса и интерактивная подсказка. А не тогда, когда "комилятор" пропустит любую чушь, которую ему подсунут.

вот что было на презентации в России.
чтобы не быть голословным, архитектор .NET Дон Бокс на глазах у зрителей создал несколько примеров и продемонстрировал десятикратный выигрыш в скорости и стабильную работу CLR-программ там, где традиционный C-код "намертво завешивал" систему.

Здесь я понял, что капец, нас похоже за стадо баранов держат. Примером своим он показал, что С-кодом можно "завесить" систему. Парень написал правильно на шарпе, потом неправильно на С и пытается убедить, что шарп лучше...


Уверен, что при желании можно сделать наоборот. Почитал интарьвью с Дон Бокс http://itware.com.ua/mg/2002/03/net.html смысл ответа на все вопросы "в Sun лохи".


Вот еще

Цитата

Для выполнения кода на IL требуется осуществить мгновенную компиляцию по требованию (just-in-time, JIT).

эта "мгновенная" мне покоя не дает


Web-service где здесь революция? Давно есть CORBA и DCOM. Новое проще за счет всяких мастеров-визардов. Согласен. Зато тормознутое. Но тоже самое.
Актуальность этой технологии весьма сомнительна. Несомненно потребность есть и будет расти, но приоритетной эта технология станет не сегодня и думаю не очень скоро.

Библиотека - она одна. Добавление нового как? библиотека универсальная. При этом у меня пример, BDE тоже универсальная. Поэтому можно пользоваться механизмом общим, а специализированными возможностями нет. Поэтому есть специально IBX и FibPlus. Надеюсь идея ясна. Или по замыслу мы теперь все будем только на SQLServer...
Когда-то давно, когда компьютеры были большими, а многих из нас небыло вааще, библиотеки были общими. Это были библиотеки математических функций. Так что и здесь первооткрывательство сомнительно...


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

И меня убеждают, что это нужно мне.

Спасибо за внимание

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

Если появляется, что то, что хорошо рекламируется я всегда спрашиваю а зачем мне это нужно, а кто выигрывает.
С .НЕТ это похоже не на рекламу, а на навязывание. Сквозит мысль: "Ребята никуда Вы не денетесь - это только вопрос времени".
1. Так почему появилась сама идея .НЕТ?
Ответ. Рынок по системному и инструментальному Software теряет свою динамику. Сейчас (как мне кажется) на пике находятся разработка прикладного софта и ему подобных. Дальнейшее совершенствование ОС и инструментов сильно затруднено, при существенных затратах выгода не большая. Многие инструменты (как Д7) практически вылизаны, и убедить разработчика на новый инструмент очень трудно. Но можно посеять тень сомнения, запугать...
2. Что прикладные программисты приобретают?
На этот вопрос пусть каждый для себя оветит. Я для себя получил следующее. Первое с чем я столкнулся так это с горящими глазами начальника (он ходил на бесплатный семинар от $MS), он сказал "Мы пишем проект на .НЕТ" (разговор шел о достаточно большом проекте). Видя мое не понимание он пояснил: "Писать не .НЕТ" очень легко. Я поинтересовался ради приличия на каком языке? Похоже мой вопрос его тоже заинтересовал, он задумался.
Второе, я не считаю себя гуру в Дельфях, что касается WinAPI, то я стараюсь избегать его использования где это возможно. Если есть сторонние компоненты то я стараюсь их использовать (причина думаю ясна). В свое время я понял, что слаб мозгами и на изучение всех "супер-пупер" технологий меня не хватит. Но я достаточно много времени потратил на изучение необходимого мне инструмента и нужных мне компонент. Если переходить на .НЕТ мне придется переучиваться (понятно, что опыт останется).
Третье, Дельфа 8 ставится с SDK .НЕТ версии 1.1, наверное через 1.5 года появилась SDK 2.0. Мне стало интересно как часто $MS будет выпускать новые версии. По опыту с ОС - патчи, постфиксы и пр. хрень выходит регулярно, т.е. скоро сбудется извечная мечта $MS - это подписка. Далее, интересно как будут работать новые версии SDK и прикладное ПО написанное в различные моменты времени. Например, в Java (насколько мне известно) дастаточно изменить маршрут к другому SDK. Если SDK будет плотно вмонтировано в ОС? Потом, если сравнивать с Java, то там вначале формируется документ, а потом реализация у $MS вначале идет реклама, потом рализация, потом документ (могу ошибаться).
Четвертое, я подумал а не начать ли мне по многим "советам друзей" изучать спецификации на .НЕТ. Насколько последовательна $MS? И вот, что мне увиделось: я буду обычным, бесплатным бета-тестером новой технологии. Буду участвовоть в форумах, писать что то о новой технологии, возможно даже программы. А через 2-3 года $MS предложит новую революционную технологию Dot NET+ или Net++ или .XML#.
Пятое, мыслей очень много, плюс вижу пока только 1. Народ сейчас "стадом" перебирается на .НЕТ под страхом потери работы. Если не стоять на пути, т.е. бежать вместе со всеми, тебя не затопчут.
3. Что приобретает $MS?
Первое, возможность без оглядки патчить свою ОС
Второе, снижение конкуренции своим продуктам, работающим под своей же осью.
Третье, восстановить динамику рынка разработки ОС и инструментального ПО.

2 Voice

Цитата Voice @ 24.08.04, 22:23

2 SPrograMMer
Все равно, что я бы сказал, учась в 5-м классе
"Ну и что, что все уже программят на MS VC++, все равно я свой Basic4.5 не брошу"

а я момоему не говорил, что не буду под .Net программить, есть ведь Delphi 8 for .Net Framework,
ЕСЧО РАЗ: D не брошу!!!
и C# - индейская, национальная изба - ФигВам, называется (лично для меня).

Добавлено в 26.08.04, 11:20:

Цитата MW Programs @ 25.08.04, 21:29

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

А кто против???!!!, помоему это единственное, что пришлось ВСЕМ по душе!
---
Надо предложить Borland Выпустить D7-D6 Second Edition...

Сообщение отредактировано: SPrograMMer - 26.08.04, 11:23

To be or .NET to be?

Цитата

Слушай, Andr, я и не думал хаять свой любимый Delphi . Но прежде чем отдавать за него кучу денег, хотелось бы разобраться, что там случилось с D8. Посмотри какие здесь о нем нелестные высказывания! Такого не было даже с D4.

Повторюсь, что D8 нельзя оценивать как очередную версию Delphi, т.к. все, что в нем нового - это не развитие Delphi как таковой, а выпуск приципиально нового продукта под принципиально новую платформу.
Когда на этом форуме удивляются, что это мол, теперь string является классом и функционирует по другому, сразу становится понятно, что авторы подобных высказываний не подрудились узнать о том, что язык D8 был приведен к требованиям общеязыковой спецификации .NET.
Можно по разному относиться к .NET, то важно понять, что прежде, чем изучать любую среду программирования под .NET, сперва надо изучить .NET, т.к. все о программировании теперь говорится в спецификациях платформы .NET.
И только потом изучать конкрентную среду/язык. Тогда не будет столько много вопросов к D8.

Цитата

Конкретно: какую популярную программу уже перевели под .NET

PowerQuest DriveImage 7
Следующая версия ERP-системы "Галактика" разрабатывается сейчас на .NET.

Цитата

и что это дало хорошего?

Читай книжки или тестируй .NET-программы, или попробуй программировать под .NET. По этому вопросу больше нечего сказать.
2 Vit

Цитата

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

А тебя не смущает, что простенький калькулятор для своей работы требует туеву хучу библиотек WinAPI? Между прочим, .NET 1.1 уже встроен в Windows Server 2003, и поставляется в виде программы, помещенной в один из пунктов автозапуска на официальных дисках Windows XP Service Pack 1.
2 H.Iglesias II Твои аргументы либо технически неграмотны, либо чистые эмоции. А в обоих случаях лучше не спорить...
2 USE

Цитата

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

Если начальник дурак, это еще не значит, что .NET плоха.

Цитата

Третье, Дельфа 8 ставится с SDK .НЕТ версии 1.1, наверное через 1.5 года появилась SDK 2.0. Мне стало интересно как часто $MS будет выпускать новые версии.

.NET SDK - это справка по .NET и набор консольных инструментов разработки. Сама платформа поставляется в виде отдельного дистриба. Поэтому безграмотен твой вопрос:

Цитата

Если SDK будет плотно вмонтировано в ОС?

Если ты имел в виду, что будет, если в ОС вмонтирована одна версия .NET, а нужна другая, отвечаю: .NET позволяет на официальном уровне устанавливать параллельно несколько версий. Еще советую тебе почитать о механизме строгих сборок.

Цитата

А через 2-3 года $MS предложит новую революционную технологию Dot NET+ или Net++ или .XML#.

.NET реализована для того, чтобы остановить наконец чехарду с дурными технологиями COM, COM+, DCOM, ATL, ActiveX. То, что в упомянутых технологиях реализовано как отстойные заплатки над уродливой WinAPI, в .NET изначально реализовано на архитектурном уровне, а потому чехарды не будет - будет плавное развитие.
2 SPrograMMer

Цитата

а я момоему не говорил, что не буду под .Net программить, есть ведь Delphi 8 for .Net Framework,
ЕСЧО РАЗ: D не брошу!!!
и C# - индейская, национальная изба - ФигВам, называется (лично для меня).

Если собираешься программировать под .NET, попробуй изучить все же C#. С D8 задолбаешься, слишком много нужно изучать касательно того, как Pascal приведен к требованиям общеязыковой исполняющей среды.

Цитата

Надо предложить Borland Выпустить D7-D6 Second Edition...

Следующая версия D9 "DiamondBack" будет позволять делать проекты для: .NET 2.0, Compact .NET, Win32, etc...

Цитата

Нет уж, я как-то пробовал C изучать, очень это было давно, и неправда, но тем не менее я еще не знал что Delphi существует, ну так вот еще простейшее C (не С++, нет) уже настолько ГЛУМНОЕ оказалось, что недавно пробовал что-то программить уже на C++ с использованем ООП, см. темы в разделе C, около месца назад, ну так вот ТО ЧТО КОНСТРУКТОРЫ И ДЕСТРУКТОРЫ в С++ (наверное и в С#) вызываются авторматом (черная магия прям!!!), и еще много чего, чего в паскале было очень просто и более понятно в С++ настолько заглумлено!!!,

C++унаследовал от C все детсвие болезни, не спорю. Насчет конструкторов и деструкторов: не побоюсь спросить, может, ты создавал статические объекты, а не динамические?

Цитата

хотя не утверждаю, что Паскаль лучше, если в этом всем разобраться, то может быть С (С#) и лучше, но тем не менее в С (C#) все, или почти все и не только в синтаксисе... ну очень заглумлено.

Да будет тебе известно, что C# разработан путем откидывания из изветсных языков всего, что ЗАГЛУМЛЕНО, и путем взятия всего, что круто!

Цитата

PowerQuest DriveImage 7

Я о такой даже не слышал. По названию догадываюсь, что для создания образов HDD. Если бы оно потребовалось, устанавливать прогу не стал бы, если бы не было .Net на компе, нашел бы альтернативу. А у большинства нет .Net.

Цитата

.NET реализована для того, чтобы остановить наконец чехарду с дурными технологиями COM, COM+, DCOM, ATL, ActiveX. То, что в упомянутых технологиях реализовано как отстойные заплатки над уродливой WinAPI, в .NET изначально реализовано на архитектурном уровне, а потому чехарды не будет - будет плавное развитие.

Andr, вот честное слово запарил уже со своей изначальностью чего-то там. "В .net переделали всё с нуля. А потому решаются ВСЕ проблемы, в том числе и с названиями". Архитектурный уровень, изначально, уродливый WinAPI. Голые слова и никакого смысла!!! А ATL каким местом там вообще отностится? Ты бы ещё MFC и VCL написал. COM - заплатка над WinAPI? Извини конечно, а ты программировал с использованием COM?

Цитата

Да будет тебе известно, что C# разработан путем откидывания из изветсных языков всего, что ЗАГЛУМЛЕНО, и путем взятия всего, что круто!

А указатели - это ацтой полнейший, да? Раз уж о COM говорили, так не из-за отсутствия ли оных в некоторых языках придумали такой гемор и извращение с Automation и IDispatch

Цитата

2 H.Iglesias II Твои аргументы либо технически неграмотны, либо чистые эмоции. А в обоих случаях лучше не спорить...

Где ты увидел у меня аргументы? Я и не собирался спорить.
Всегда можно при желании сказать наоборот

Цитата

Guest
COM - заплатка над WinAPI?

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

С появлением .NET и, в частности, понятий "общеязыковая спецификация" и "общеязыковая система типов" необходимость в надстройке отпала. И это только одно и множества преимуществ .NET.

Цитата

Архитектурный уровень, изначально, уродливый WinAPI. Голые слова и никакого смысла!!!

Да, именно архитектра .NET решает множество накопившихся проблем в программировании. Если кого-то запарили "общие слова", пусть читает книги, в которых эти слова расшифрованы.
На форуме же невозможно изложить весь книжный материал.

Цитата

Цитата

PowerQuest DriveImage 7

Я о такой даже не слышал. По названию догадываюсь, что для создания образов HDD.

Странно, что ты не слышал о одном из двух ведущих игроков в области клонирования дисков/партиций/операционок.
Второй крупный игрок этой области рынка - Symantec Ghost.
Кстати, насчет PowerQuest DriveImage. А, может, ты и о PowerQuest PartitionMagic не слыхал???

Цитата

Если бы оно потребовалось, устанавливать прогу не стал бы, если бы не было .Net на компе, нашел бы альтернативу. А у большинства нет .Net.

Проблема есть, но, повторюсь,
MS делает все, чтобы ее решить:
1) .NET 1.1 идет на дисках с Windwos XP SP1, встроена в Windows Server 2003.
2) в одну ОС могут устанавливаться разные версии .NET.
3) сейчас разрабатывается .NET 2.0, похоже, именно эта версия будет прошита в Longhorn.

Сообщение отредактировано: Song - 27.08.04, 08:59

Цитата

Andr

что C# разработан путем откидывания из изветсных языков всего, что ЗАГЛУМЛЕНО, и путем взятия всего, что круто

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

Добавлено в 27.08.04, 08:53:
Admin`ам и Moderator`ам: помоему QUOTE не работает...

Сообщение отредактировано: SPrograMMer - 27.08.04, 08:51

Цитата

всё работает

теги надо Андру закрывать!

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

Я вообще удивляюсь, что мы спорим, что лучше (.Net или WinApi). .Net является оболочкой для того же

Цитата

уродливого WinApi

. Microsoft еще не долго никуда не денется от WinApi, потому что на нем построена вся Винда. А в ближайшее время переделывать Винду с нуля (а именно этим придется заниматься, если делать ее с использованием .Net Framework).

Но чем тогда будет .Net Framework? Сделает ли Микрософт реализацию .Net на ассемблерных кодах (где будут функции форматирования дисков, записи CD и другие низкоуровневые функции)? Но тогда это будет лишь новая реализация WinApi. А только в этом случае можно будет говорить о смерти WinApi.

Господа Дельфийцы, использующие WinApi!

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

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-файлов.

2 encobalt

Цитата

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

Указатели в .NET ЕСТЬ, только это называется "небезопасный код".

2 Sanek
Никто и не говорит, что переход на .NET - это так просто. Но переходить нужно, т.к. концепции, заложенные, например, в тот же COM, теперь закладываются в платформу, а это приводит:
- к более простому написанию программ (ессно, для этого .NET надо изучить);
- к более простой инетеграции программ;
- и главное, к гораздо более высокой стабильности программ.

По поводу полной переделки Delphi language. Причина не в том, что общеязыковая спецификация налагает требования, приводящие к коверкагию языка, а в том, что Delphi language никогда не являлся подлинно объектно-ориентированным языком (каковым является C++). В Delphi lang. не было:
1. Методов и свойств у записей (структур). А такие структуры (статические объекты без наследования) иногда очень полезны. Теперь они есть.
2. "Настоящих" private и protected секций. Теперь они есть: strict private, strict protected.
3. Статических полей у классов. Теперь они есть: объявляются как var.
4. Не было перегрузки операторов. Теперь они есть (class operator).
Первые 2 пункта меня всегда особенно тяготили.

2 Sanek, 2 mike

Цитата

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

Риторический вопрос: не задумывались, почему Delphi делает промедуточные файлы dcu? Да так проще и оптимальнее через посредника делать оптимальный машинный код. Это утверждается разработчиками .NET.

2 Sanek

Цитата

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

Компиляция происходит не во время выполнения (как у виртуаьных машин), а ПЕРЕД ПЕРВЫМ ВЫЗОВОМ МЕТОДА. И компиляция выполняется С ОПТИМИЗАЦИЕЙ ПОД КОНКРЕНТНЫЙ ПРОЦЕССОР. Так утверждают разработчики .NET. Что же здесь не понятного.
Для слишком упертых: для пущего быстродействия можешь в момент старта программы вхолостую вызывать используемые метода, чтобы в момент "реального" вызова не тартить время на компиляцию.

Цитата

В Windows XP/Server 2003 есть функции для работы с такими списками, в остальных - нет.

Понятно, что за счет универсальности и чуть более высокого уровня у .NET программ немного сужается возможность работы на низком уровне. Никто тебе не запрещает вызвать WinAPI-функции из .NET-приложения.

Цитата Andr,2.09.04, 18:21

Это утверждается разработчиками .NET.

Компиляция происходит не во время выполнения (как у виртуаьных машин), а ПЕРЕД ПЕРВЫМ ВЫЗОВОМ МЕТОДА. И компиляция выполняется С ОПТИМИЗАЦИЕЙ ПОД КОНКРЕНТНЫЙ ПРОЦЕССОР.Так утверждают разработчики .NET. Что же здесь не понятного.
Для слишком упертых: для пущего быстродействия можешь в момент старта программы вхолостую вызывать используемые метода, чтобы в момент "реального" вызова не тартить время на компиляцию.

Посточнные ссылки на то что утверждают разработчики .Net (то бишь "теория") а в реальности видим не очень то быстродействующий код. Это замечание №1.
Замечание №2: предложение вызвывать для компиляции нужные методы при загрузке программы мне кажется, это может привести к очень большим недарзумениям в работующей программе. Например, метод "обощенный", делает что-то взависимости от параметра, например пишет в реестр занчение какого-то ключа. Возникает вопрос, с каким параметров вызывать этот метод в начале работы программы. Конкретный ключ - означает запись или перезапись его значения. Можно в методе предусмотреть выход из этого метода когда, в качестве параметра задана, напрмер, пустая строка. И использовать пустую строку в качестве параметра, когда запускаем программу. Но тогда это приводит к УВЕЛИЧЕНИЮ программного кода (в пример как минимум на одно условие), и опять таки все это ради быстродействия?
На КАКИЕ ЕЩЕ ФОКУСЫ придется пойти? А ? Andr?

Сообщение отредактировано: SPrograMMer - 02.09.04, 11:27

Цитата

Цитата

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

Риторический вопрос: не задумывались, почему Delphi делает промедуточные файлы dcu? Да так проще и оптимальнее через посредника делать оптимальный машинный код. Это утверждается разработчиками .NET.

Я это и имел ввиду. Повторяю еще раз:

Цитата

IL нужен только для более быстрого создания машинного кода

а также возможности запуска на разных платформах и для того чтобы скрыть исходный код.
Я имел ввиду что такого не може быть:

Цитата

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

Разве есть разница из чего делать ассемблерный код. Разница есть только в необходимом для этого времени.

Где-то я успел прочитать что при компиляции IL кода подразумевалась оптимизация не только под процессор, но и под установленное железо вообще, но в Framework 1.1 такого еще нет, будет в 2.0

С этимии фишками... это моя догадка, может быть я мечтаю, но возможно все идет к тому что драйвера (о которых говорилось что написать их в .net непонятно как) будет писать нетрудно, функция драйверов сведется к тому что они будут просто трнслировать ядру .net список поддерживаемых функций. Поддерживаемых из определенного стандарта, как это например сейчас умеют делать дрова для DirectX и OpenGL. Так вот... продолжение мысли - "тяжкое бремя" спецификации стандарта дров и возможных функций определенного типа железа возмет на себя естественно загребущая лапа майкрософт. Конечно выигрыш от этого будет, но что-то мне как-то неуютно. Или еще лучше, вообще никаких дров, мелкий камушек на железке с готовым списком того что умеет эта железка, и к этому камню .net будет обращаться напрямую перед тем как компилить оптимальный IL..

Я глючу?

SPrograMMer

Цитата

Посточнные ссылки на то что утверждают разработчики .Net (то бишь "теория") а в реальности видим не очень то быстродействующий код.

1. Прежде, чем сформировать свое мнение о чем-то новом, нужно первым делом как следует изучить теорию. Не задумывался, почему все так хают D8? Можно по-разному относиться к .NET, но нужно вначале изучить.
2. .NET-программы работают чуть медленнее, чем Win32 не потому, что разработчики врут об оптимальной компиляции под конкретный процессор, а потому, что все типы данных в .NET - объектные. Поэтому простейший цикл и работает в 1,5 раза дольше, т.к. счетчик - объект.
Если только из-зи этого отказываться от .NET, то давай откажемся и от D7 в пользу C и Pure-Win32-приложений, и будем писать их в любимой проге всех Pure-Win32-программеров Borland C++ 5.02??! А??? SPrograMMer???
На то все-таки и процы сейчас такие. Помнишь, когды Intel выпустила очень резко процы на 700 MHz, везде писали, что такую приозводительность негде использовать?

Цитата

На КАКИЕ ЕЩЕ ФОКУСЫ придется пойти

SPrograMMer, это был НЕ ФОКУС, а утрированный пример для очень УПЁРТЫХ.

Лирическое отступление: когда вышла D5, у нас один преподаватель, говорил, что его проги для баз данных, написанные в D3, после компиляции в D5 начинают работать на 30% медленнее. И потому, типа, D5 - го..но, а D3 - очень крута.
Ну, так давай, SPrograMMer, откажемся от D7 и будем писать проги на D3, т.к. они будут работать быстрее??? А???
Но я знаю, SPrograMMer, что ты не откажешься от D7, т.к. она отвечает вызовам времени, предоставляя соответствующие технологии, а D3 вызовам времени не отвечает.
Но теперь настают времена, что надстройки над WinAPI не отвечают вызовам времени, и скоро наступит золотое время .NET.

P.S. Код, написанный в VS. NET 2005 Beta 1 на чистом C++ (под Win32, без .NET Managed Extensions), всего лишь на 25% производительнее, чем код, написанный на C#. А если учесть, программировать на C# раз в 10 (десять) легче и приятнее (!), чем на C++, то мой выбор в пользу C#.

2 Andr

Цитата Andr,2.09.04, 15:52

Код, написанный в VS. NET 2005 Beta 1 на чистом C++ (под Win32, без .NET Managed Extensions), всего лишь на 25% производительнее, чем код, написанный на C#. А если учесть, программировать на C# раз в 10 (десять) легче и приятнее (!), чем на C++, то мой выбор в пользу C#.

Небольшой вопрос: на каком процессоре это проверялось? Если на P4, то вообще удивительно, если заметна какая-то разница в производительности. И если на P4, то где же оптимизация кода под конкретный процессор? Если ее нет (скорость не повышается), то зачем она нужна?

2 encobalt

Цитата encobalt,2.09.04, 15:12

возможно все идет к тому что драйвера (о которых говорилось что написать их в .net непонятно как) будет писать нетрудно, функция драйверов сведется к тому что они будут просто трнслировать ядру .net список поддерживаемых функций

Мне кажется, что со стороны Микрософт это возможно. Но опять же пока этого нет...
Тоже мысли вслух: если это действительно произойдет, то я точно буду думать, что Микрософт все время оставляет некоторые усовершенствования на потом. Разве этого нельзя было сделать в эпоху еще расцвета WinApi?

2 mike

Цитата

И если на P4, то где же оптимизация кода под конкретный процессор? Если ее нет (скорость не повышается), то зачем она нужна?

Ты не догоняешь:
1. Есть оптимизация методов под конкрентный процессор, и скорость повышается.
2. Итоговая скорость ниже, т.к. объектно-ориентированный код всегда медленнее (а без оптимизации под процессор стал бы еще медленнее). Если ты это не знал, то тебе учиться надо, а не рассуждать о производительности .NET

Цитата

Компиляция происходит не во время выполнения (как у виртуаьных машин), а ПЕРЕД ПЕРВЫМ ВЫЗОВОМ МЕТОДА.

А это не run-time? Метод вызывается не в рантайме?

Цитата

2. .NET-программы работают чуть медленнее, чем Win32 не потому, что разработчики врут об оптимальной компиляции под конкретный процессор, а потому, что все типы данных в .NET - объектные. Поэтому простейший цикл и работает в 1,5 раза дольше, т.к. счетчик - объект.

Для самых упёртых. Код на C#:

 
using System;
 
namespace net_test
{
         /// <summary>
    /// Summary description for Class1.
    /// </summary>
    class NetTest
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main(string[] args)
        {
            TestFunc();
        }
 
        static void TestFunc()
        {
            for(long i = 1; i < 50000; ++i)
            {
                bool simple = true;
                for(long j = 2; j < i; ++j)
                {
                    if(i % j == 0)
                        simple = false;
                }
                if(simple)
                                         Console.Write(i + "\n");
            }
        }
    }
}

Код на C++:

 
#include <iostream>
 
class long_integer {
public:
    long_integer(long l):
      _val(l) {}
 
    operator long() { return _val; }
 
    long_integer operator+(const long_integer & l) { return long_integer(_val + l._val); }
    long_integer operator++(int) {
        long_integer i = _val;
        _val++;
        return i;
    }
    long_integer & operator++() { _val++; return *this; }
    bool operator<(const long_integer & i) { return _val < i._val; }
    long_integer operator%(const long_integer & i) { return _val % i._val; }
 
private:
    long _val;
};
 
static void test_func()
{
    for(long i = 1; i < 50000; ++i)
    {
        bool simple = true;
        for(long j = 2; j < i; ++j)
        {
            if(i % j == 0)
                simple = false;
        }
        if(simple)
            std::cout << i << std::endl;
    }
}
 
static void test_func2() {
    for(long_integer i = 1; i < long_integer(50000); ++i)
    {
        bool simple = true;
        for(long_integer j = 2; j < i; ++j)
        {
            if(i % j == 0)
                simple = false;
        }
        if(simple)
            std::cout << i << std::endl;
    }
}
 
 
void main() {
    std::cout << "test 1" << std::endl;
    test_func();
    std::cout << "test 2" << std::endl;
    test_func2();
}

На С++ две функции: одна - аналог кода для C#, вторая - где счетчики - объекты. Время выполнения обеих функций на С++ одинаково!!! Что касается сравнения C++ и С#, то тут даже высокоточного счетсика не надо, всё и так понятно.
Использовалась VS 2003. Первый пример у меня на компе выполняется 2 минуты 10 сек, второй - каждая функция по 1 минуте 10 сек.
Попробуйте у себя.
P.S Не забудьте пробовать на Release версиях.

Цитата

А если учесть, программировать на C# раз в 10 (десять) легче и приятнее (!), чем на C++, то мой выбор в пользу C#.

Субъективное мнение.

Цитата

2. Итоговая скорость ниже, т.к. объектно-ориентированный код всегда медленнее (а без оптимизации под процессор стал бы еще медленнее). Если ты это не знал, то тебе учиться надо, а не рассуждать о производительности .NET

смотри пример

Сообщение отредактировано: Sanek - 02.09.04, 15:22

2 Sanek

Цитата

Цитата

Компиляция происходит не во время выполнения (как у виртуаьных машин), а ПЕРЕД ПЕРВЫМ ВЫЗОВОМ МЕТОДА.

А это не run-time? Метод вызывается не в рантайме?

Я несколько некорректно высказался. Но рантайм рантайму рознь. Одно дело, когда виртуальная машина перемалывает байт-код в машинный каждый раз при вызове, другое, когда IL-код при первом вызове скомпилит код метода оптимально под конкретный процессор при первом вызове метода.

Теперь рассмотрим твои примеры с C# и C++. Тебе известно понятие чистоты эксперимента? (ты где учился ?) Если сравнивается производительность счетчиков, то в теле цикла ничего ни должно быть (что более предпочтительно), либо должен быть одинаковый код.
А у тебя:

Console.Write(i + "\n");

для C#;

std::cout << i << std::endl;

Понятно, что .NET-консоль более сложный объект. Например, ты передаешь ему целое-объект, которое перобразуется в строку-объект и выводится.
А в системную консоль C++ ты пишешь просто целое число (к тому же наверняка коварный оптимизирующий компилятор помещавет его не в ОЗУ, а в какой-нибудь регистров проца). И преобразуется он наверняка перед выводом в простой и быстрый *char.

Так что постарайся быть более убедительным, Sanek.

Цитата

Если сравнивается производительность счетчиков, то в теле цикла ничего ни должно быть (что более предпочтительно), либо должен быть одинаковый код.

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

Цитата

Понятно, что .NET-консоль более сложный объект. Например, ты передаешь ему целое-объект, которое перобразуется в строку-объект и выводится.
А в системную консоль C++ ты пишешь просто целое число

И чем же это .NET-консоль сложнее cout? И что значит "просто пишу число". Как будто оно не преобразуется в строку.

Цитата

к тому же наверняка коварный оптимизирующий компилятор помещавет его не в ОЗУ, а в какой-нибудь регистров проца

Ну так если у .NET плохой оптимизатор, что я могу поделать.

Ну да ладно. Специально для тебя. Можешь закомменитровать эти строки. Изменений не будет. Тут же невооруженным глазом видно, что основная часть времени тратится на цикл, а не на вывод. Можешь преобразовать в std::string в С++, всё равно ничего не изменится.
Факт есть факт. У нас два ООП-кода, один выполняется гораздо медленне. Ничего с этим не поделаешь.

2 Sanek
Пример с соблюдением чистоты эксперимента (для тех, кто гонит на .NET)
Консольное приложение, которое можно скомпилировать как в D7, так и в D8:

program Test;
{$APPTYPE CONSOLE}
{if CompilerVersion >= 16.00}
  {%DelphiDotNetAssemblyCompiler '$(SystemRoot)\microsoft.net\framework\v1.1.4322\system.drawing.dll'}
{endif}
uses SysUtils;
var
  BeginTime: TDateTime;
  I: Integer;
begin
  BeginTime := Now();
  for I := 0 to MaxInt do begin { empty cycle } end;
  Writeln(FormatDateTime('"Test time: "hh:nn:ss:ms" (hour:min:sec:msec)"', Now() - BeginTime));
  Writeln('Press ENTER...');
  Readln;
end.

Время выполнения обоих приложений (скомпилированных в D7 и D8) одинаково: 0 ч, 0 м, 3 с, 123 мс.
Рузультата говорит сам за себя.

Andr, приведи аналог на C#, если сможешь.

2 Sanek
Аналог (Release-сборка) на C# - VS .NET 2003:

using System;
namespace ConsoleApplication1
{
    class Class1
    {
        [STAThread]
        static void Main(string[] args)
        {
            DateTime beginDate = DateTime.Now;
            [B]for (uint i = 0; i <= int.MaxValue; i++) { /* empty cycle */ }[/B]
            TimeSpan testTime = DateTime.Now - beginDate;
            string s = testTime.ToString();
            Console.WriteLine("Test time: " + s);
            Console.WriteLine("Press Enter...");
            Console.ReadLine();
        }
    }
}

Результат: на той же машине (Cel 1300, WinSrv 2003 Ent) выполняется 4 с 983 мс.

Что же, резальтат не так хорош, как в Delphi 7/8.
Я думаю, связано это с различной релизацией цикла for.
Если в Delphi цикл for заменить на цикл while, выполняться цикл будет почти в 2 раза дольше (я проверял).
Это связано с тем, что цикл for можно скомпилировать в очень быструю asm-инструкцию loop, в случае же цикла while компилятор вынужден самостоятельно управлять изменением счетчика.

А в C# цикл for фактически является иначе записанной формой цикла while:

using System;
namespace ConsoleApplication1
{
    class Class1
    {
        [STAThread]
        static void Main(string[] args)
        {
            DateTime beginDate = DateTime.Now;
            [B]uint i = 0;
            while (i <= int.MaxValue) { i++; }[/B]
            TimeSpan testTime = DateTime.Now - beginDate;
            string s = testTime.ToString();
            Console.WriteLine("Test time: " + s);
            Console.WriteLine("Press Enter...");
            Console.ReadLine();
        }
    }
}

Этот код выполняется тоже 4 с 483 мс.

Так что увеличение времени выполннеия в данном случае - не недостаток .NET, в недостаток реализации цикла for в конкретном языке.
Кстати, в C/C++ цикл for тоже является фактически циклом while. Я всегда считал это недостатком .

Сообщение отредактировано: Song - 06.09.04, 11:35

В последнем после у меня опечатка:
вместо 4 с 483 мс надо писать 4 с 983 мс

Andr, code=cpp !

Цитата Andr,2.09.04, 17:26

2 mike
1. Есть оптимизация методов под конкрентный процессор, и скорость повышается.

Вот тут я возможно действительно не догоняю, а хотел бы разобраться: так каким образом работает компилятор .NET: действительно как компилятор (т.е. создает машинный код) или как транслятор (т.е. вызывает код только отдельных методов)?

2 mike

Цитата

Цитата

Есть оптимизация методов под конкрентный процессор, и скорость повышается.

Вот тут я возможно действительно не догоняю, а хотел бы разобраться: так каким образом работает компилятор .NET: действительно как компилятор (т.е. создает машинный код) или как транслятор (т.е. вызывает код только отдельных методов)?

Все просто:
1. Мы пишем программу в среде разработки (например, VS .NET 2003 или Delphi 8 .NET).
2. Собираем (в Delphi 8 это: Project|Build) нашу программу. Компилятор, поставляемый со средой разработки, компилирует весь исходный код в IL-код общеязыковой среды.
3. Запускаем нашу программу:
3.1. перед первым вызовом каждого из вызываемых в программе методов метод компилируется в машинный код (оптимальный для процессора, который установлен в компе) и и остается о ОЗУ до завершения программы.
3.2. если какой-либо метод ни разу не вызывается в программе, то он и не компилируется в машинный код во время выполнения.

2 Song

Цитата

code=cpp

Что это? Я не в курсе.

Andr,
Вот это что такое по твоему?



Для кого оно по-твоему пишется вверху в красной рамке!?
Когда глаза последний раз мыл?

M

Флуд пошёл! Предупреждения начать раздавать или сами прекратите?

Извиняюсь, конечно может и не по теме, но меня очень интересует вопрос, на что мне отдать своё предпочтение? ПС, можно поставить D8 к уже стоящей D7 чтоб ничё не закосячить?

Извиняюсь, такой вопрос уже был, сорь...

Слушай, Andr, хватит мозги пудрить. Сначала у тебя там счетчики объекты, потом это всё как-то запихивается в регистр cx, используется "очень быстрая" loop. Приплёл уже туда какие-то недостатки циклов С.

Вот, опять, специально для тебя:

 
#include <iostream>
#include <time.h>
#include <conio.h>
 
static void test_func()
{
    clock_t begin = clock();
    __asm {
        mov ecx, 100000000;
m1:
        loop m1;
    }
    std::cout << "Test 1: " << (clock() - begin) << std::endl;
}
 
static void test_func3() {
    clock_t begin = clock();
    __asm {
        mov eax, 100000000;
m1:
        dec eax;
        cmp eax, 0;
        jne m1
    }
    std::cout << "Test 2: " << (clock() - begin) << std::endl;
}
 
 
void main() {
    test_func();
    test_func3();
    std::cout.flush();
    getch();
}

На моём компе первая функция: 911, вторая: 460.
Да к твоему сведению, аналог приведённого тобой кода на С++, скомпилированный на любом приличном компиляторе (например VC++), будет выполняться 0, просто потому, что компиллер выкинет нафиг этот цикл.
Проверь лучше, что твой пример на D8 действительно компилируется с использованием .Net.

И ещё: если поменять во второй функции так, чтоб счетчик возрастал, ничего не изменится.

Сообщение отредактировано: Sanek - 13.09.04, 21:50

Sanek,

мой

Цитата

пример на D8 действительно компилируется с использованием .Net

по той простой причине, что D8 способна компилировать исполняемые файлы только под .NET Framework 1.1.

Я не знаю конкретно, почему в твоем примере вариант цикла с loop выполняется дольше. Это предмет исследования.
Но я знаю, что в системе команд x86 команда loop предусмотрена для создания более быстрых счетчиком цикла (ну, и, попутно, для более простого написания кода этого цикла).

И еще. Я не спорю, что на данный момент .NET/C#-проги выполняются медленнее. Версия 1.1 - это пробный шар. Когда выйдет .NET 2.0 - это и будет момент истины: станет ли технология .NET массовой (и быстрой).

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

Сообщение отредактировано: Andr .NET - 14.09.04, 11:11

Цитата

по той простой причине, что D8 способна компилировать исполняемые файлы только под .NET Framework 1.1.

Так то оно так, но на форуме тут писали:

Цитата

Столкнулся с интересной штукой:

Создаю новый проект /File/New/VCL Forms Application
Получаю проект с пустой формой.
Сохраняю его.
Собираю /Project/Build Project1
После сборки заглядываю в папку проекта и вижу:

Project1.exe 1,348,096

Добавляю на форму кнопку (TButton).
Сохраняю, собираю, заглядываю в папку проекта и вижу:

Project1.exe 8,192

Кто-нибудь знает, почему размер файла резко сократился ?
И какого лешего он вообще изначально 1,3 мега "весил" ?

Кстати, может обяснишь, из-за чего такое было?

По поводу команды loop у меня есть догадки, но я не спец в этом деле, это надо в раздел по asm к системщикам .

Так я о том и говорю, что по крайней мере в ближайшее время .Net использовать не собираюсь точно. Как выйдет 2.0, так и посмотрим. Хотя сомневаюсь, что что-то изменится очень сильно.
Считаю, что рассмотреть переход на .Net можно программирующим на VB и Java. А остальным пока не дёргаться.

Уважаемый Andr! Ваш пример не впечатляет, поскольку используется пустой цикл. Оптимизатор кода может быть достаточно умен, чтобы поместить счетчик в регистр процессора и тогда сравнение двух програм сводится к сравнению скорости работы функций вывода на консоль, а это не совсем то, что интересует (вывод результатов выполняется один раз по окончании работы и разница в милисекунды здесь крайне не существенна). Попробуйте, пожалуйста, вставить в цикл какие-либо математические действия, вычисления факториала, например.
Для меня вопрос производительности крайне актуален. Я занимаюсь моделированием и оптимизацией технологических процессов: составление и решение систем 15-20 тысяч уравнений, перебор большого числа вариантов. Соответственно есть циклы в циклах, рекурсии и активная работа с динамической памятью (поскольку в разных вариантах разный объем данных).
Понятно, что чудес не бывает. Больше универсальности/навороченности достигается за счет объема/производительности. Но одно дело, если производительность ухудшается на проценты - да, тогда предпочтем более современный и навороченный интерфейс (в свое время Delphi был принят на ура благодаря возможности сократить до минимума время создания пользовательского интерфейса и сконцентрировать усилия на решении технологических задач). Но если идет замедление в разы, то тогда лучше остаться на морально устаревшем и архитектурно никудышнем WinAPI. Или, дабы не быть задавленным толпой бегущих в .NET программистов ( ), отскочить в сторону юниксов.

Цитата Sanek @ 14.09.04, 17:19

Считаю, что рассмотреть переход на .Net можно программирующим на VB и Java. А остальным пока не дёргаться.

Насчет VB согласен, а вот насчет Java имхо переход на .Net может и даст ряд положительных моментов, но при этом пропадет многоплатформенность а с ней и большой кусок рынка ПО. Лично я плохо себе представляю разработку ПО под Sun Solaris, которое будет написано для платформы .Net, а клиенту будет предлагаться погеммороиться с Open Source Memo.

Sanek,

Цитата

Так то оно так, но на форуме тут писали:

Цитата

Столкнулся с интересной штукой:

Создаю новый проект /File/New/VCL Forms Application
Получаю проект с пустой формой.
Сохраняю его.
Собираю /Project/Build Project1
После сборки заглядываю в папку проекта и вижу:

Project1.exe 1,348,096

Добавляю на форму кнопку (TButton).
Сохраняю, собираю, заглядываю в папку проекта и вижу:

Project1.exe 8,192

Кто-нибудь знает, почему размер файла резко сократился ?
И какого лешего он вообще изначально 1,3 мега "весил" ?

Кстати, может обяснишь, из-за чего такое было?

По этому поводу могу дать исчерпывающий ответ:

1. В D8 можно создавать VCL .NET-приложения. Эта технология позволяет создавать .NET-приложения, но использующие внешний неуправляемый код: компоненты VCL .NET построены на вызовах функций WinAPI.
В состав технологии VCL .NET входят пространства имен Borland.Vcl.* (например, Borland.Vcl.Windows, Borland.Vcl.SysUtils).

2. Создадим пустой проект VCL .NET и скомпилируем его. Посмотрим на диалоговое окно, появляющееся при нажатии Project|Information for <Project Name>. Тут мы увидим, что размер файла 1,3M, но списке динамических библиотек, необходимых для выполнения нашего проекта, отсутствуют Borland.Vcl.*.

3. Положим Button на форму нашего проекта. Опять скомпилируем. Жмем Project|Information for <Project Name>. Размер файла стал 8K, но при этом в списке необходимых библиотек появились несколько Borland.Vcl.*!

4. Из пп. 2 и 3 следует, что компилятор сам решает, поместить ли используемый код из библиотек Borland.Vcl.* в исполняемый файл проекта, или подключать эти библиотеки во время выполнения.
Если D <= 7 можно было управлять этим самостоятельно, то D8 этим вопросом заведует исключительно компилятор.
Понячалу меня это раздражало, но потом я прочитал в справке, что VCL .NET не рекомендуется использовать для создания новых проектов, а рекомендуется только для поддержки старых.

В приведенном примере для оценки производительности счетчика я не подключал ни одного пространства имен Borland.Vcl.*.
Однако если бы я использовал VCL .NET, то код, написанный мной собственноручно, все равно был-бы .NET-овским.

Цитата

Да к твоему сведению, аналог приведённого тобой кода на С++, скомпилированный на любом приличном компиляторе (например VC++), будет выполняться 0, просто потому, что компиллер выкинет нафиг этот цикл.

А если в качестве начального и/или конечного значений счетчика будут не константы, а функции?

Цитата

Считаю, что рассмотреть переход на .Net можно программирующим на VB и Java. А остальным пока не дёргаться.

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

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

Единственный камень преткновения - производительность.

Sanek, Guest, подождем выхода .NET 2.0: Microsoft обещает, что производительность C#.NET-кода будет всего на 3-5% ниже, чем производительность чистого C++/Win32-кода.

Сообщение отредактировано: Andr .NET - 15.09.04, 05:33

Цитата

А если в качестве начального и/или конечного значений счетчика будут не константы, а функции?

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

Про Java: я имел в виду про тех кто программит вод Win

позволю себе также несколько замечаний

Цитата

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

это как бы очевидно, как очевидно и то, что данная мысль легко асоциируется с чем угодно помимо .Net, так как у всех есть преимущества, равно как и недостатки.

Цитата

А если в качестве начального и/или конечного значений счетчика будут не константы, а функции?

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

Цитата

подождем выхода .NET 2.0: Microsoft обещает, что производительность C#.NET-кода будет всего на 3-5% ниже, чем производительность чистого C++/Win32-кода.

только вот еще надо бы господам из MS добавить на какой конфигурации. Думаю, P4 не меньше

опять же о оптимизации. При запуске все затачивается под мою систему. Оптимизируется код для "конкретного моего" процессора, невызываемые функции вообще в код не включаются (всеми нами используемым борланским компилятором также неиспользуемые ф-ции в код не включаются) и т.д. и производительность всего на 3-5% НИЖЕ. Нормально... У Вас нет чувства, что где-то Вас кидают? Я всю жизнь думал, что оптимизация имеет смысл когда она приводит к ПОВЫШЕНИЮ производительности. Конечно, зачем нам эти одинаковые экзешники на разных компах... Они же не оптимизированы под каждую конкретную машину! Толи дело в Net, на каждой машине приложение оптимизировано, и всего на 5% медленнее. Это даже не смешной довод в пользу Net - это глупый довод.

А если учесть, что с .Net писать программы

Цитата

проще и приятнее

то я могу себе представить как они будт работать. Кривой алгоритм никакой компилятор не оптимизирует.

Дюжину с лишним страниц написали в этой ветке, а в чем суть?

Кто-нибудь уверовал в то, что используя .Net программа будет разработана быстрее, работать будет лучше (если будет лучше, то чем), работать с ней будет легче, еще какие-то преимущества, чем если-бы ее писали в Delphi или BCB или там яве какой-нить?

Цитата

H.Iglesias II: и производительность всего на 3-5% НИЖЕ. Нормально... У Вас нет чувства, что где-то Вас кидают? Я всю жизнь думал, что оптимизация имеет смысл когда она приводит к ПОВЫШЕНИЮ производительности.

Ответ до смешного прост. Если бы не было оптимизации, то производительность была бы еще ниже.
Но потеря 3-5% производительности - ерудна по сравнению с новыми преимуществами. Другое дело, что кто-то может не захотеть их познать, но это его дело...

Никто же не будет отрицать, что программы, написанные на на Delphi или C++Builder медленнее, чем Pure-Win32-проги (скажем, написанные, в Boorland C++ 5.02). Но почему-то основная масса народу пишет именно на Delphi/C++Builder/Visual Studio.

Кстати, разработчики FAR'а в свое время отказались писать на C++Builder из-за тормознутости написанных на нем прог (версия 1.70b3 в качестве эксперитента была написана на C++Builder, в 1.70b4 опять вернулись к Borland C++ 5.02).
Но FAR не относится к классу наиболее распространенных программ - это своего рода исключение.

Сообщение отредактировано: Andr .NET - 15.09.04, 13:32

2 Andr .NET

Цитата

Ответ до смешного прост. Если бы не было оптимизации, то производительность была бы еще ниже.

Это как раз очевидно, но ты ведь преподносишь этот пункт как один из козырей, а на самом деле это не дает ничего, и другие "преимущества" сводят на нет всю оптимизацию. Да, это действительно смешно....

Цитата

Никто же не будет отрицать, что программы, написанные на на Delphi или C++Builder медленнее, чем Pure-Win32-проги (скажем, написанные, в Boorland C++ 5.02). Но почему-то основная масса народу пишет именно на Delphi/C++Builder/Visual Studio.

та как бы смотря с чем сравнивать. Я не спорю, что инструмент должен быть по задаче, но мы ведь сравниваем Delphi не с BC++, а с net и C#. Если человек не может объяснить как работает его программа на Delphi в "дореволюционной редакции", то с какого бодуна он будет выдавать лучшие программы в Net?

Цитата

Но потеря 3-5% производительности - ерудна по сравнению с новыми преимуществами.

Ну назови хотябы пару-тройку преимуществ, которые имеют программы сделаные в Net по сравнению с программами не использующими технологию Net, сплошь состоящие из этого ужасного "неуправляемого" кода.

Ты без конца повторяешь о присутствии в net каких-то преимуществ (видимых и невидимых) нажимая на уродства API, COM и т.д. При появлении каждого из детищ MS (будь то OLE или COM или еще что) мы слышали, что теперь уж наши проблемы решены Раз и навсегда! Dll Hell, опять же - красивый слоган... При попытках конкретики ты многозначительно указываешь, что мы должны эти преимущества познать. Все преимущества, с которыми я познакомился при поверхностном знакомстве, просто рекламная шелуха. Для конечного пользователя программы абсолютно наплевать в Builder или Borland C++ FAR написан. Eго интересует качество, а качество в первую очередm зависит от того, кто разрабатывает, а потом уже от того каким инструментом пользуется разработчик. И еще очень долго будет именно так, и никак не наоборот как нас пытаются убедить в MS: "берите .Net и все станет в шакаладе"

Ещё хочу сказать пару слов насчёт производительности. Скорее всего, как и предположил H.Iglesias II, самые маленькие потери производительности будут на P4 или каком-нибудь другом продвинутом процессоре.
Однако что будет если скомпилить свой код под конкретный проц, а потом сравнить? Потеря производительности наверное станет ужасной.
Тут у .Net есть преимущество: всё компилится с использованием оптимизации под свой проц. Но толку-то нет. Всё равно код медленне.

H.Iglesias II,

Цитата

При появлении каждого из детищ MS (будь то OLE или COM или еще что) мы слышали, что теперь уж наши проблемы решены Раз и навсегда! Dll Hell, опять же - красивый слоган...

Потому у Microsoft сейчас и проблемы с продвижением серьезной технологии .NET - они раньше рождали слишком много технологий-однодневок и снабжали их рекламной шелухой.
Dll hell - не слоган, а насущная проблема.

Цитата

Цитата

Никто же не будет отрицать, что программы, написанные на на Delphi или C++Builder медленнее, чем Pure-Win32-проги (скажем, написанные, в Boorland C++ 5.02). Но почему-то основная масса народу пишет именно на Delphi/C++Builder/Visual Studio.

та как бы смотря с чем сравнивать. Я не спорю, что инструмент должен быть по задаче, но мы ведь сравниваем Delphi не с BC++, а с net и C#.

Я не призывал сравнивать Delphi <=7 и C++Builder. Повторюсь, Программы, написанные в Delphi <=7 и BCB много медленнее, чем написанные в "классических" средах разработки под Win32 (тот же BC 5.02).
А программы, написанные на C# под .NET, медленнее, чем программы написанные на D <=7 и BCB.
На каждом из этапов мы выигрываем в удобстве, но проигрываем в в быстродействии. Надо отдать должное разработчикам Microsoft, что они предоставляют максимум удобств и стараются минимизировать потери в быстродействии.

Цитата

Если человек не может объяснить как работает его программа на Delphi в "дореволюционной редакции", то с какого бодуна он будет выдавать лучшие программы в Net?

Об этом говорили уже. Под DOS, Win32 или .NET надо уметь и знать, как программировать. Читай внимательнее топик .

Цитата

Ну назови хотя бы пару-тройку преимуществ, которые имеют программы сделаные в Net по сравнению с программами не использующими технологию Net, сплошь состоящие из этого ужасного "неуправляемого" кода.

Преимущества технологии .NET я уже называл неоднократно, не ограничиваясь только словами о грамотной архитектуре платформы. Научись читать .
И еще. Если кто-то ожидает, что ему на форуме в двух словах исчерпывающе расскажут о архитектуре м примуществах новой технологии, то он ошибается. Без серьезной самостоятельной работы не обойтись. Ограничиваться рекламной шелухой не стоит, надо хотя бы пару-тройку серьезных книг почитать.

P.S. Когда только появилась Delphi, наверняка многие, подобные H.Iglesias'у II'у, говорили что, типа вот Borland C++ 4.5 круче, т.к написанные на нем проги быстрее дельфийских.
И где сейчас классические среды типа BC?

P.P.S. Хватит уже флеймить! Модераторам: закрывайте тему. Один флейм пошел...

Сообщение отредактировано: Andr .NET - 16.09.04, 09:38

Цитата

Dll hell - не слоган, а насущная проблема.

ага. так ведь в книжке написано

Цитата

Потому у Microsoft сейчас и проблемы с продвижением серьезной технологии .NET - они раньше рождали слишком много технологий-однодневок и снабжали их рекламной шелухой.

Каждый раз мы слышим, что раньше была какашка, а вот теперь!!!!! Сейчас ничего нового, те же слова. С чего ей быть не однодневкой. OLE пока тоже еще дух не испустила.

Цитата

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

я не стону о потере производительности. Действительно, сейчас нет проблемы в нехватке ресурсов и падение скорости выполнения цикла с 400 мс даже до 800 мс никакой принципиальной роли не сыграет.
Мне непонятно бесконечное повторение "удобно". В VS NET плитра компонентов удобнее? Когда все сгружено в один список... Приятнее? Хотя по сравнению с VC++60 бесспорно. Язык программирования меняется, хоть паскаль, хоть С++, это удобно? Не надо только здесь объяснять почему он меняется и становится лучше. Если бы он становился лучше и удобнее, то изменили бы его намного раньше, и не в MS

Цитата

Цитата
Если человек не может объяснить как работает его программа на Delphi в "дореволюционной редакции", то с какого бодуна он будет выдавать лучшие программы в Net?
Об этом говорили уже. Под DOS, Win32 или .NET надо уметь и знать, как программировать. Читай внимательнее топик .

об этом и речь, а не о том, что Net лучше или Delphi. Это тоже самое, что рассуждения о том, что "]паскаль лучше С++, потому, что я не понимаю зачем там указатели". Я вот не разу не написал, что Делфи лучше. Или BCB...

Цитата

Преимущества технологии .NET я уже называл неоднократно, не ограничиваясь только словами о грамотной архитектуре платформы. Научись читать

Я умею читать. Я читал весь топик. никаких серьезных преимуществ я в твоих топиках не видел (приведи номер поста, где есть конкретика).

Если преимуществами называется возможность писать в проекте каждому на своем любимом языке, то во первых это уже не мой любимый язык, а сильно измененный язык и он уже не тот. А во вторых я не разу не встречал проекты, в которых разные части программы хотелось бы писать на скажем, бейсике, С++, паскале. Именно хотелось, потому, что когда это было необходимо, решалось это без проблем (только не надо здесь повторять "dll hell! dll hell!").

Описание преимуществ нового архитектурного уровня библиотеки сводится к изначальному уродству WinAPI=> уродство библиотек. Все согласны, что оболочка над С-ми функциями по опредлению не может отвечать концепции ООП на 100%. Примем, что библиотека Net 100% ОО без доказательства. И какой вывод? НИКАКОГО... Одна библиотека более ОО чем другая. Кто-нибудь комплексует по поводу ОО-ности VCL? Кому-то это было неудобно?
Насчет единоначала библиотеки, которое ты выдвигал как преимущество постов с сотню назад, то это такое же преимущество как и недостаток, потому, что я считаю искать и исправлять ошибки проще в отдельных мелких специализированных продуктах, чем в огромном механизме. Notepad намного проще отладить чем OfficeXP. Потом правда ты признался, что под отдельные API сторонних продуктов есть свои Netы. Ну так специализация всетаки лучше или нет?

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

Цитата

Под Windows программировать сложно.
А .NET создан для того, чтобы облегчить программирование! Писать под него программы проще. Но, конечно, придется перед этим напрячься - почитать новые книги, документацию... Ничего совсем уж лего не бывает!

Так все таки программированию под Win надо учится или не особо? По вашему с MS при работе программиста в Net не надо заморачиваться на тему как там оно работает в принципе.

Цитата

одно из преимуществ .NET - независимость разрабатываемых программ от среды разработки. И это правильно!

Пустые слова.
Не более независимы чем они были раньше. Если я неправ, объясните в чем заключается независимость

Цитата

Вывод: на мой взгляд, лучше изучать спроектированный с учетом всего опыта программирования новый язык C#, чем изучать все нововведения в Delphi language, VB, etc...

в том-то и дело, что в итоге все сводится к тому, что чем D8 или BCBuilderX так уж лучше купите VS Net.

Цитата

общеязыковая система типов

Согласен. Это неплохо, это проще чем через COM, но COM не единственный способ общения. Здесь, пожалуй, не поспоришь...

Цитата

На форуме же невозможно изложить весь книжный материал

никакого изложения кроме "читайте книги" много раз я у тебя не вижу (не пиши только "читай топик". Я читал топик)

Цитата

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

я часто бываю в одном месте, где могу прочесть такой лозунг слова без смысла объясняют любую аномалию (или нечто вроде того). Любая программа решает какие-то проблемы. так и net: какие-то проблемы решает, а какие-то создает.

Цитата

Разница есть? Есть, и заключается она в упрощении/убыстрении разработки ПО и в высокой стабильности разработанного ПО, при программировании под .NET.

и

Цитата

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

ну просто пустые слова. Не будете вы быстрее разрабатывать приложения перейдя с D на Net. И стабильность приложения зависит не от Net. Совсем не зависит. От программиста она зависит. Коряво можно писать и на delphi и в net и на билдере и на VS. На всем можно сделать нестабильную программу. Возможно, она даже не будет глючить в Net, но РАЗВЕ ЭТО ХОРОШО?

Цитата

Но я знаю, SPrograMMer, что ты не откажешься от D7, т.к. она отвечает вызовам времени, предоставляя соответствующие технологии, а D3 вызовам времени не отвечает.

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

Цитата

Но теперь настают времена, что надстройки над WinAPI не отвечают вызовам времени, и скоро наступит золотое время .NET.

Это из какой книжки? Кто тебе сказал это? Каким именно вызовам времени?

Цитата

А если учесть, программировать на C# раз в 10 (десять) легче и приятнее (!), чем на C++

В чем измеряется? Я могу сказать, что мне на С++ легче и приятнее. Где здесь Довод?

и последнее: Вы меня не поняли. ВСЕ. Я не против нового.

Не надо просто мозги компоссировать. Нет никакой революции - есть продукт, который призван принести прибыль создателям. Большинство доводов в пользу этой технологии известных мне надуманы и раздуты. А если придется, буду и я в VS Net писать... и может даже на шарпе. Это рынок решит, а не мы с вами в этом топике

Сообщение отредактировано: H.Iglesias II - 16.09.04, 14:15

Цитата

Потому у Microsoft сейчас и проблемы с продвижением серьезной технологии .NET - они раньше рождали слишком много технологий-однодневок и снабжали их рекламной шелухой.

Ты правда не в Microsoft рабоатешь? Или тебе COM что-то плохого сделал? Не, ты по-моему не догоняешь, .Net Framework работает на COM, ибо в системных требованиях у неё написано COM+ !!!

Sanek,
Это ты не догоняешь
По поводу того, что .NET - открытый набор спецификаций, мы уже говорили, повторяться не будем.
Теперь очень конкретно: системные требования Microsoft .NET Framework 1.1 (то бишь системные требования конкретной реализации .NET):

Цитата

System Requirements
Review the tables below to determine the minimum system requirements for running the Microsoft .NET Framework 1.1 SDK and the .NET Framework 1.1 Redistributable.

.NET Framework 1.1 SDK
To install the .NET Framework 1.1 SDK, you need:

Minimum Requirements
Processor Client (a computer not working in a server capacity): 90-megahertz (MHz) Intel Pentium-class processor
Server (a computer working in a server capacity): 133-MHz Intel Pentium-class processor

Operating System The .NET Framework 1.1 SDK can be installed on the following platforms:

Microsoft Windows® Server 2003 family
Windows 2000, with the latest Windows service pack and critical updates available from the Microsoft Security Web site
Windows XP (Windows XP Professional is required to run ASP.NET)
Note: The .NET Framework SDK 1.1 cannot be installed on 64-bit computers; Windows Millennium Edition and Microsoft Windows NT® 4.0 are not supported
Memory Client: 32 megabytes (MB) of RAM, 96 MB recommended
Server: 128 MB of RAM, 256 MB recommended

Hard Disk 660 MB of hard disk space required, 190 MB additional hard disk space required for installation (850 MB total)
Display 800 x 600 or higher-resolution display with 256 colors
Input Device Microsoft mouse or compatible pointing device
Other Prior to installing the .NET Framework SDK version 1.1, you must first install the .NET Framework 1.1 Redistributable. You can download the Redistributable from the .NET Framework Downloads page.
Microsoft Internet Explorer 5.01 or later is required (click to get Internet Explorer 6.0).
Microsoft Data Access Components 2.6 is required for data scenarios (Microsoft Data Access Components 2.8 is recommended on a server).
Install the latest Windows service packs and critical updates from the Windows Update site.




.NET Framework 1.1 Redistributable
To run applications on the .NET Framework, you need:

Minimum Requirements
Processor Client (a computer not working in a server capacity): 90-megahertz (MHz) Intel Pentium-class processor
Server (a computer working in a server capacity): 133-MHz Intel Pentium-class processor

Operating System The .NET Framework 1.1 Redistributable is supported on the following platforms:

Microsoft Windows® Server 2003* (.NET Framework 1.1 is installed as part of the operating system)
Windows XP Professional*
Windows XP Home Edition
Windows 2000*
Windows Millennium Edition (Windows Me)
Windows 98
Microsoft Windows NT® 4.0 Service Pack 6a
Notes: ASP.NET Web applications and XML Web services can only be hosted on Windows XP Professional, Windows 2000, and Windows Server 2003

The .NET Framework 1.1 Redistributable cannot be installed on 64-bit computers; Windows NT 4.0 Terminal Server is not supported
Memory Client: 32 megabytes (MB) of RAM, 96 MB recommended
Server: 128 MB of RAM, 256 MB recommended

Hard Disk 110 MB of hard disk space required, 40 MB additional hard disk space required for installation (150 MB total)
Display 800 x 600 or higher-resolution display with 256 colors
Input Device Microsoft mouse or compatible pointing device
Other Microsoft Internet Explorer 5.01 or later is required (click to get Internet Explorer 6.0).
Microsoft Data Access Components 2.6 is required for data scenarios (Microsoft Data Access Components 2.8 is recommended on a server).
Microsoft DirectX 9b is required to execute managed DirectX applications
Install the latest Windows service packs and critical updates from the Windows Update site.
Installation of the .NET Framework 1.1 is split into two parts: the core and language packs. The core contains everything you need to run .NET Framework applications; all dialog boxes and error messages will be in English. If you want dialog boxes and error messages in another language, you must also install the corresponding language pack. For more information, see the .NET Framework Downloads page.


* To access the features of ASP.NET, Internet Information Services (IIS) with the latest security updates must be installed prior to installing the .NET Framework. If IIS is not present on the computer when the .NET Framework is installed, ASP.NET will fail to register correctly and ASP.NET applications will not run. If IIS is installed after the .NET Framework, you must manually register the Aspnet_isapi.dll file using Regsvr32.exe.

© _http://msdn.microsoft.com/netframework/technologyinfo/sysreqs/default.aspx
Понимаю, что никто из идеологических противников .NET на этом форуме не читал ни официальную документацию .NET, ни книги. Их позиция (необоснованная) очень похожа на позицию большинство идеологических противников MS в целом.
Ваше дело. Но зачем же фантазировать о том, что в системные требования .NET входит COM+ ?!!

H.Iglesias II,

Цитата

Цитата

Dll hell - не слоган, а насущная проблема.

ага. так ведь в книжке написано

Ну почему же. Не тока в книжке. Когда туева хуча левейших прог кидает (и перезаписывает) в %sysdir% dll-ку с одним и тем же названием, но разных версий (чаще всего несовместимых между собой по части функций), то это и есть DLL Hell.

Теперь наконец-то Самая Любимая Корпорация ставит заслоны на пути таких левых разработчиков, а всякие H.Iglesias'ы II'е критикуют сии добрые намерения. Уж не засланец ли Вы, батенька, конкурирующей фирмы по имени Linix???

Сообщение отредактировано: Andr .NET - 17.09.04, 15:13

Цитата

это и есть DLL Hell

Спасибо. За идиота меня принимаешь? Dll hell - проблема придуманная MS в виде ветряной мельницы, чтобы было с чем бороться. Все просто стонут от этого hella... Давай не будем к этому возвращаться. Большинство предыдущих разработок MS боролось с dll hell. Еще не скоро они эту идею отбросят...

Цитата

Их позиция (необоснованная) очень похожа на позицию большинство идеологических противников MS в целом.

Какая у меня позиция? Я пытаюсь добиться у тебя обоснования твоей позиции. Обоснуй ты свою позицию. Я не утверждаю, что моя технология лучше твоей, и я не отстаиваю никакой позиции. Меня очень легко убедить, но только не фразами "читайте топик", "возмите и изучите". Ты ведь изучил и "удобней", "стабильней" (с указанием во сколько раз), а повторяешь банальности из книг про изначальный архитектурный уровень + другие видимые и невидимые преимущества. Все, что ты писал и есть "рекламная шелуха и красивые слова".

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

кстати

Цитата

Уж не засланец ли Вы, батенька, конкурирующей фирмы по имени Linix

Что это за фирма? Такое знакомое название... Что они выпускают?

COM+ у них написан в Additional Software Requirements в SDK. Вероятно я ошибся, и это значит, что то типа Для того чтобы использовать COM+ вам нужен COM+

Ладно, опять тебе всё доказывать надо как обычно.
Какая там у нас библиотека отвечает за запуск приложений под .Net? Как я понял, это mscoree.dll. Так обясни мне почему у неё экспортируются функции DllRegisterServer, DllUnregisterServer, DllGetClassObject и DllCanUnloadNow? Ничего не напоминает? Тогда почему у меня в реестре в разделе CLSID столько записей со ссылками на эту библиотеку и указанием там каких-то классов, напирмер System.MemberAccessException, System.Runtime.Remoting.Proxies.ProxyAttribute, и т. д.

Я не противник MS, хотя бы потому, что большинство программ компилирую их компилятором. Но когда они придумывают действительно хрень, да ещё её и рекламируют, как какую-то божественную вещь, то тут трудно сдержаться.

Добавлено в 18.09.04, 02:20:
Насчет DLL Hell согласен с H.Iglesias II. Вообще не слышал про такую проблему, хорошо хоть объяснили, что тут называют проблеммой. И даже не задумывался об этом. В MS привыкли наверное, что у пользователей мозгов маловато, теперь они стали думать, что у разработчиков мало.

Тем, кто беспокоится по поводу производительности .NET: тут уже игры портируют под .NET!
_http://www.vertigosoftware.com/Quake2.htm

Добавлено Сегодня, 14:59
H.Iglesias II,

Цитата

Обоснуй ты свою позицию.

Когда я впервые заглянул в этот топик, увидел, что в основном Delphi 8 критикуют за то, что ожидали одно (Delphi "традиционную"), а получили Delphi for .NET.

Поскольку .NET - принципиально новая платформа (как бы мы к ней ни относились) по отношению к Win32, то нужно вначале изучить .NET. Тем более, что одна из основных особеннностей .NET - как раз достаточно серьезная независимость разрабатываемых программ от средств разработки.

(Под Win32 была обратная ситуация. Платформа Win32 не отвечает некоторым современным требованиям, например, легкости построения GUI. Потому под нее было несколько сред разработки с разными подходами - Delphi/VCL, VS/MFC...).

Однако по ходу изложения вышеобозначенных мыслей я по ошибке невольно увлекся изложением преимуществ .NET. Это-то и вызвало непонимание со стороны части форумчан.

Если кому-то интересна технология .NET, отчасти повторюсь, чтобы ее изучить/понять, нужно иметь определенный опыт программировавния под DOS/Win32, почитать серьезную литертуру, иметь способности к определенному уровню абстракции. И, конечно, желание.

Предлагаю на этом завершить широкое обсуждение.

Сообщение отредактировано: Andr .NET - 22.09.04, 12:05

Выясняется, что Delphi 9 "DiamondBack" не будет поддерживать .NET Framework 2.0, как заявлялось перед проведением BorCon-2004.

По той простой причине, что .NET Framework 2.0-Final будет готова только в 2005 г., а ребятишкам из Борлянда нетерпится выпустить Delphi 9 уже сейчас (года не прошло с выхода D8!).

Как только выйдет .NET Framework 2.0-Final, обещают незамедлительно выпустить Delphi 10.
Скоро Delphi раз в полгода начнет выходить

Итак, в одной IDE будет поддерживаться:
- .NET Framework 1.1;
- .NET Compact Framework (ограниченная поддержка - только компиляция);
- Win32 (!). Будет много всяких новых модных штуковин - Win32-программисты, держитесь!;
- C# (!!);
- само собой, Delphi language;
- всякие модные штучки типа Refactoring.

То, что D9 по-прежнему поддерживает .NET Framework 1.1, и в нее возвращена поддержка Win32, позволяет говорить о том, что Delphi 8 - просто перевалочный пункт.
Вот только что-то затянулся у ребят переходный период - D7 тоже была объявлена как перевалочная база на пути к .NET.

Источники:
_http://bdn.borland.com/article/0,1410,32708,00.html
_http://bdn.borland.com/article/0,1410,32719,00.html
_http://bdn.borland.com/article/0,1410,32718,00.html
_http://bdn.borland.com/article/0,1410,32499,00.html

Сообщение отредактировано: Andr .NET - 05.10.04, 05:36

http://russian.joelonsoftware.com/Articles...oesBonkers.html
Интересная статейка про дотНет. Взгляд бывшего программиста Microsoft.

2 Curve
Статейка - графоманский отстой долбаных чуваков. В качестве аргумента против .NET была взята "рекламная шелуха", и заявляется, что, типа, в .NET ничего нет.

Это в этой статейке ничего нет.

Ну не обойтись без "рекламной шелухи" крупным корпорациям при продвижении новых продуктов - никто же не будет читать отчеты о научных изысканиях.

Кому интересно узнать, что же в .NET есть, читайте уже упомянутую книгу Дж. Рихтера "Программирование на платформе .NET Framework" - 2-е издание, "Русская редакция", 2003.

P.S. Давайте все же завершим дискуссию о .NET, все уже высказались как могли.

Сообщение отредактировано: Andr .NET - 06.10.04, 14:13

Цитата

P.S. Давайте все же завершим дискуссию о .NET, все уже высказались как могли.

Andr

Я вижу у тебя просто закончились аргументы. Завершать тему не нужно. Она интересная и главное злободневная. Не думай что ты один на форуме.

s-mike, аргументы у меня не закончились.
Просто многие тут не хотят чуть-чуть изучить .NET, но просто похаять рады

Я думаю, если отбросить рекламную информацию - .net - это супер-супер скрипт. И такой - же быстрый как и все скрипты. :( аля - HTML+J+asm
Преходить или нет на .нет - об этом пока рано говорить - слишком сыро. BD "сжульничали" - могли бы и полноценную версию воткнуть в продукт, как продолжение D<=7 линейки.
Безусловно D8 красивая, но мне придется половину своих програмок переделывать, под нее чтобы работали. Чесно говоря, я пожалел, что установил D8.

2 Andr.net - конечно твои аргументы очень-очень убедительны, как и аргументы СССР о прелестях коммунизма и времени его наступления :) (конечно, очень приятно что прочитал эту книгу, а также кучу рекламных проспектов)

Складывается впечатление что Boland переняла маркетинговую политику MS, тама тоже деньги любят ;)

Ув. Poso1,
Что касается D8 - да, это сыроватая программа:
- медленная (разработчики это признают - читал я это где-то на bdn.borland.com);
- если посмотреть в Диспетчере задач, памяти при работе с проектом использует раза 3 больше, чем VS2003.

Но эти недостатки не касаются ни .NET, ни MS .NET Framework!
И если Ваши D7-программы не компилируются в D8, не надо говорить, что .NET и D8 - лажа. Ведь .NET - это другая ПЛАТФОРМА!
Повторюсь:

Цитата

Когда я впервые заглянул в этот топик, увидел, что в основном Delphi 8 критикуют за то, что ожидали одно (Delphi "традиционную"), а получили Delphi for .NET.

Не зря же .NET хают в основном Delphi-разработчики, а давние приверженцы Visual Studio более лояльны.

Цитата

Переходить или нет на .нет - об этом пока рано говорить - слишком сыро.

Не скажи, уже сейчас есть класс задач, которые лучше реализовывать на .NET. Вот несколько примеров:
- многие ведущие разработчики ERP-систем перевели/переводят свои продукты на .NET (Scala, Галактика). Кстати, краем уха слышал, что MS пытается заставить 1С перейти на .NET, но те держат оборону
- все, что связано с интернетом, например, приложения баз данных электронной коммерции (в нашем городе одна зарубежная контора, специализирующаяся на этой теме, где-то еще 1,5 года назад перешла с Delphi на .NET; есть и другие примеры).

Цитата

конечно твои аргументы очень-очень убедительны, как и аргументы СССР о прелестях коммунизма и времени его наступления

Это совсем не аргумент

Сообщение отредактировано: Andr .NET - 11.10.04, 08:26

Цитата Andr .NET @ 11.10.04, 11:23

MS пытается заставить 1С перейти на .NET, но те держат оборону

Значит, наверное есть причины B) . А можно поподробнее или получить ссылку?

Цитата

Кстати, краем уха слышал, что MS пытается заставить 1С перейти на .NET, но те держат оборону

Естественно держат. При переходе на .NET их платформа будет просто не нужна. Что дает их платформа? Простой доступ к базе данных (субъективное мнение, мне кажется, что не проще чем через ADO), создание скриптов (убогий язык, бейсик с примесью паскаля и операцией ? : из Си ), удалённый вызов кода, создание интерфейса пользователя (как в RAD), синхронизация документов по времени. Первые два пункта .NET обеспечивает гораздо лучше, особенно язык. Удалённый вызов кода есть в .NET, DCOM. RAD естественно гораздо лучше в .NET. Синхронизация документов реализуется не просто легко, а элементарно. Базу они используют в последней версии MS SQL. Причём тормоза в последней версии просто ужасные. Ещё и богатые возможности запросов MS SQL заменяют каким-то кастрированным синтаксимом. Они держаться просто из-за того, что у них есть всегда свежая кофигурация для новых законов/постановлений.

Я считаю, что если выбросить 1С и писать под .NET или на Delphi/C++/..., то скорость разработки возрастет в разы. Особенно если накидать пару базовых классов в начале, и их использовать в дальнейших разработках. Например зачем мне лезть в какое-то дерево конфигурации, чтобы добавить константу или перечисление, если можно написать const или enum. Тем более нет поддержки ООП.

Вот здесь .NET как раз подходит. Не требуется особая скорость, можно всё красиво организовать через использование удалённых объектов на сервере + сделать быстро интерфейс пользователя.

Тут, когда велись дебаты, были вопросы, а какие программы для .NET уже есть. Я приводил примеры. Вот еще один пример:
Microsoft (!) Business Contact Manager for Outlook 2003.

Дистрибутив BCM за вычетом веса .NET Framework 1.1 составляет 130M, что очень много, т.к. весь код, не относящийся к функциональности программы, находится в .NET Framework.
("Много" - не в смысле "плохо", а в смысле, что прога эта - не утилитка простая, а серьезный функциональный продукт).

Если так дело пойдет и дальше, может, и следующая версия офиса будет для .NET Framework.

Если кого-то опять заденет, что я положительно пишу о .NET, давайте только не спорить о нужности/ненужности Business Contact Manager. Это просто пример, что Microsoft тоже не стоит в стороне .

Сообщение отредактировано: Andr .NET - 16.11.04, 07:39

Поставил только сегодня. Зря диск купил!!!
И вообще я .НЕТ Не уважаю.
Кто мне скажет её преемущество.
Я нашёл только одни минусы.

1. За собой нужно таскать 23 метра
2. Прога заводиться на много дольше чем на 7
3. В памяти она занимает от 14 метров когда на 7 всего 3-4

Что они там такого нашли

Сообщение отредактировано: Aleman - 10.12.04, 19:22

Aleman,
При такой постановке вопроса тебе никто не сможет растолковать преимущества .NET.

А че там с Kylix? Уж там-то не должно быть точки NET , а его новой версии нет?