Ура-то ура, но у меня на FPC-2.2.2 с нормально настроенной оптимизацией ехешник занимает 34кБ.
Такшта делфи... вот когда лазарус заживет полнокровной жизнью, станет веселей. Хай живе Free Pascal!

Уважаемые Жека и Pasha

Вы что измеряли-то?
Вы в курсе, что помимо вашего кода, который вы написали на Делфи, и который откомпилился в какой-то исполняемый код, в вашем ехе-шном модуле присутствует еще "посторонний" код?

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

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

Я не знаю точно как, но Делфя позволяет сгенерить код ехе-шника без этого хлама. Хламовник подключается динамически из соответствующих dll или паков. Специалисты -- подскажите!

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

Другой вариант. Вы пишите прогу в Visual C++ 6.0 под MFC. Вы будете наверно удивлены, тем, что объем вашего кода ехе-шника будет исчисляться несколькими десятками килобайт. Недостающие компоненты будут так же подгружаться динамически из библиотек. Но фокус состоит в том, что передавая кому-то ехе-шник вам скорее всего не потребуется озаботиться длл-ками, т.к. необходимые длл-ки M$ поумолчанию включает в дистибутив Винды.

Конечно, если вы хотите прилинковать библиотеки статически, то можете это сделать. Тогда ваш код буде автономен (на подобие Делфи-ехе-шника), а его объем будет сотавлять 150-200 кило.

Если, вы пишите консольное приложение на плюсах, и не используете MFC, то свой "шахматный" ехешник сможете уменьшить до 20-30 кило.

Что касается Шарпа. Тут объемы ехе-шников тоже будут маленькие, т.к. M$ опять таки подсуетилась и впарила всем желающим Framework, объем дистрибутива которого занимает несколько десятков мегабайт. Установив фреймворк один раз, вы получаете среду исполнения для многих программ от разных производителей. Это чем-то напоминает Делфи-подход с использованием пакетов, но отличается тем, что масштабы больше в разы.


Лет 15 назад, я отличным "железячником" и типа начинающим программистом. Я плохо знал Паскаль и так же плохо знал Си. В те времена бал правила Борланд. Я понимал, что мир программирования развивается очень динамично. Знать два языка -- это все равно что сидеть на двух расползающихся стульях. Поскольку времени всегда не хватает, то либо ты будешь знать два языка так себе, либо один, но очень хорошо. Поэтому возникла задача выбрать какой-то один. Я начал тестировать Turbo-C 2.0 и Turbo Pascal 5.5. Сначала я написал оболочку (типа борландовской IDE) с ниспадающими цветными менюшками и горячими клавишами. Простую (пустую) оболочку, не наполенную каким-либо функциональным кодом. Си-шный ехе-шник занимал что-то около 8-10 килобайт, в то время как Паскалевский раза в три-пять меньше. Я тогда подумал -- вот она истина! И стал писать на Паскале. Вскоре я понял, что Паскаль навязывает мне какие-то догмы... А когда попробовал вернуться на Си, то к своему удивлению увидел, что писать на Си оказалось легче, что для больших программ объем кода для Си и Паскаль ехе-шников становится с точностью до наоборот. Си-шный ехе-шник изначально имеет большой объем стартового кода, т.к. он делает больше работы, в отличие от Паскалевстого ехе-шника, у которого стартовый модуль очень маленький. И не смотря на то, что линковка Паскалевских библиотек происходила более изящно, и код должен был бы получаться более компактным я столкнулся с проблемами оверлейев! Это меня и доканало. В то время как на Си можно было задать модель памяти Huge и работать со всеми 640 килограммами оперативы, Паскаль предлагал оверлеиться по 64 кила. Такие шаманские танцы меня никак не устраивали.

Последний раз я брался за Паскаль, точнее за Делфи, где-то в конце 90-х. Поигрался и оставил в покое. Монструозные ехе-шники просто пугали меня не столько своим объемами, сколько тем, что меня напрягало то, что я непонимал чего там и для чего столько понапихано. Ну, конечно, были и другие веселые моменты... Короче, пройдя через все эти тернии я понял, что если я хочу программировать не только для компов, и при этом слыть хорошим специалистом, я должен чем-то пожертвовать, т.е. от чего-то отказаться. И я сознательно отказался от Паскаля/Делфи. А через какое-то время месяцев я почувствовал легкость в движении, как буд-то открылось втрое дыхание. Мне не нужно было скакасть с одного синтаксиса на другой. Мне пропала необходимость читать как минимум половину периодики и мне не нужно стало отслеживать пследние события в паскаль-сфере. У меня появилось свободное время! Но я его заполнил около си-шными делами и мой профессиональный уровень резче пошел в рост.
Разумеется, сначала я очень переживал эту потерю (паскаль-делфи), но вскоре я словил кайф от содеянного. Это чувство можно сравнить с тем, что вы наконец-то вынесли на помойку старую мебель, которую так долго не могли растаться.

Несколько лет назад я попробовал освоить Шарп с целью отказаться от Си и полностью перейти на него. Поддался M$ рекламе. Поигрался, поигрался и понял, что лучше Си/Си++ для меня нет.

Как я уже говорил, из-за ограниченности ресурсов (в частности -- вашего личного времени на доскональное изучение, копания и пр. работы), вы не можете хорошо знать несколько языков программирования. Широких специалистов не бывает. Бывают только узкие специалисты и широкие делитанты. Идеальный случай -- глубокое знание только одного языка. Вопрос, какого? Паскаль/Делфи привяжет вас к Винде и компам, ожидаются сложности под Линкусом и с микроконтроллерами. Шарп -- аналогично. Жаба, Васик, ПХП -- это языки совершено другого уровня. (Наверно Шарп тоже нужно сюда отнести.) И только Си/Си++ даст вам свободу пересещения с Винды на Никсы, с микроконтроллеров на компы. Вы поймете меня, если вам доводилось писать распеделенные приложения, когда часть функцианальности выполняется на компе, часть в МК. Когда наступает час-икс, и приходится не важно по какой причине часть функционала переносить из компа в МК или наоборот, то вам будет это сделать намного легче, если и там, и там проги созданы на одном языке.

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

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


// Текст не редактирую, т.к. за день очень устал и хочу спать.

Нельзя стать узким специалистом, не став, в строгом смысле, болваном. (Бернард Шоу)

Если писать левой ногой, то 25K. Но не Pascal.
Под DOS - менее 6K. Линукс менее 17K
Это я к тому, что и компиляторов приличных паскалевских так и нет.

Турбо-Паскаль 5 версии (более ранней нет на компе) ~2.5кб
Вообще-то интереснее было-бы сравнивать время для N>=16.

Не правда. В стандарте C89 переменные можно объявлять в начале любого блока
{
..

Стало быть, я искусственно себя ограничивал

zhevak
пацтолом
давно так ни ржал, аж спать перехотелось


AVR
задачка (об ущербности паскалевского оператора варианта case), пусть есть некая функция на входе которой есть строка параметров заранее неизвестной длины не превышающей N, на C можно строку параметров обработать так:



Ключевой момент, что в С оператор варианта может выполнить множество вариантов.

Как предложите быть в паскале?

PS: таких ущербных "ограниченных" мест у Паскаля очень много - костность for, дубовость условий (функции в условии вызывать можно, а присваивание делать нельзя, почему?), тупость/отсутсвие препроцессора, жесткая типизация, отсутствие икререментов-декрементов,
кстати про инкременты декременты, сравните:
a[ i++ ] = ...;
a[ i++ ] = ...;
и
a[ i ] := ...;
i := i + 1;
a[ i ] := ...;
i := i + 1;
а очевидных преимуществ - только строки (и может избыток теста? begin-end-procedure-then.. ну которые типа повышают наглядность кода)... Отход от правил паскаля для решения той или иной конкретной задачи делает код ничуть не более безопасным чем Cишный, зато капитально снижает его читаемость.

Понятно, что на Pascal'е сделать можно все то же, что и на C (особенно когда есть возможность применять asm вставки и/или подключать asm объектники), но как верно отметили выше - некоторые задачи будут сделаны через ж...А в сфере МК - это подавляющее большинство задач.

Помоему это также очевидно как и то, что в C через ж... приходится работать со строками.

зы: как видим, код на паскале практически в два раза короче Кроме того, работать будет однозначно быстрее, в т.ч. на AVR.


Не смешите, про ущербных и ограниченных



Строки чтоли экономим ?
a[ i ] := ...;i := i + 1;
a[ i ] := ...;i := i + 1;

А если так потребуется:
a[ i ] := ...;i := i + 2;
a[ i ] := ...;i := i + 2;
что будете делать ? Наверно, следуя логике, должно быть:
a[ i++++ ] = ...;
a[ i++++] = ...;



Си нам давали после паскаля, поэтому количество нецензурных выражений по поводу "работы со строками" в си не имело границ. Только одного этого было достаточно похерить си, что и было сделано после завершения курса. Паскалем же пользовался все 5 лет с удовольствием. Потом десять лет Дельфи. И где все это время был си ? И рядом с паскалем не лежал, точно. Даже сейчас, при наличии возможности использовать паскаль (для МК), при прочих равных писал бы на паскале. И вот это, как мне кажется, ключевой момент в споре - при одинаковом качестве объектного кода, что потенциально достижимо, удобнее, быстрее, безопаснее и качественнее писать на паскале. А недостаток паскаля во всей ветке, повторюсь, пока обнаружили только один - неявная передача параметров по ссылке/по значению. Что может фикситься пердупреждением. Которые, кстати, сишники, обычно, вынуждены трактовать как ошибки ) иначе прога однозначно не работает. В отличие от паскаля.


Остальную ерунду даже комментировать лениво. Прокомментирую вот эту:

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

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

Ныне покойный Дэвид Круглинский в своем бестселлере "Основы С++ и MFC" говорил "Чтобы эффективно пользоваться каркасом приложений, его надо изучить досконально, а это требует времени. И если Вам придется осваивать и С++, и Wimdows, и библиотеку MFC (без OLE), то сделать что-то полезноеВы сможете не раньше, чем через полгода. Что интересно, на изучение толко Win32 API уходит примерно то же время."

Я неоднократно убеждался в верности этого предположения. На освоение Шарпа-ли, на освоение Lunux-ли, ARM7-ли у меня действительно уходило несколько месяцев. И только после прошествия этого срока я понимал, что только сейчас я могу говорить о себе тапа "похоже я начинаю что-то понимать, и похоже я приближаюсь к понятию специалист".

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


Прошу учесть, что все выше сказано не в адрес уважаемого Огурцова.

Вот собственно и квинтесснция проблемы - давали Паскаль, потом поверхам 'C', при этом ленивейшие преподаватели разве только перелицовывали слегка те-же учебные паскалевские задачи. При этом еще толком сами не зная ни того ни другого языка. Наблючаю лично уже не на одном поколении выпускников ВУЗов .
Работа со стороками в "C" не скрывает их физической сущности - в большинстве случаев примения именно 'C' это более, чем оправдано. Ну а если реально плотно работать, то ,например, Perl - будет действительно причина нецензурно поговорить и о Паскале за убогую поддержку строк .

Да уж выше давал три бинарника под три операционки - исходник у них один единственный. В текущем проекте процентов 10 исходников пришло еще со 186 контроллера, а 30 работали ранее под Линуксом. Еще около 15% для опортированы уже из текущего проекта на старое оборудование на 51 контроллере. Поддержка файловой системы в оригинале у ее автора работала на AVR. Ядро микроконтроллерной операционки лично использую под несколько разных ARM и MSP430, хотя ее портов на самом деле много больше. Вот такая, понимаш, реальная картина мира за пределами стен учебных заведений и простеньких учебных-же задач по работе с несколькими строчками.

Не забывайте про возможность создания граблей. Паскаль - наиболее граблеустойчивый язык, из тех что я знаю. С# - тоже весьма неплох.
А про "граблеустойчивость" Perl`а я даже говорить не буду - Perl - это что-то с чем-то.


Да уж. Но если только в ваших операционках по две функции - printf и getchar.


зы:

Преподаватели у нас были PC-неграмотные - знание EC мешало. Так что все, что в институте изучали, изучали самостоятельно. И программирование и электронику. Базовые вещи, типа вышки, дискретки и т.д. - это конечно давали хорошо. Правда, не все брали )

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

другой пример. сделал я для Windows DLL, расписал интерфейс - все путем. DLL, разумеется, писал на Delphi. но само собой, вызовы STDCALL и т.п. - все как положено. один знакомый, много лет работающий с MS VC попытался ее использовать - и не сумел. говорит, что-то не то в возвращаемом значении... вы, конечно, скажете - виновата Delphi, что не умеет правильно создавать экспортируемые функции... однако же callback-функции в коде Delphi (тоже STDCALL), которые порой нужны для WinAPI, сама Windows прекрасно использует - значит, интерфейс правильный? я делаю вывод, что не все благополучно и в VC, если обычную DLL надо делать "под него"...

еще пример. большинство существующих уязвимостей Windows и *nix обычно связаны именно с особенностями Си (и даже С++) - одиозные переполнения буфера, форматные вводы-выводы, отсутствие контроля типов указателей и т.п. Эти нюансы, помноженные на случайные ошибки или некомпетентность(невнимательность) программиста (что в условиях современного программирования в стиле аля-цейтнотфорева повсеместная практика) дают уязвимости, баги и т.п. Ну что мешало сделать на уровне языка некий фильтр "глупости", как в паскале? сколько бы ошибок даже не родилось бы! И об этой "недодумке" Кернигана и Ко никто не вспоминает...

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

А никто и не говорил что если Вы что-то написал на Си - это уже по умолчанию кросплатформенное. Наличие компиляторов почти для всех архитектур и ОС даёт возможность написать кроссплатформенную программу, а как Вы напишете - это ваше дело.

Брал исходники и от восьмибитовиков. Неоднократно. Весьма часто написаны небрежно в исключительно "восьмибитовом" стиле. В таком случае после небольшого достаточно механического приложения рук (обычно достаточно паковки структур, разборок с 16bit интами, обилием 8bit переменных и знаковостью char), они беспоблемно работают на любой, в том числе и первоначальной, платформе. Просто их авторы, э.... несколько бездумно подходили к делу. От языка это никак не зависит. Отдельные места естественно, могут быть более четко нюансированоы уже под конкретный компилятор для достижения того-же быстродействия, например. Но работоспособность сколь-нибудь разумно написанного кода не нарушается. Лично мои исходники СВОБОДНО бродят между платформами.

+1 Но это еще как-то хоть как-то объяснимо. А вот есть еще более замечательное - исходники для AVR под IAR-це не компилятся на G-це-це. Так, извините, задача писать программы или заниматься с ними сексом ? Это вроде бы несколько разные вещи ? Вот уж тут точно, для первого подходит паскаль, для второго - си

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

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

P.S. не сочтите за продолжение холивара. я устал. просто философствую...

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

хочу сказать, что достичь "крутизны" легче всего внешне: приехал на джипе - ты крут (джип папин), на тебе штаны от GUCCI - ты крут (штаны китайские, но этого никто не знает), на шее цепь до пупка - ты крут (цепь из самоварного золота)... пишешь на Си - ты крут (пишешь хелловорды)... то есть вступление в клуб избранных как бы автоматически делает тебя умнее, лучше и т.п. но ведь это не так, тем более что вступление в клуб - свободное и не требует реальных усилий... действительно асов-программистов единицы/десятки на город средней величины, а считающих себя таковыми - едва ли не все, кто за компом сидит. и если посчитать их количество (сидунов) - вот вам и массовость Си... те 5-10 тысяч интеллектуалов от Си, что есть на страну, а может и планету, не моргнув глазом сменили бы язык и не потеряли бы своего имиджа - им не нужен Си (алгол, ада, паскаль - допишите сами), чтобы быть гениями... а остальные - массовка...

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

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

Компилятся на 99%..100% (99% AVR и 99,99% для ARM). Просто не нужно пользоватся НЕНУЖНЫМИ ДОПОЛНИТЕЛЬНЫМИ прибамбасами от производителей компиляторов, и останется только подправить возможные межплатформенные отличия отданные стандартом на откуп производителям. А вот о том, как набивший оскомину Bilder под каким-нибудь донельзя убогим Паскалевскм компиплером для AVR компилится.... Вот это действительно практически никак, если речь не идет о банальнейшем коде уровня 2 +2 = ?, или построенном на вызовах многочисленных волшебных "компонентов" из неведомых библиотек, не являющихся, кстати, неотъемлимой частью языка.

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



Не только такие. Я в т.ч. О какой кроссплатформенности можно говорить, если проект не собирается даже на практически всем готовом. И приходиться разбираться месяц-другой и т.д. с чем угодно - с ос, пактеами, компиляторами, дистрибутивами, ide, и еще чем попало, но только не непосредственно с программированием. Все это конечно же на фоне це. А сколько _минут_ (вместе с установкой дельфи!) заняло создание вашего первого приложения в дельфи ? Я вот до сих пор в шоке и в восторге одновременно.

Да уж... Создаётся впечатление, что работа на Паскале рождает философов, а на С - циников...
С чего бы это?

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

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

Т.е. если dll, сделанные на Delphi не работают под VC, а dll сделаные на VC работают под Delphi, то виноват VC? Может надо где то в консерватории поправить?

Уважаемые спорящие. Посмотрите на мир микроконтроллеров шире: ест не только AVR. Взглянув на другие семейства (в том числе от Freescale, AD и др.), посмотрите на имеющиеся средства разработки для соответствующего семейства. Часто у разработчика просто нет выбора в инструментальных средствах и спор становится бессмысленным. Спор "что лучше паскаль или си ?" религиозностью отдает. (IMHO)

Ну вот и расскжите, пожалуйста, имено о том, как лично Вы "просто открываете и пересобираете" свои дельфийские исходники под AVR. Весь внимание.




Он отдает глупостью, поскольку на самом деле "Паскаль", как инструментальное средство просто не существует, а все разговоры за "Паскаль" всегда сводятся к разговорам о некоем "Делфи" существующем исколючительно на PC платформе и наиболее массовый стиль программирования на котором сводится к вызову всевозможных DLL и непрерывный поиск в интернете "компонентов" для выполнения любых, даже самых элементарных действий. А так-же, в качестве демонстрации собственной 'крутости' выкладывание в тот-же интернет своих "компонентов" решающих "грандиозные" задачи недалеко ушедшие от 2+2=?. После отрывания такого "программиста" от Win и PC на этом форуме возникают темы "где взять Паскаль для микроконтроллера" и (после нахождения одного из обмылков авторы которого решили обозвать свое детище "Паскалем" ) - "дайте библиотеку".

cdecl не пробовали писать?

Кстати как насчет ущербного паскалевского оператора варианта? Не принимаете очевидное? То что знаток (поверхностно знающий) множества языков, Огурцов, привел в качестве аргумента даже смотреть не интересно, на C ведь тоже IF-ов можно наставить.


Как вы в Delphi контроллируете типы при взаимодействии с функциями DLLки? Какой есть для этого механизм?

Если я Вас правильно понял, то Вы во всех случаях пользуетесь только своими "библиотеками"?

Типичный образ ламера, который кстати никак не связан с каким-то конкретным языком.
Ламер он во всем такой.


Вы правы, что ламеров везде хватает , в т.ч. и занимающихся "батонокиданием" на Delphi.
А вот насчет процента, на мой взгляд, среди Сишников % оных меньше, чем среди Delphi'стов.

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

Вы, вроде бы, по-русски неплохо пишете, попробуйте прочитать мой тезис еще раз.


Щаз. А линку выше вы не видели ? У меня целый диск с паскаль-компилерами валялся, датирован годом так 2000. Было там и под всеми любимый (ранее) пик. А за 8 лет мало ли еще чего понаписали. Кстати, вот что удивительно, раньше так же, как и про паскаль с си кричали: пик - рулез, авр - маздай. И что-то, извините, про пик сейчас редко слышно, а авр у всех на слуху. Так что ждите, для 32-битников и паскаль появится качественный, а там и народ подтянется, при том, что массово, а не как си - единицы.


Да, потому что все это экономит время и генерально увеличивает надежность. Героям, конечно, этого не понять.


Знаток си defunct мог бы для приличия скомпилить свой код под gcc, например, для avr, а потом то же самое переложить на if и скомпилить еще раз. И удивиться. И больше никогда дурацкий сишний switch не юзать. А паскалевский case не противопоставлен только потому, что у него иной, более оптимальный принцип работы, и по быстродействию он порвет сишный switch как тузик грелку. Ну в худшем случае, будет работать так же, как и конструкция из if. Впрочем, для того, чтобы это понимать, нужно хотя бы чуть-чуть знать паскаль. Но это ж сишникам в падлу - им, гагарам, недоступно наслажденье битвой жизни: гром ударов их пугает (с)

зы: C#, Delphi 7.0, GCC, SQL, 1C, Foxpro 2.6 в порядке убывания кайфа от программирования. И еще столько же, от которых тошнит.

Вот именно, что "валяется". Валяется многое что (Классический Паскаль в основе очень прост с точки зрения компиляции и вполне годится для темы дежурного курсовика, что и определяет количество валяющегося "материала"), речь идет о том что со сколь-нибудь реальной работой облом.

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

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

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

"Остапа понесло"

Можно ламеру вякнуть?
Решил для чистоты эксперимента сделать в Дельфях вообще пустой проект - форма со значками закрытия, сворачивания-разворачивания.
Он весит 359 Кб

Таким образом, рабочая часть "восьми ферзей" влезает в 374 - 359 = 15 Кб

но ведь так же описанные функции принимаются самой ОС и работают с нею - не значит ли это, что в консерватории все ништяк? мне не доводилось юзать VC и я не могу сказать, в чем именно проблема. но почему-то не верю, что Delphi создана настолько тупым образом, что ее DLL отличаются от любых иных DDL. думаю, такой проект никогда не имел бы такого колоссального коммерческого успеха, какой был у Delphi - надеюсь, про этот успех все программисты помнят?

cdecl отличается от stdcall местом "чистки" стека при вызове функции: для cdecl это делается в вызывающей программе, а при stdcall этим занимается сама функция. для экспорта из DLL рекомендовано использовать stdcall - как я понимаю, это стандартный способ обращения к функциям DLL. мне кажется, что VC при загрузке DLL долна использовать не традиционный для С способ, а именно этот... я не прав?

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

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

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

Да, кстати о ламерах. в организации, где я работаю, программистов много, пишут программы для весьма серьезных объектов. но либо мне не повезло, либо они и в самом деле такие - но то, какой код они пишут (тот, что доводилось видеть), лично у меня вызывает просто шевеление волос! не смотря на то, что 90% программ - для встраиваемых систем, ну ни малейшей оптимальности, о которой тут говорили: если в функции 5 циклов - введено 5 итерационных переменных, называются все они типа i1, i2, i3 и т.д., глобальные переменные раскиданы везде - от хидеров до промежутков между функциями в исходниках (короче стиль "собаки" - где приспичило, там и нагадила)... зато очень много вложений операторов друг в друга (ну, типа когда в пре- и пост- части for пишутся чуть ли не поэмы) и т.д.
все знакомые мне программисты - достаточно молодые парни (2-4 года стажа), все учились на программиста, все пишут на Си и презирают паскль за убожество и "длинность"... каждая их программа месяцами налаживается на объектах... ужос!

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

Главная отличительная черна качественного компонента, как и качественной сишной библиотеки в том, что они практически не встречаются в свободном виде. Результат-же использовани чего попало не радует (ну разве только автора-ламера у которого "все работает").




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

я думаю, что неаккуратность и лень - вовсе не следствие изучения паскаля... зато явная причина ламерства. не думаю, что те, кто так же учит в ВУЗе Си меньшие ламеры - скорее, гораздо бОльшие...

возможно, вам покажется странным, но точно так же, как для GNU-сообщества сишников, для паскалистов (и в том числе для Delphi) имеется очень много качественного и бесплатного софта, в том числе и компоненты. лично я для своих задач полностью удовлетворен комплектом JVCL - поиски прекратил много лет назад, сразу, как обнаружил этот набор. чего не хватает - лично мне проще сделать самому, чем искать в сети...


сомневаюсь. я говорил и повторю снова: ламерство - оно "кроссплатформенно"
просто это к слову о том, что в Си ламеров меньше...

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

Кстати отключить это можно средствами компилятора.

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

Достаточно посмотреть те примеры которые идут вместе с Delfi. И, я на 200% уверен, что проффессионалы C++, которые давно не используют Delfi - слегка будут удивлены.

Многоэкранный текстовый редактор, со всеми сервисами. Текст программы - 3 файла общим весом 20858 байт (исходный текст).

Проект WebServises.
Client - Delfi::Bilder == 2/15077 :: 7/22179 (в полтора раза!!)
Server == 5/9550 :: 15084 (в 1.6 раза)

Говорите "begin - end"?

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

В этом и есть разница языка более высокого уровня, которым является Pascal.


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

Далее будет врят ли Паскаль. Скорее всего что-нибудь платформенно независимое. Загадывать сложно. Но факт состоит в том, что нет идолов. И Си неизбежно уступит место другим языкам.

Я почему использую Паскаль (Delfi)? Да мне до лампочки сколько он мне нагенерит!!! 100кб или 10мб в тех приложениях которые я пишу. Когда мне будет до лампочки сколько кб займёт моя прога в камне, а язык более высокого уровня предоставит мне лучший сервис, то я с удовольствием перейду на него.

Одно дело когда мы сравниваем средства одного порядка. Другое если сравнить например C++ от IAR и DELFI (условно конечно). Чтобы я, например, мог также запросто создать графическую оболочку на своём дисплее (в МК), чтобы также смог работать с файлами и т.д. И представим, на секунду, что результирующий код легко влазит в моё устр-во.
И что? Я откажусь и буду сам что-то ваять - вылизывать байты? Да не в жизнь! Кто сейчас вылизывает байты на ПК?

Консольный компилятор dcc32.exe, с ключем -сс --> будут желаемые 15кб.

а еще интересная тема скрыта в истории...
сначала была Delphi.
эта среда (не язык - именно среда) породила такой фурор, что борландовцы решили сделать и для программистов С\С++ аналог (билдер знаменитый) - чтоб им не обидно было (ибо трудоемкость создания одного и того же на С/С++ и Delphi отличалась в десятки раз!)... заметьте, какое отношение тогда было - паскальные программеры жалели сишных... и борландовцы портировали на С++ свою VCL, причем по простоте душевной сделали это до наивности просто: научили собственный С++ компилятор "понимать" исходники на паскале... потом взяли и пересобрали VCL прямо из паскалевских исходников на С++... и тем самым вырыли себе яму... с этого момента звезда Delphi пошла на закат... причем снисходительно-доброго отношения со стороны С/С++ ни Delphi, ни ее последователи не получили и не получают до сих пор... наоборот, всяческие поношения
вот она, черная неблагодарность...

среди ламеров

еще больше окучить и постричь ламеров...

поскольку на расплодившихся ламеров обратили свое внимание и другие более крутые фирмы и забрали их к себе показав им такие красивые IDE c офигительными наворотами на кнопках мышки! Ну и тут еще и WEB-программимрование подоспело . Но дело Борланда не умерло те, первые ламеры заматерели и начали рожать планы обучения в росийских школах и ВУЗах Причем

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

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

Во вчерашних примерах: оставил только проверку стека, остальное - не надо.
По остальным пунктам хоть и обширного поста +1
Кстати - в лазарусе собрал демку про OPENGL -


Пробовали реально ? Под win32 должно быть больше по-любому

От версии Delphi зависит.

Оффтоп: N ферзей: http://nqueens.ing.udec.cl/

Да что вы знаете про матросов, салабоны! (ЦЭ)

До делфей был турбопаскаль. Между прочим, даже кроссплатформенность была некоторая, потому как третий тп я, например, пользовал в двух вариантах, под писюк и под CP/M. Даже была у меня самописная графическая библиотека в трех вариантах, под три таргета (одна машина под CP/M, вторая - тоже восьмибитка, только другая, и третья - банальный 8086) подключалась при помощи $I (раздельной компиляции третий тп еще не умел), а вот основной код был практически идентичный (единственная проблема была с разными кодировками русских букв). И ничего, все собиралось и работало.

А потом турбопаскаль научился раздельной компиляции. И Борманд придумал библиотеку типа теперешнего VCL, только в текстовом режиме работала. Я с ее помощью никогда не писал, посему название в голове крутится, а вспомнить не могу. Но факт в том, что была. И ее весьма широко использовали.

А вот пример из современности:

Вот где-то года 2 (или уже 3) назад начал я один проект, который представлял собой гейт ICQ-мой протокол. Сначала были найдены исходники более-менее вменяемого делфийского компонента для создания аси, после чего он был доточен под личные нужды и исправлены самые вопиющие ошибки (ну, например, сразу был отстрелен какой-то компонент типа индисокет с заменой на вменяемые send, recv и select). В каком-то виде это было запущено в работу. После того, как количество одновременных коннектов достигло сотни, у меня стал вопрос или об апгрейде сервера, на котором работал этот гейт, или, как говорится, чтото решать. Было принято волевое решение "чтото решать" - постоянные утечки памяти в VCL, необъяснимые глюки в VCL-ных тредах и пляски с бубном просто достали. Кроме того, на горизонте маячила необходимость перевода гейта на никсы.
Вообщем, выбросил я нафиг делфя и на основе найденной в инете более менее вменяемой айсикюшной библиотеки с исходниками на плюсах было исполненно аккуратное кроссплатформенное приложение, крутящееся на сервере месяцами, обеспечивая в среднем одновременно триста соединений, без утечек и тормозов. И совсем мало по памяти. Вопрос апгрейда сервера снялся сам собой.

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

Вот такая вот музыка

Да! Борладовцы были первые, которые начали делать ПРЕЖДЕ ВСЕГО не компиляторы, а ПРЕЖДЕ ВСЕГО IDE, Турбовижины, самодельные "Базы даных", массу готовых библиотек... Это реально привлекло в программировние людей, многие из которых стали ламерами ввиду изначально заложенной прадигмы по воспитанию потребителя их продукции. В заметной степени и я, до мозга костей железячник, хотя и отдавший в свое время немало дней и ночей Фортрану, пришел в конце 80 в реальное а не "научное" программирование Благодаря их "Турбо" продуктам. Заметное количество из хоткеев борландовской IDE живут в моих редакторах до сих пор , хотя сама их IDE использовалась в первоначальном варианте совсем недолго. Иx BCC 3.1 и TASM используется мною (c самодельными библиотеками и линкером) для программирования старого 186 железа до сих пор. Код, правда, гененит по нынешним временам отвратный, но переползать на, например, что-то типа Watcom бессмысленно. Их TASM лучший до сих пор.
В всем этом ничего страшного нет - процесс движения многих навыков и профессий в массы естественнен и неизбежен. Еще десятки лет назад "шофер" было исключительно профессией. Сейчас много, много больше, чем профессионалов "Блондинок за рулем". Для "болондинок" работает целая индустрия старающаяся (и не безрезультатно! и небесполезно! для всех участников) сделать программирование вождение безопаснее, удобнее, безответственее и не требующим никаких особых знаний (тем более знания железа ). Это все естественно и не ново, и, повторюсь, нормально. Только вот требовать какого-то особого "снисходительно-доброго отношения со стороны", наверное, с их стороны несколько чрезмено .

TurboProfessional.

А я использовал. Один из первых программаторов делал с меню на его основе.


ЗЫ: Только не Борланд это написал. А Борланд потом приобрёл эту фирму.


Давайте будем объективными. Это имеет отношение к языку Паскаль как таковому? Это имеет отношение к его реализации. Причём именно к реализации библиотек в виде VCL.
Могло быть, что на основе плюсов, например с помощью Borland C++ была бы таже шляпа? Естественно. Именно эта же шляпа и была бы, так как таже VCL.
Так какое отношение это имеет непосредственно к теме обсуждения?

Вон сколько нареканий на некоторые компиляторы С мы наблюдаем.

http://www.tiobe.com/index.php/content/pap...tpci/index.html
http://forum.vingrad.ru/forum/topic-162297.html

Мимо кассы. Какое отношение конкретный компилятор имеет к возможностям языка?

Все равно, что сказать - возьмите паскаль компайлер от микроэлектроника и попробуйте сложить два "real" аргумента. И протащиться удивиться от результата. И больше никогда дурацкий паскалевский REAL не юзать.


TurboVision. У меня по ней книжка до сих пор валяется. Классная вещь была - красиво построена.

Не, не так, нужно еще добавить для порядку "бей паскальников, спасай Россию!"



Не, я бы сказал, ламерами не становятся, ламерами рождаются.



В общем, обида, видимо, в том, что на умненьких, беленьких и пушистеньких сишников никто не обращает внимание и к себе не забирает. А я вот вам таки скажу, какой язык программирования самый правильный - идите на job.ru и смотрите цены. Я надеюсь никто из присутствующих не будет спорить с тем, в каком месте находится си/встраиваемый си ?



Утверждаете, что GCC - плохой компилятор ?

Нет, gcc хороший компилятор плюс еще и бесплатный, но он имеет и недостатки. Для AVR - это например неэффективная с т.з. быстродейтсвия организация стека и как раз неэффективная генерация кода для switch. Однако, есть компиляторы более эффективно справляющиеся с оператором switch - VS, RVDS, IAR... Может лучше их асм код посмотрим?

Эффективность и правильность работы Real операндов ведь тоже не зависит от языка, это проблема конкретного компилятора.

По оператору варианта. Паскаль не дает возможности выполнения множества вариантов, C - дает.
Вы языки хотели сравнить или компиляторы?

Если первое - тогда почему просто не примете факт - по оператору варианта Паскаль слил?
Есои второе - так скажите наконец - где же взять эффективный компилятор Pascal для AVR? ;>

Ничуть, все легко и красиво реализуется на if - не надо без необходимости умножать сущности (с). А вот си слил свой switch по скорости. И если вы не понимаете, почему, почитайте про case самостоятельно. Я скажу более, для МК паскалевский case - самое то. А сишный switch, если вы хотите сказать про его "дополнительные" возможности - красиво заложенные в код грабли.

зы: про компиляторы - смотрите ссылку, которую дали выше, _самостоятельно_

Огурцов продолжает нести пургу . Сколь-нибудь вменяемый компилятор прекрасно оптимизирует баланс между if() и switch() при этом получая или абсолютно идентичный код для if() и switch() в простых случаях применения, либо много более высокоэффективный по скорости табличный код для сложных switch(). При этом switch() выигрывает и по читаемости (в невырожденных случаях) и всегда по расширяемости.
По второй причине я достаточно часто использую switch() и в вырожденном варианте в качестве 'рыбы' для возможного последующего расширения. Кусок реального исходника:

Причем код при этом получается ни на бит не отличающийся от if()