[_Pasha 0]

Exe-шник получился 374 Кб в Дельфи 7. Найдены все 92 варианта, ура!

Ура-то ура, но у меня на FPC-2.2.2 с нормально настроенной оптимизацией ехешник занимает 34кБ.

Такшта делфи... вот когда лазарус заживет полнокровной жизнью, станет веселей. Хай живе Free Pascal!

[zhevak 0]

Уважаемые Жека и 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$ рекламе. Поигрался, поигрался и понял, что лучше Си/Си++ для меня нет.

 

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

 

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

 

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

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

 

 

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

[Aesthete Animus 0]

Бывают только узкие специалисты и широкие делитанты

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

:(

[zltigo 0]

Ура-то ура, но у меня на FPC-2.2.2 с нормально настроенной оптимизацией ехешник занимает 34кБ.

Если писать левой ногой, то 25K. Но не Pascal.

Под DOS - менее 6K. Линукс менее 17K

Это я к тому, что и компиляторов приличных паскалевских так и нет.

8f.rar

8fd.rar

8fl.rar

[Leka 0]

Турбо-Паскаль 5 версии (более ранней нет на компе) ~2.5кб

Вообще-то интереснее было-бы сравнивать время для N>=16.

Изменено 11 декабря, 2008 пользователем Leka

[defunct 0]

Тут Вы неправы, хотябы потому, что С89 тоже требует объявлять переменные в начале функции и это мало кого смущало.

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

{

..

[Aesthete Animus 0]

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

{

..

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

[defunct 0]

zhevak

:a14: пацтолом :08:

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

 

 

AVR

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

 

 

void handle_DevParams( char *ParamStr, int size)
{
   ...
   switch(size)
   {
       case N: // самый старший параметр
            apply_n_0(ParamStr[--size]);
       case N-1;
            apply_n_1(ParamStr[--size]);
       ...
       default: // действия выполняемые всегда (даже при size == 0)
           save();
           ...
   }
}

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

 

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

 

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 через ж... приходится работать со строками.

[VCucumber 0]

void handle_DevParams( char *ParamStr, int size)
{
   ...
   switch(size)
   {
       case N: // самый старший параметр
            apply_n_0(ParamStr[--size]);
       case N-1;
            apply_n_1(ParamStr[--size]);
       ...
       default: // действия выполняемые всегда (даже при size == 0)
           save();
           ...
   }
}

 

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

 

procedure handle_DevParams(string ParamStr);
begin
   ...
  if length(ParamStr) >= 2 then
    apply_n_2(ParamStr[2]);
  if length(ParamStr) >= 1 then
    apply_n_1(ParamStr[1]);
  save();
   ...
end;

 

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

 

таких ущербных "ограниченных" мест у Паскаля очень много - костность for, дубовость условий (функции в условии вызывать можно, а присваивание делать нельзя, почему?), тупость/отсутсвие препроцессора, жесткая типизация, отсутствие икререментов-декрементов,

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

 

 

кстати про инкременты декременты, сравните:

a[ i++ ] = ...;

a[ i++ ] = ...;

и

a[ i ] := ...;

i := i + 1;

a[ i ] := ...;

i := i + 1;

Строки чтоли экономим ?

a[ i ] := ...;i := i + 1;

a[ i ] := ...;i := i + 1;

 

А если так потребуется:

a[ i ] := ...;i := i + 2;

a[ i ] := ...;i := i + 2;

что будете делать ? Наверно, следуя логике, должно быть:

a[ i++++ ] = ...;

a[ i++++] = ...;

 

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

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

 

 

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

вы не можете хорошо знать несколько языков программирования

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

Изменено 12 декабря, 2008 пользователем Огурцов

[zhevak 0]

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

 

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

 

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

 

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

 

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

 

 

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

[zltigo 0]

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

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

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

и всякие рассуждения про кроссплатформенность си ничтожны.

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

[VCucumber 0]

например, Perl - будет действительно причина нецензурно поговорить и о Паскале за убогую поддержку строк

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

А про "граблеустойчивость" Perl`а я даже говорить не буду - Perl - это что-то с чем-то.

 

Да уж :( выше давал три бинарника под три операционки

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

 

 

зы:

при этом ленивейшие преподаватели

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

[ARV 0]

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

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

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

 

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

 

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

 

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

Изменено 12 декабря, 2008 пользователем ARV

[msalov 0]

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

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

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

 

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

[zltigo 0]

кроссплатформенность... гм... беру исходник FFT для C8051F120 и пытаюсь его....

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