Вышла новая стабильная версия FreePascal.

>Когда как:

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

В FPC перегрузка операторов имееися... Равно как и шаблоны (ака генерики)...

> В FPC перегрузка операторов имееися... Равно как и шаблоны (ака генерики)...

Она и четыре года назад была? если "да", то я жестоко обманулся :)

Перегружать операторы и на Бейсике 2005 можно

> Перегружать операторы и на Бейсике 2005 можно

Предпочитаю компилируемые языки.

Бейсик 2005 - это компилируемый язык. Причем качество исполняемого машинного кода, довольно часто превосходит комплированный С++. Кому еще прочитать лекцию про JIT?

Вы сейчас мне напоминаете людей, кричавших начаная с 70 годов: Ассемблер это круть! С - отстой. Я не могу там управлять регистрами. И вааще работать напрямую с процом - это верх крутизны, там все можно написать.

>Потому что в (турбо) паскале подумали о такой вещи, как precompiled headers, которая сейчас, насколько мне известно, есть в оффтопичной студии и поддерживается qmake. Основные тормоза при компилировании сишного кода происходят из-за огроменных инклюдов. В особенности это верно для программ, использующих STL.

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

ЗЫ: Меня паскаль когдато учили потом сам спрыгнул на С/Python..., а недавно попросили перевести на Линукс "конторку" но так чтобы все их старые досовские проги на паскале работали и что удевительно пришлось только подбросить к ним библиотеки crt,graph,... чтобы пути в текстах прог не менять установить диалект паскаля в turbo pascal, включить потдержку некоторого синтаксиса, оптимизации и всё собралось и заработало на Линаксе!!! Так что проблем с миграцией паскалистов-делфистов на современную, надёжную платформу GNU/Linux нету. :-)

> Бейсик 2005 - это компилируемый язык. Причем качество исполняемого машинного кода, довольно часто превосходит комплированный С++. Кому еще прочитать лекцию про JIT?

Чисто теоретически, этот JIT действительно может быть настолько хорош, как говорят виндомаркетологи.

НО! Любой язык с JIT-компиляцией сохраняет главную проблему платформы windows - очень "дорогой" fork(), пусть потом всё и летает реактивно.

>И постами выше доказано что и на паскале можно кодить вполне хорошие вещи и даже зарабатывать бабки )

Брайан Керниган вполне убедительно разобрал, почему на изначальном Паскале Вирта нельзя написать ничего серьезного. Зачем пичкать это дело пичкать С/С++ - ными стероидами лично мне не понятно.

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

А что делать если мне *действительно* нужен динамический массив? Связанные списки не предлагать, там 16 байт указателей на каждый следующий и предыдущий элемент + MCB; время доступа к произвольному элементу - линейное в то время как у массива - константное. Массивы заведомо большого размера - это бомбы с часовым механизмом.

Это говорит тебе не маркетолог МС, а программист .Net, узнавший, что такое быстродействие С++. Попробуйте хотя бы элементарный гармонический ряд: C# vs VC++ 2005 vs MinGW vs Java

>Когда как

Старый (2.0.4) компилятор там, надо бы на новом разницу посмотреть

>Потому что в (турбо) паскале подумали о такой вещи, как precompiled headers, которая сейчас, насколько мне известно, есть в оффтопичной студии и поддерживается qmake. Основные тормоза при компилировании сишного кода происходят из-за огроменных инклюдов. В особенности это верно для программ, использующих STL.

Дак паскаль то _изначально_ и языком програмирования небыл! Так одому професору надо было научить студентов _теоритически_ написанию програм вот он и придумал понятный для студентов синтаксис, а уже потом студентам он настолько понравилса что они написали его реализацию. Да, первые версии были несовсем хороши, но и было время конца 80-тих когда обектный Pascal-5.0 жестко рвал C по всем параметрам! Были времена Делфи итд. Но небыло свободной реализации этого языка потому и програмисты под Линукс его и не выбирали. Сегодня ввиду малого использования паскаль не очень бистро развивается но с появлением свободного компилятора и современных IDE для простой и быстрой разработки ситуация может изменится. Это простой для человека язык с бистрой компиляцией, быстрой надёжной работой програм, простой и лёгкой связью с сишними библиотеками GNU/Linux через конвертор хедеров в паскалевские файли/юниты, кросплатформенностю, ещё может занять достойное место в мире разработок програмного обеспечения.

> Это говорит тебе не маркетолог МС, а программист .Net, узнавший, что такое быстродействие С++. Попробуйте хотя бы элементарный гармонический ряд: C# vs VC++ 2005 vs MinGW vs Java

Не уводите в сторону. Мне для счастья хватит и того, что "а программист .Net, узнавший" признает дороговизну форка на винде. Или Вы не знаете, что есть форк()?

А про (.* vs){3,3) vs .* давайте поговорим отдельно. Пример кода для сравнения в студию.

>>Вот какое "говно" пишут на "говне" FreePascal-е, причем, похоже, в одиночку.

По ссылке сходил. Во Фьючерсы заклянул. Комменты будут:

+1 . Только кавычки убери.

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

>>Когда как > Старый (2.0.4) компилятор там, надо бы на новом разницу посмотреть

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

А что, в Линухе до сих пор процессы с помощью форканий создаются? 30 лет так и топчемся на месте?

>А что, в Линухе до сих пор процессы с помощью форканий создаются? 30 лет так и топчемся на месте?

А что, в неужели в Винде каждый тред может изуродовать память другого треда?

> А вы спросили скока автору этой проги пришлось хидеров сишных переписывать? ....

Учить матчасть! man h2pas; man h2paspp

Да именно этим С и получило в Юниксах фору! Были только проприетарные реализации Паскаль в ДОС - для бедных и в МАC - для буржуев.. А свободной под *nix небыло ибо *nix изначально на С писали и всё в нём тоже на С. Но сегодня когда есть свободный компилятор Pascal в Линуксе и сностное IDE для него, ввиду простоты понятности и быстрой обучаемости паскаля количество програмистов на нём может возрасти, а с этим и количество написаных програм. С интерпретаторами паскаль рядом ставить нельзя ибо на нём можно реализировати и целую ОС, а по быстродействию он всегда на пятки С наступает. А сколько человеко часов вложили в компилятор С, а сколько в Pascal???

Я не знаю где как но видел разные реализации паскаля (не всегда полноценные) на украинском с начала 90-тых и до теперь (код закрытый под оффтоп но в wine идут) и експеременты показали что люди которых не возможно было научить програмировать НИ НА ОДНОМ ЯЗЫКЕ в этих "локализированых паскалях" програмировали сразу! Более того пошли дальше в експерементах, на обласной олимпиаде с информатики поставили деба с таким "паскалём" под вайном, дали 30 минут инструктажу (никто с детей его до этого в глаза не видел, а были дети которые програмировали только блок схемы на бумаге, с сёл где и компьютеров нет!!!) и дети освоили его в обёме позволившем успешно _решить_ поставление задачи!

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

>А что, в Линухе до сих пор процессы с помощью форканий создаются? 30 лет так и топчемся на месте?

Нет скоро на Дилоновские LWKT перейдём. А если серьёзно то glibc кажется уже их имеет, а внидрять их в само ядро не целесообразно так как приросту производительности считают что не будет.

>Все нормальные дельфинисты перешли на .NET, ненормальные подохли от >голода.

Все нормальные пишут попрежнему на Delphi и потихоньку начинают применять Java.

> Все нормальные пишут попрежнему на Delphi и потихоньку начинают применять Java.

Зачем переучиватся на Java. FreePascal даёт портируемый кросплатформенный код и бистро работающий бинарь без всяких виртуальных машин. Lazarus уже приближается по функционалу к Делфи, а в ввиду капца последнего скоро его и перегонит, кроме того код Lazarus даёт бинарь как для GNU/Linux так и для оффтопа без проблем...

С одного трупа на другой труп? Стервятники какие!

Поглядел немного этот Pixel Editor... Шустрая штуковина! Интерфейс ваще летает! Под Linux такой скорости отрисовки ещё не видел. Видать интерфейс реализован поверх SDL, отсюда и скорость. но с изменением размеров окна из-за этого проблемы.

> Видать интерфейс реализован поверх SDL, отсюда и скорость.

Именно так. Весь GUI там свой, через SDL.

> К стати компилятор паскаля очень бистрый и в разы превосходит сишные (почему???)

Потому что алгоритмы разные. Паскаль специально разрабатывался так, чтобы программы было проще парсить и компилировать. В те времена это было принципиально. Да и сейчас, в общем...

> но проги ~1,5 раза медленые

Потому что разработчиков меньше. Да и таланты больше вокруг gcc сосредоточены.

> также Pascal даёт очень коректно работающий с памятью код и его програмы считаются более защищёнными..

Это весьма спорное утверждение. Средства RTL ObjectPascal позволяют избегать скользких ситуаций, в которых возможно переполнение стека, утечки памяти и т.д. Но нет ничего невозможного. :) Особенно, для "чайника", который не знает что делает. С другой стороны, грамотное продумывание программы, позволяет "творить чудеса" и в C. Что и было продемонстрировано в своё время Бернштейном. Вот только наука в прок не пошла...

> Наконец вспомнилось мне одно высказывание Линуса Тордвальдса

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

Вот, что про C# скажу. Язык - это чисто коммерческий и идеология кодинга
на нем коммерческая. Это означает, что программисту плевать на производительность программы, красоту кода и т.д.
Единственное что его интересует - это чтобы быстро заработало.
А кодится на нем действительно быстро. Перефразируйте следующий код на C\C++,Pascal также компактно. Особенно на великий и могучий C, или супер-мега стабильный Паскаль.
 
   string str = "eee rrr\nttt\twww";
   string[] strs = str.Split(' ', '\t', '\n');
   foreach (string s in strs)
      Console.WriteLine(s);

Я кодить начинал с Паскаля и C. А когда на работе первый раз столкнулся с VC++, то подумал, что в Microsoft либо ненавидят C++, либо клали на всех программистов. Но после долгой медитации до меня дошло что мелкософт клал на ВСЕ. 

>на Линаксе

К логопеду, быдло!

Есть и динамические массивы - Array Of <Type>... Перед вставкой следующего элемента банально память ему выделяешь и рулишь...

Delphi далеко не "капнулсо", а просто логически продолжился в Turbo Delphi... И хотя разработка на нем быстрее (в частности из-за более высокой скорости линковки) и нет множества мелких (но досадных) глюков, он не кроссплатформенный, не свободный и платный... Хотя цена и вполне себе посилна даже для программиста-одиночки...

> Кто и что на нем пишет, кроме школьников?

Лишь бы обосрать, что за люди...

Ну например "Галактика" пишет на нём свой язык, на котором в свою очередь написана ERP Галактика.

Достаточно?

JFYI пипл из "Галактики" имеет отношение к развитию RTL фрипаскаля.

> ... в Turbo Delphi... И хотя разработка на нем быстрее (в частности из-за более высокой скорости линковки) и нет множества мелких (но досадных) глюков,...

День юмора на ЛОР - в дельфи, оказывается, глюков нет ;)
Хотя, мелких может и нет - всё крупняк...

>Вот, что про C# скажу. Язык - это чисто коммерческий и идеология >кодингана нем коммерческая. Это означает, что программисту плевать на >производительность программы, красоту кода и т.д. >Единственное что его интересует - это чтобы быстро заработало. >А кодится на нем действительно быстро. Перефразируйте следующий код >на C\C++,Pascal также компактно. Особенно на великий и могучий C, или >супер-мега стабильный Паскаль.

> string str = "eee rrr\nttt\twww"; string[] strs = str.Split(' ', '\t', '\n'); foreach (string s in strs) Console.WriteLine(s);

>Я кодить начинал с Паскаля и C. А когда на работе первый раз столкнулся с VC++, то подумал, что в Microsoft либо ненавидят C++, либо клали на всех программистов. Но после долгой медитации до меня дошло что мелкософт клал на ВСЕ.

>anonymous (*) (11.09.2007 19:53:57)

Вот версия на джаве из трех строк:

StringTokenizer t=new StringTokenizer("eee rrr\nttt\twww"); while(t.hasMoreTokens()) System.out.println(t.nextToken());

>Перефразируйте следующий код на C\C++,Pascal также компактно. Особенно >на великий и могучий C, или супер-мега стабильный Паскаль.
>
> string str = "eee rrr\nttt\twww";
> string[] strs = str.Split(' ', '\t', '\n');
> foreach (string s in strs)
> Console.WriteLine(s);


char str[] = "eee rrr\nttt\twww";
char* delim = " \t\n";
char* tok;

tok = strtok (str, delim);
while (tok != NULL){
printf ("%s\n",tok);
tok = strtok (NULL, delim);
}


всего на 3 строки больше.

/anode

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

/anode

>Вот версия на джаве из трех строк:

>StringTokenizer t=new StringTokenizer("eee rrr\nttt\twww"); >while(t.hasMoreTokens()) System.out.println(t.nextToken());

неправильно.
Пустые токены растеряли.

Пользуйте string.split - как в шарпе (точнее последний скоммуниздил у жавы)

имеется в виду - два делимитера "\n\n а \nа"
(это проблема StringTokenizer'а)

/anode

> Это означает, что программисту плевать на производительность программы, красоту кода и т.д.

_Плохому_ программисту - надо заметить.

Давеча была написана прога на C, фильтрующая данные с большого железа. На одном фреймвоке один товарищ было написал. Час считает. А данные могут прийти и на порядок больше.
Ваш покорный слуга переписал на Ц, со своими хешами конечно и алгоритмами (никаких фреймвоков). 1.1-1.3 секунды - максимум. За день даже была наброшена морда в виде тикля.

>по использовании памяти, коректности и безопасности работы с ней в переди будет fpс.

/тихо/ Java, Java!

нет, вы почуствуйте разницу - больше 3 порядков!

Ещё пример из жизни.
3 проекта. делают примерно одно для юзера (возвращают странички:)
лайфрей - использует все мыслимые и немыслимые фреймвоки - от стратс,спринт,тайлз до ОРМ.
У одного крупного <...> крутится. Только несколько клиентов в секунду на определённом железе при приемлемом ожидании. Другой товарищ - использует при том-же примерно железе - минимум фреймвоков, получая до 60-80 одновременных клиентов на машину.
Я взял подобную машину и написал всё с нуля, в крайнем случае используя System.arraycopy и свои алгоритмы - оптимизированные под задачу (сравнения делаются на примере жабских проектов, т.е. на жабе).
1000 клиентов лехко при отдыхающем процессоре (это когда не было - epoll-ов, но зато с зелёными нитями - на первой blackdown).

К чему это?
К тому что без лишних и мёртвых фреймвоковских циклов - перформанс может отличаться на _порядки_.
5-60-1000
это даже внутри одной жавы.
О примере больших проектов (биржа) написанных чисто на ассемблере - ... умолчим ;)


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

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

надо оговориться конечно.
Несколько порядков - это конечно прежде всего - ненужный IO, туда-сюда, ненужный парсинг и прочее. Да и вообще кластера не надо скорее всего - если всё вначале подсчитать на пилоте. И базу скорее всего нужно не реляционную. Но в корпоративном мире все обычно идут колонной, одинаково - в ж.

всё, кончаю флудить - наболело.

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

char str[] = "\n\neee rrr\nttt\t\nwww\n";
char* tok;
long n = strlen(str);
long i;
char c;

tok=str;
for(i=0; i<n; i++){
c=*(str + i);
switch (c){
case ' ': case '\t': case '\n':
*(str + i)='\0';
printf ("%s\n",tok);
tok=str+i+1;
}
}

чисто-по-приколу запустил оба Ц варианта 10^6 раз с закомментированными printf и memcpy (одно и то-же для обоих случаев). Разница - 6.7-7.7% (~7%) - только в проверке одного символа и вызове стрток.
То-есть если мы там флаги оптимизации крутим - 7% - это круто. А здесь - ещё 4 строки добавить (5 минут) - и то-же самое - лехко.

Гениально. За это я и уважаю C. С - это ИМХО кроссплатформенный ассемблер. Только я в посте про C#. Делал ударение не на разделение строк на подстроки, а на то что массив из объектов string создается и инициализируется одной строкой.

string[] strs = str.Split(' ', '\t', '\n');

Просто вывод строк в C можно сделать еще короче

char *str = "eee rrr\nttt\twww"; for(int i = 0; i < strlen(str); i++) if(str[i] != ' ' && str[i] != '\t') putch(str[i]); else putch('\n');

Насчет самого Паскаля скажу, что он не стал основным языком программирования в основном потому, что Вирт не называл свои нове языки Psacal 1, Pascal 2, Pascal 3 и т.д, а придумывал какие-то Футуристические названия: Modula, Oberon и т.п. У него сейчас еще один новый язык появился с таким забористым названием, что я и не запомнил.

> А кодится на нем действительно быстро. Перефразируйте следующий код на C\C++,Pascal также компактно. Особенно на великий и могучий C, или супер-мега стабильный Паскаль. string str = "eee rrr\nttt\twww"; string[] strs = str.Split(' ', '\t', '\n'); foreach (string s in strs) Console.WriteLine(s);

ну что-то типа такого char str[] = "eee rrr\nttt\twww"; for (char* pch = strtok (str," \t\n"); pch != NULL; pch = strtok (NULL, " \t\n")) printf ("%s\n",pch); и что самое интересное кодится и выполняется быстро :-)

Ну что, засчитываем слив дотнетчиков? :)

>Ну что, засчитываем слив дотнетчиков? :)

Только в пользу Java :D

>> Ну что, засчитываем слив дотнетчиков? :)

> Только в пользу Java :D

Мне и к Java придраться за дорогой форк? ;)

>Мне и к Java придраться за дорогой форк? ;)

А мне поф. :D

FPC is a fast compiler: FPC compiles code roughly 7 times faster than for instance GCC. This may seem to be of little importance, but it cuts down development time. The speed of the generated code is comparable to the GCC compiler: according to the Shootout benchmarks, the FPC 2.0.4 code is 30% slower code than GCC. In contrast, FPC code uses less memory than GCC generated code. Compared to interpreted languages, one sees that FPC code executes 50 times faster than e.g. Ruby. The difference with PHP and Java is smaller, but these use 14 (PHP) to 17 (Java) times more memory than FPC programs.

One can wonder whether the speed of benchmarks says anything about real (graphical) applications. Comparing the response of the popular Java IDE Eclipse with the response of Lazarus will quickly convince one of the difference. Native code remains faster than interpreted and JIT languages, even when pre-compiled. Native code uses less memory, and is easier to install, since no extras need to be installed on the computer of the end-user.

http://osnews.com/story.php/18592/Cross-Platform-Development-with-Free-Pascal...