- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
implementation
uses Unit1,Unit2,Unit3,Unit4,Unit5,Unit6,Unit7,Unit8;
{$R *.dfm}
var
k,Zst,zk,Vm12,Vm23,Vm34,Vm45,Vm56,Z2pr,Z3pr,Z4pr,Z5pr,Z6pr,Lm12,Lm23,Lm34,Lm45,Lm56,Vk,Vst,Q,q11,q2ob,q3ob,q4ob,q5ob,q6ob,
Sst,P1st,P2st,p0k,p12k,p23k,p34k,p45k,p56k,L0,Dk,Dst,H,Hst: real;
J0,j, i: integer;
const a=1.1; g=9.81; Y=0.03; x1=605; Y1=48; X2=772; Y2=104;
x3=627; Y3=107; X4=646; Y4=379;
x5=X3; Y5=194; X6=576; Y6=200;
x7=582; Y7=193; X8=576;
x9=X3; Y9=285; X10=526; Y10=291;
x11=532; Y11=284; X12=X10;
x13=650; Y13=380; X14=395; Y14=399;
x15=479; Y15=377; X16=473;
x17=394; Y17=Y13; X18=314; Y18=Y14;
x19=398; Y19=Y15; X20=392;
x21=314; Y21=Y13; X22=233; Y22=Y14;
x23=317; Y23=Y15; X24=311;
x25=233; Y25=Y13; X26=152; Y26=Y14;
x27=235; Y27=Y15; X28=229;
x29=152; Y29=Y13; X30=70; Y30=Y14;
x31=154 ; Y31=Y15; X32=148;
X33=70;Y33=Y13;X34=3;Y34=Y14;
X35=72;Y35=Y15;X36=66;
procedure TForm9.FormClose(Sender: TObject; var Action: TCloseAction);
begin
Form9.visible:=false;
end;
Follow us!
С 23 строки автор явно устал тужитьсякопипастить, и проебал Y36.
хуясе
Application was halted by an exception.
Debug-mode is off.
я даже боюсь сюда постить, очень всё шедеврально - http://www.everfall.com/paste/id.php?yacyylrzccpm
и не зря. M4K3 M3 UNS33N 1T!
>>>очень всё шедеврально
да, но в то же время женщинам и детям я бы не рекомендовал смотреть на это
Draw (...);
end;
Явно короче чем Canvas.Draw (...);
И Form9.visible:=false; при закрытии формы тоже доставило :)
но не для построения сложных бизнес-систем
просто в мире, где столько кода написано на пхп -- смешно ругать паскаль
оптимизация в Delphi вообще какая-то странная... несколько раз попадался код, который работает по-разному при включении и выключении оптимизации.
Причем без оптимизации работает корректно.
Сейчас пример уже не приведу, но оптимизацию всегда отключаю. В time-critical участках проще самому посмотреть, минимизировать обращения к памяти и стеку - результат обычно существенно лучше.
Для сравнения оптимизация кода в Visual Studio 2005:
n = ((++ a) / b) + ((a ++) % b);
в результате asm-код содержит 2 инкремента, 1 сложение и 1 деление.
А сам Object pascal вполне нормальный язык, возможности которого сравнимы с С++. Немного иной подход к ООП - но он имеет право на существование. Хотя отсутствие шаблонов, нормальных макросов, стековых экземпляров классов и, особенно, отсутствие inline функций иногда очень напрягает.
Я, как упоротый пользователь D7, хотел написать про это, но D2010 же есть.
> нормальных макросов
Корявых макросов тут нету,
Спасибо Вирту хоть за это!
> стековых экземпляров классов
type A = object итд
> и, особенно, отсутствие inline функций
D2010. В D7 их отсутствие, как и отсутствие перегрузки операторов, действительно напрягает, работа с 3хмерными векторами превращается в китайщину.
> несколько раз попадался код, который работает по-разному при включении и выключении оптимизации.
В D6 был такой баг, в новых тоже вроде есть, но D7 в этом плане чиста. И грузится влёт, если минимальный набор ставить (как я, только я добавляю редактор иконок, исходники VCL и помощь)
+я категорически согласен с Lure Of Chaos в нем нет элегантности и лаконичности
> Спасибо Вирту хоть за это!
Сишников вынуждает использовать макросы отсутствие модульной структуры. Macros are evil! Они приводят к неуловимым ошибкам. Недаром в C# ввели-таки модули.
И в Delphi, и в Lazarus есть подобие макросов:
{$i macrotext.inc}
но я бы это использовал тока если уже ничего другого не остается, ибо говнокод.
а {$I file} aka {$INCLUDE file} - обычный для Сей плоский инклюд, ни разу не макро (хотя кулибины на них ухитрились сделать кривое подобие шаблонов)
макро совсем нет
Он пару раз всплывал в говнокодах. Разные версии VS дают разный результат.
Новые версии Delphi хвалят за то, что у них крутой оптимизатор, и одновременно ругают за то, что у них глючный оптимизатор. Но тем не менее, у любой версии код более быстрый, чем у GPC и FPC. Насчёт оптимизации согласен. Изменение логики программы даёт ускорение, которое не даст никакой оптимизатор.
Спасибо за явное перечисление недостатков.
азаза
как и бейсик, в нем нет элегантности и лаконичности, слишком много ключевых слов - те же begin и end
в нем нет встроенной поддержки алгоритмических структур (например хэши, они же карты, динамические массивы), нет работы с потоками и т.д. и т.п.
То есть, теоретически такую поддержку можно обеспечить включением дополнительных модулей, но их интерфейс будет неуклюжим, что обеспечено архитектурой самого языка
даже простые вещи, вроде работы с файлами, требуют неоправданных усилий со стороны программиста
поэтому код разбухает очень сильно, что даже психологически его утомительно читать - как следствие, с ростом кода, увеличивается кошмар поддержки больших систем
Они лучше видны в коде, в отличие от фигурных скобок.
> в нем нет встроенной поддержки алгоритмических структур
У Паскаля нету СТЛ, это его минус как языка типа?
> динамические массивы
Их нету в Паскале?!
> нет работы с потоками
Их нету в Паскале?!
> даже простые вещи, вроде работы с файлами
Assign; Rewrite; Close; что проще?
нет, хуже, потому что больше букв
> У Паскаля нету СТЛ, это его минус как языка типа?
допустим, СТЛ чьими-то усилиями реализован. Код использования его так же был бы уродлив. Кроме того, сторонние библиотеки не унифицированы и увеличивают размер кода и стоимость поддержки
> Их нету в Паскале?!
Их нету в Паскале. Дельфи в расчет не берем
> Assign; Rewrite; Close; что проще?
допустим, мы хотим считать весь файл в утф8, каждую строку в массив. Код, реализующий это просто ужасен
Хуже видны, потому что больше жирных цветных букв?! Не лагай.
> Код использования его так же был бы уродлив.
Как в С++? Нет, будем меньшее уродство, потому что меньше закорючек.
> Их нету в Паскале. Дельфи в расчет не берем
Ололо, давайте вспоминать, чего нет в С89.
> допустим, мы хотим считать весь файл в утф8, каждую строку в массив. Код, реализующий это просто ужасен
А в С++ есть готовый оператор для этого, встроенный в язык, да?
Наличие/отсутствие библиотек - это особенности не языка, а реализации.
Короче, продолжишь, когда опохмелишься.
вовсе не потому. см http://govnokod.ru/4232#comment47648
> Как в С++? Нет, будем меньшее уродство, потому что меньше закорючек.
С был идеален. С++ не идеален (избыток закорючек), но верхом элегантности я считаю Java.
> Ололо, давайте вспоминать, чего нет в С89.
а я имел ввиду именно паскакаль. Дельфи лучше, но его многабуквенный синтаксис остался, это лично меня раздражает
> А в С++ есть готовый оператор для этого, встроенный в язык, да?
в С++ запись короче и элегантней, хотя тоже непаханое поле для улучшений
> Наличие/отсутствие библиотек - это особенности не языка, а реализации.
Согласитесь, набор стандартных библиотек - это намного приятнее, нежели головная боль, где и какие библы достать. Опять приведу в пример Java, где достаточно хорошая стандартная библиотека(или совокупность таковых) для большинства распространенных задач
> Короче, продолжишь, когда опохмелишься.
Прошу без оскорблений, иначе не буду выражать свою точку зрения вообще (прим.переводчика: в тексте "иди ты нахуй"). Хотите, программьте на дельфях, а я с этим тра...мучаться не буду, а возьму родную Java.
В своём году.
> а я имел ввиду именно паскакаль
Хорошо хоть, что не Алгол-67.
> в С++ запись короче и элегантней, хотя тоже непаханое поле для улучшений
И читаемее? Скорость написания намного менее важна, чем скорость врубания.
> Согласитесь, набор стандартных библиотек - это намного приятнее, нежели головная боль, где и какие библы достать.
Это относится к реализации.
> В своём году.
как и паскаль
> Хорошо хоть, что не Алгол-67.
вот именно, сравнение удачное
> И читаемее?
зависит от самого кода. Можно писать и так и так
> Это относится к реализации
конечно, не стоит все пихать в язык.
>>>я еще в древние времена, турбопаскалем заработал аллергию на этот язык. Когда малость поинтересовался дельфями, то увидел, что там те же раздражающие факторы
+7
Вот так прямо сходу за ООП?
Принуждение к распиздяйству по отношению к системным ресурсам.
Дельфи -- странная штука
– какие страсти
чисто обезьяний довод, вы уж меня простите
я думаю, обезьянам до букв параллельно.
паскаль создавался как язык для обучения, а нубам (англоговорящим) проще воспринимается begin,end нежели скобки. потом они подучивают немного вышки и скобки становятся приятнее глазу.
Таким образом, что такое программирование, поймут больше идиотов, нежели начать обьяснять абстрактные скобки
Хреново, что в Сях семантика синтаксической конструкции зависит от контекста, т. е. один и тот же символ может расшифровываться по-разному. В Паскале таких примеров меньше.
возможно и так, но, у меня есть подозрения, что их происхождение императивно-коммандное
> Хреново, что в Сях семантика синтаксической конструкции зависит от контекста
это достаточно вкусная возможность, впрочем, усложняющая понимание кода при недостаточно продуманном использовании этой возможности.
Мне даже немного жалко, что в яве отказались от множественного наследования и перегрузки операторов, например.
насичот множественного и да и нет - да иногда очень надо, нет - говнокода стало было больше поскольку тулили бы его где надо и где не надо.
насичот перегрузки 100% да. или че чтоб поюзать перегрузку мне нада юзать груви?
видимо приходится юзать именованные методы
При определённом опыте и нормальной подсветке они с первого взгляда читаются именно как скобки, но согласен, занимают многовато места.
Это не правда всё таки. Создавался он вполне для продакашена, просо так вышло, что стал популярен для обчеимя
Это тот же самый эффект, для сравнения, если читать текст с кеглем 12-14 пунктов, и, скажем, 48 пунктов.
Если вам разница неочевидна, поставьте эксперимент: сохраните любую статью из интернета и откройте ее в ворде. Прочитайте. Затем выделите все и увеличьте размер текста до 48, и снова прочитайте. И сравните усталость после прочтения в первом и во втором случае. Если разница незаметна, возьмите статью в 2 раза обьемнее.
В случае же с бегином разницы нет, один хрен он занимает одну строчку (у меня ноль), как и фигурная скобочка.
А вот то, что скобоки вынуждают делать отступы не в 2 символа а в 4, это уже существенно. Да, почему дельфисты 2 отступа делают, а сишникам уже и 4 мало? Не в моде дело, а скобочки фигурные их вынуждают. И код расползается в ширину, его труднее смотреть, вот так вот. Так что бегин-енд рулят, хотя, согласен, смотрятся как-то убого, допотопно.
то же самое при использовании длинных [ключевых] слов
> скобоки вынуждают делать отступы не в 2 символа а в 4
это почему? не согласен.
лично я делаю отступы и со скобками 1 пробел (ставля размер шрифта 8) и не вижу никаких вынужденных неудобств
и уж скорее "код расползается в ширину" именно благодаря длинным ключевым словам (5, 3 символа против 1 символа на скобку)
можете более подробно обьяснить этот момент?
2. Я вот, когда на С++ делал 2 отступа, плохо видел, где что кончается, если бегин-енд образовывали чёткую рамочку (только не всегда бегин, иногда иф или фор, я бегин оставляю на старой строчке, чтобы не слишком жирно было), то лёгкие фигурные скобки были издали еле заметны. Стал делать 4 - стало легче.
2. наверное, это дело привычки, у меня подобных проблем никогда не было. Но за время использования бейсиков-паскалей заработал аллергию на переизбыток ключевых слов (например, раздражало, что в бейсике for должен заканчиваться только next, а while - wend. При таком подходе при изменении одного ключевого слова нужно еще где-то ниже менять ему парное ключевое)
и несмотря на это мне нравилось в бейсике что там не нада открывающее слово типа begin писать -почти как ява-стайл расставления скобок - на одной строке с оператором.
>>>а while - wend
кстати есть крайне гибкий do..loop. паскалевские циклы сосут.
trollface.pas :))
А чем не нравитсяВот сишного for () не хватает, да.
+1. лично я первые 4 года плевался ядом. а потом просто плевался.
>>while условие do ... ;
>>repeat ... until not условиe
а тем, что когда меня заставляли писать на этом ... и рисовать блок-схемы к коду. в силу упаянности препода паскалем оказалось, что
в блок-схемах можно использовать цикл с пост-условием и not <условие> и цикл с предусловием раб по true.
никаких других альтернатив быть не могло. я поначалу не въехал с чего бы это вдруг кроссязыковым блок-схемам иметь подобные ограничения, а
потом понял что это результат повышенной фимозности.
в том же бейсике
do
...
loop
while и until можно писать как сверху так и снизу. или вообще не писать ))) - аналог сишный for(;;).
Удобно. Одно из немногих преимуществ Basic перед паскалем и остальными (включая православные С-подобные языки).
Вот это как раз к паскалю и не относится. Операторные скобки begin/end универсальны.
На 4 символа? Ты неадекватен и сам в этом признался.
> При таком подходе при изменении одного ключевого слова нужно еще где-то ниже менять ему парное ключевое
О, это уже что-то дельное. Правда, к Паскалю это не относится.
почему на 4? не обязательно.
Или у тебя много бегинов в одной строке?
А, ещё бесит писать слово ПРОЦЕДУРА (или ФУНКЦИЯ), это я бы убрал из языка.
+1, еще не гуд, что блок не всегда выделяется begin/end, например repeat/until, try/except. В С++ в любом случае будет скобки... хотя все это дело практики
LOL"D
>>паскаль не виноват) это далеко не самый плохой язык между прочим)
>>просто в мире, где столько кода написано на пхп -- смешно ругать паскаль
согласен
>>для обучения, например
не согласен, как по мне не обучает он хорошему стилю - скоко студентоты его учит и такое обилие говен.
Вот меня он ничему вооще не научил - я только испытываю лютую ненависть к наиудобнейшим паскалевским циклам в частности...
Вот зачем? ну создал Вирт язык для обучения - не учить же потому всем его поголовно, чтобы в итоге писать С-like код.
но пых это вообще жесть.
Вы скрытно рекламируете БРЕЙНФАК!!!
>>>Это точно!
это точно - полнейшая миниммалистичность, простая кроссплатформенность и компилер меньше чем 200 байт.
ИТОГ: пусть учатся кодить на брейнфаке - полезно для головы
а на паскале/делфях сложные продукты занимают меньше памяти/ЦПУ чем на Си?
или как писать сложнейшие корпоративные системы на асме?
хотя я и сам люблю асм и подобное транжирство мне очень не по душе.
но повторяю - брейнфак - именно то что надо
Это зависит от программиста и от используемых библиотек больше, чем от языка. Хотя если брать в сравнение скриптовые языки...
Важно уменьшение производственных затрат, т.к. их несет сам разработчик ПО (в смысле софтверная компания). А основными производственными затратами является ФЗП.
Соответственно, снижение трудозатрат на разработку (а значит и сокращение штата сотрудников) - одна из основных целей руководства софтверной компании.
В дельфях уже может быть компонент TTetris :)))
LOL"D, да это особенность делфей)))
правда он с вероятностью 90% будет иметь баги - тоже особенность.
его надо найти, ознакомиться, вытоптать грабли - тоже время нужно
от выбора языка никак не зависит насколько говен будет код студентов. Он будет говен в любом случае.
Так будет лучше?
UPD: А вообще, казнил бы за такой код (автора я имею ввиду)
В Паскале константы можно свалить в кучу, а в C++ нельзя! Следовательно, C++ - отстой, lul