Лично для меня шоустопером является отсутствие доступа к berkley сокетам 1:1 как в C в стандартной библиотеке. socket/bind/accept/connect/read/write/select/poll. 9 лет назад смотрел, пару недель назад, а с этим всё не то. Можно и не 1:1, а даже удобней, но тогда хотя бы без ограничения имевшейся гибкости. Т.е. начальных требований у меня минимум.

Лично для меня шоустопером является отсутствие доступа к berkley сокетам 1:1 как в C

1:1 как в C

«Шта?» (с) Еще один ниасилел интерфейсный модуль с STDCALL/CDECL к WinAPI ? Winsock или sockets не смог подключить в uses?

1:1

Это можно и самому, если очень надо гибкость и префиксы в именах функций Sockets не нравятся :)

Winsock или sockets не смог подключить в uses?

Ну в Си тоже не обходится без ifdef, но минимально. Т.е. для винды нужно WSAStartup/WSACleanup, но в остальном всё практически то же. А можно поподробнее, как в FP?

в именах функций Sockets не нравятся

А откуда юзать select/poll? А с сокетом заведётся?

А откуда юзать select/poll? А с сокетом заведётся?

Как-то так http://lazarus-ccr.sourceforge.net/docs/rtl/linux/index-5.html Опять таки, захочется большей гипкасти — никто тебя не удержит от обертывания в модули любых .so-шек/.dll-ок и поцматривания, как они в лазарусе это сделали.

Вот скажи, почему я должен использовать для нативного софта С++, а не тот же Delphi?

Самое главное: компиляторы С++ генерируют намого более эффективный код, чем компиляторы дельфи/фрипаскаль/прочие подобные поделия. собственно, это ниша С/С++ — любые приложения, где скорость имеет первостепенное значение, а именно: hiload, системные утилиты, браузеры, игры и любые несерверные приложения потолще калькулятора. У дельфи в этой нише просто нет никаких шансов.

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

Может, хотя бы, мелкий гуй под винду на нём клеапть? Да нет, тут есть C# и таже Java, у которых гораздо более развитая экосистема.

Во-вторых, Delphi, попросту, не всюду заведётся: жирный минус, по сравнению с любыми др. мейнстрим-ЯП.

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

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

Самое главное: компиляторы С++ генерируют намого более эффективный код, чем компиляторы дельфи/фрипаскаль/прочие подобные поделия.

Пруфы в студию. Пока вижу только фонатека с тарелкой борща, лежащего на диване.

собственно, это ниша С/С++ — любые приложения, где скорость имеет первостепенное значение, а именно: hiload, системные утилиты, браузеры, игры и любые несерверные приложения потолще калькулятора.

Где я говорил о hiload? Это раз. Два - давай все же делить Pure C (который я очень люблю и уважаю) от б-г мерзкого С++, который почему-то кто-то считает языком, причем программирования и причем нормальным. С Pure C не спорю, хотя я не вижу координальных отличий сегодня между FPC и тем же GCC как инструмента для разработки нативного софта или встраиваемые системы - это отдельная тема для разговора. Вот решил я написать новый «либрофис» - что мне даст С++, чего не может дать Lazarus? Qt не приводи в пример - он и в Lazarus есть. Вырвиглазный синтаксис? Тогда я лучше к Tcl схожу, там хотя бы программы читабельны. ООП? В С++ его нет и не может быть. Кто не согласен - берем принципы ООП А.Кея и сравниваем с С++. Только когда найдете аргументы, почему С++ подходит на 100% под каждый - возвращайтесь. Метапрограммирование? Вот когда впилят в С++ полноценные макросы, а темплейты закопают - тогда приходите. По своей сути С++ - уникальный язык. Он эмулирует большое количествоо парадигм, фишек, подходов, сахара. Но в нем их нет, только чистая эмуляция, убогое подражание...

У дельфи в этой нише просто нет никаких шансов.

Пруфы, сравнения, тесты в студию.

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

Ты наркоман? У Delphi, Java, Ruby и C# - разные экосистемы, разные области применения. Если язык общего назначения - это не значит, что на нем хе**чат всё подряд. Go и Python языки общего назначения, только драйверов на них я не видел. И если C# и Delphi еще конкуренты, то с Java и Ruby он слабо пересекается.

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

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

Наркоман? FPC используется Lazarus, а Lazarus - это Qt. И на сколько помню у Delphi сейчас есть возможность компилить приложения под любые ОС, вплоть до Android и гейских ОС. Так под FPC на сколько знаю есть и полноценные биндинги под Qt, Tk, wx, etc. Да и что вы так к Qt приклеились? Это далеко не самый идеальный фреймворк. Ах, да. Вы же покалечены С++. Ну да, тогда для вас только Qt существует.

Может, хотя бы, мелкий гуй под винду на нём клеапть? Да нет, тут есть C# и таже Java, у которых гораздо более развитая экосистема.

Да ладно. А то что Delphi работает с тем же .Net - это как бы вам не известно? Да и где хоть под Windows у Java лучше экосистема? Я виндузятник в домашних условиях и за 15 лет не использовал ни одной декстопной программы на Java, окромя RubyMine и PyCharm.

Во-вторых, Delphi, попросту, не всюду заведётся: жирный минус, по сравнению с любыми др. мейнстрим-ЯП.

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

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

Так ты так и не назвал ни одной причины использовать C++. Все твои аргументы за C++ равны моим аргументам за Delphi.

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

Ооооо, хипстор детектед. А теперь реши мне задачу высоконагруженного сервера в хотя бы 10 000 коннектов одновременных на популярных языках типа С++, Python, Ruby. Удачи. Отпишись о результатах когда поймешь, что тут мало альтернатив. Ну или напиши драйвер видеокарты на чистом (т.е. без применения либ Pure C или либ других языков) на популярной жабке. Ну и в довершении, наклепай мне на своём либимом С++ и Qt реально кроссплатформенное приложение. Только без необходимости ставить кучи либ. Тупо распаковал архив и все, работает на 100%. Целевые ОС - Linux, Windows, Android, iOS, MacOS, Plan9, Inferno, FreeDOS, FreeBSD, AmigaOS ну и давай для того, чтобы задача была тебе интереснее (ведь C++ и Qt такие идеальные) - пусть в последнем гвоздем в крышку твоего ущербного представление о C++ будет KolibriOS. Жду программу (бинари+скриншоты).

Пруфы в студию.

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=fpascal&lan...

например. freepascal — лучший компилятор с дельфообразного шлака под линукс на сегодняшний день.

Только когда найдете аргументы, почему С++ подходит на 100% под каждый - возвращайтесь.

зачем? области применения С++ я чётко обозначил. под 100% областей он не подходит.

Вот решил я написать новый «либрофис» - что мне даст С++, чего не может дать Lazarus?

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

У Delphi, Java, Ruby и C# - разные экосистемы, разные области применения.

А я про то и толкую? У них это сервера и гуй. А у дельфи нет областей применения.

Если язык общего назначения - это не значит, что на нем хе**чат всё подряд.

И я про тоже.

А то что Delphi работает с тем же .Net - это как бы вам не известно?

прекрасно известно. только вот .NET и C#. слегка ортогональны

то с Java и Ruby он слабо пересекается.

разумеется. как с любым др. языком.

FPC используется Lazarus, а Lazarus - это Qt. И

НЯЗ в этом вашем лазарусе максимум некрофильская 4-я версия куте. поправьте с пруфами если не так.

Мне очень важно, конечно же, чтобы моя программа завелась на Plan9

не вашей фирмы, а именно вашей, лол? вы ПО в одиночку, что-ли, клепаете?

А теперь реши мне задачу высоконагруженного сервера в хотя бы 10 000 коннектов

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

Ооооо, хипстор детектед. А теперь реши мне задачу высоконагруженного сервера в хотя бы 10 000 коннектов одновременных на популярных языках

С каких пор хипстеры пишут на популярных языках?

например. freepascal — лучший компилятор с дельфообразного шлака под линукс на сегодняшний день.

А реальные задачи если брать? Бощета меня мало интересует.

зачем? области применения С++ я чётко обозначил. под 100% областей он не подходит.

Окей. Тогда скажи, где твой любимый C++ в высоконагруженных сервисах забарывает Erlang.

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

Окей, собралась программа не за 2 часа, а за полтора. Предположим мне это кретически важно. Исполнения - в чем будет профит? Если писать оптимизации, то тут можно так же как и на цпп использовать ассемблер. И в чем профит? Что там ASM будет, что тут.

А я про то и толкую? У них это сервера и гуй. А у дельфи нет областей применения.

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

прекрасно известно. только вот .NET и C#. слегка ортогональны

Окей. Скажи чего нет в Delphi, но есть C#, что даёт прирост производительности.

НЯЗ в этом вашем лазарусе максимум некрофильская 4-я версия куте. поправьте с пруфами если не так.

Пруфы лень, но в новостях на оф.сайте было пользование Qt5. Оно есть даже на Gambas, в Lazarus тем более

не вашей фирмы, а именно вашей, лол? вы ПО в одиночку, что-ли, клепаете?

Ну я как бы говорю от лица фирмы.

А теперь реши мне задачу высоконагруженного сервера в хотя бы 10 000 коннектов

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

Удачи. Хоть бы сказал, что за сервис с более чем 10 000 одновременных коннектов. Пока Erlang еще никто обогнать не мог.

С каких пор хипстеры пишут на популярных языках?

А на чем еще? Хипстота не знает парадигм, не знает теории. Им не осилить нормальные языки, такие как Erlang, OCaml, Haskell, Tcl, Racket, Smalltalk. Ведь для них ООП язык - там где есть классы. А про принципы ООП создателя парадигмы они не слышали, голубую книгу не читали. А Simula считают родоночальником парадигмы.

А реальные задачи если брать?

Беру движок hedgewars, транслирую из паскаля в си, компилю, работает на 20% быстрее.

Бощета меня мало интересует.

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

Erlang, OCaml, Haskell, Tcl, Racket, Smalltalk

а дельфи тут при том, что?

Исполнения - в чем будет профит? Если писать оптимизации, то тут можно так же как и на цпп использовать ассемблер.

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

GUI - есть.

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

Скажи чего нет в Delphi, но есть C#, что даёт прирост производительности.

прирост производительности чего? прирост производительности труда программиста на С#, например, даёт более развитое сообщество, поддержка со стороны крупной корпорации, наличие удобного инструментария (ambracadero delphi заметно хуже vs), большие объёмы актуального кода и куча доступных нативных библиотек.

ах да, бОльшее число программистов, знающих С#, гарантирует, что работодатель легко сможет найти вам замену.

Пруфы лень, но в новостях на оф.сайте было пользование Qt5.

ага. предальфы. с тех пор — ни слуху, ни духу

Ну я как бы говорю от лица фирмы.

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

Дожили. Дельфист называет C++ борщом :/

Беру движок hedgewars, транслирую из паскаля в си, компилю, работает на 20% быстрее.

Pure C - как говорил, согласен. Он более системны. Всё же спор о С++, который не есть Pure C. Далее - не понятно на сколько хоршоо движок hedgewars хорошо написан, насколько оптимизирован и т.п. Поэтому и спрашиваю реальные задачи, а не теорию из разряда «мой факториал стал на 20% быстрее, потому что я на C++ прочитал туториал, а на Delphi - мне лень и я пишу как м***ак».

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

Конкретно - нет аргументов исходящих из суровой практики. Только популистические примеры, красивые слоганы.

а дельфи тут при том, что?

При том, что Delphi как и приведенные языки являются практическими инструментами, а не красивой идеей, скатившейся в ср***ое г**но, как С++.

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

Тогда вопрос по существу - чем работа с памяться в С++ лучше работы с памяться в Delphi? В последнем она есть, есть указатели, есть управляемая и не управляемая память и т.п. В чем отличия?

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

Хах, лучшая защита - это нападение, да? Я не говорил, что она пригодна только для этого. Это же язык общего назначения, как и твой любимый С++. Тебе сказать честно? Ну по крайней мере в Delphi язык не является помойкой, для меня это уже достаточный аргумент. Нет жирного рантайма как у Java. Есть прекрасный генератор форм. А вот по функциональным возможностям современный Delphi = C#, т.к. они оба .Net.

прирост производительности чего?

Ну ты же с пеной у рта кричишь о производительности С++. Вот какую ты имеешь ввиду.

прирост производительности труда программиста на С#, например, даёт более развитое сообщество, поддержка со стороны крупной корпорации, наличие удобного инструментария (ambracadero delphi заметно хуже vs), большие объёмы актуального кода и куча доступных нативных библиотек.

Наркоман детектед. Скольк раз мне в этой ветке говорить, что Delphi уже давно .Net юзает и его развитие так же одобряет та самая крупная корпорация?! И кто тебе мешает эти библиотеки .Net дергать в проектах Delphi?! Религия? Так тогда не используй либы написанные на Pure C на твоём любимом С++. Ах да, ты же считаешь это одним языком. Печаль-беда.

ах да, бОльшее число программистов, знающих С#, гарантирует, что работодатель легко сможет найти вам замену.

Вообще, если вы программист - вам без разницы на чем писать. Мыслите уже не языыками, а задачами и алгоритмами. Видимо у вас не так - поговорим когда просветленее придет.

ага. предальфы. с тех пор — ни слуху, ни духу

Странно, я пол года назад юзал, что-то делал мелкое на Lazarus и всё работало.

от лица фирмы даже гендир не может с уверенностью говорить,

Гендир. Не может. Вы наркоман, батенька? А так- гендир читает этот тред. С вас так же ржет как и я.

что захотят в будущем акционеры фирмы.

На**р акционеров, только ООО в рамках РФ.

может, действительно, потребуется софт под plan9.

Тогда я возьму явно не С++, а буду писать именно под Plan9, используя подходящие для него инструменты. А не заниматься ан**ом на QT.

Дожили. Дельфист называет C++ борщом :/

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

Ооооо, хипстор детектед. А теперь реши мне задачу высоконагруженного сервера в хотя бы 10 000 коннектов одновременных на популярных языках типа С++, Python, Ruby. Удачи.

Прекрасный тред. Новая комедия от создателей фразы «Кому нужны «кресты», окромя пары сотен фонатеков и полутора Ъ-линуксоидов?» В ролях дельфисты. Спешите читать!

Вообще, если вы программист - вам без разницы на чем писать.

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

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

После того, как в плюсы завезли блямбы, а Страус начал упарываться по Какашкелю, иначе как борщом плюсы уже и не назовешь. Спекся бобик. FreePascal теперь наше все.

не понятно на сколько хоршоо движок hedgewars хорошо написан, насколько оптимизирован и т.п

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

Вот решил я написать новый «либрофис» - что мне даст С++, чего не может дать Lazarus?

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

ясно

При том, что Delphi как и приведенные языки являются практическими инструментами, а не красивой идеей, скатившейся в ср***ое г**но, как С++.

тогда только один вопрос: в вашей волшебной параллельной вселенной эликсир бессмертия изобрели?

После того, как в плюсы завезли блямбы, а Страус начал упарываться по Какашкелю, иначе как борщом плюсы уже и не назовешь

Продолжайте наблюдение, мы с вами свяжемся :D

Вот как раз c Qt у Лазаря не всё в порядке: нужна дополнительная разделяемая библиотека (соответственно, с portable приложениями выходит швах). Но чем GTK-вариант-то не устраивает? Все равно же реально почти на каждой системе с графикой этот тулкит установлен.

А почему про «GNU Pascal» никто не пишет. Может слышали, в Линуксе есть коллекция компиляторов, называется она «GNU Compiller».

А почему «praseodim» не написал главного: Free Pascal — это компилятор для конкретного диалекта, который называется Object Pascal. И поэтому у него наблюдается такая совместимость с языком Дельфи.

На паскале пишешь? Фу таким быть...

Если такое услышишь от сишника или жабиста, скажи ему: «Не дрочи судьбу!».

gpc мёртв (последняя активность в проекте аж 10 лет назад), да и вообще является не более чем костылём, по сути только преобразующим синтаксис паскаля в си. Freepascal поддерживает несколько диалектов.

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

У меня пользователь = бизнес. А им главное скорость выдачи готового продукта. Приходится писать на Python'ах.

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

А в чем стеб? Таки asm прекрасный язык и он мне всегда нравился. Но для web'a в использовании он дает результат быстрый, но оооочень долго. А так рад бы

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

Перечитайте мой комментарий. Лень опять переписывать один и тот де комментарий

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

Ага. Расскажите об этом бизнес-сектору

тогда только один вопрос: в вашей волшебной параллельной вселенной эликсир бессмертия изобрели?

Аргументы кончились?

вы уж, определитесь: «без разницы на чём писать» или «но оооочень долго»

Ребята а как насчёт Компонентного Паскаля на нём в Линуксу кто-нибудь программировал? Как никак это прямой потомок Виртовского Паскаля.

Компиляторов нихрена нет. Только GPCP под жабу с дотнетом, и BlackBox, который ещё чёрт знает как собрать под эти наши линуксы и имеется только поддержка 32-х битов.

Насчёт <BlackBox Component Builder+Component Pascal> у меня такие впечатления. Component Pascal — это промышленный язык, Компания Oberon Microsystems создала его для своих корпоративных нужд, не для «людей». Потом она «BlackBox Component Builder» почему-то отдала «в подарок» сообществу типа допиливайте. Сборка под Винду есть, под Линукс есть какая-то «BlackBox Freenix» собранная под Убунту.

Сам эту среду я не пробовал, излагаю слухи. <BlackBox Component Builder+Component Pascal> принцип работы не понял, но это что-то типа жабы. Сам язык компилируемый. Но почему, код Компонентного Паскаля работает в изолированной среде? Так и непонял. Может это опять гениальная разработка учеников Никлауса Вирта, незнаю-незнаю?

то за размером буфера не уследили, то за модификаторами в printf, а сколько багов наплодили 0-terminated строки - это вообще.

В С++ это все не надо. Автор вроде о ООП паскале говорил, так и сравниваем его с С++, а не с pure C. А там где реально применим pure C паскалю уже никогда ничего не светит. Слишком узкая область и уже давно занятая.

Какая ещё изолированная среда? Можно спокойно загружать любые библиотеки и дёргать любые функции, да и без них можно использовать не безопасные расширения языка. Просто тогда возможность выстрелить в ногу подымается до уровня сишки.

Значит, не изобрели. Печально.

Может ли скомпилированная программа запуститься и корректно работать на другом компе. Я читал, что для запуска проги написанной на Компонетном Паскале требуется «BlackBox Component Builder».

Если я ошибаюсь, то это просто замечательно!

Не обязательно, нужные модули можно просто статически прилинковать. В документации вроде бы даже есть инструкция.

Итак, если всё вместе - начнём с недостатков С

1. Главный недостаток - неуместное использование макросов (#define). Макрос - очень мощный инструмент, фактически превращающий один ЯП в немного (или даже много) другой. Использовать этот инструмент для определения констант или того, что можно было бы реализовать небольшой функцией - это как забивать гвозди микроскопом. Не только неудобно, но и опасно - ошибка может всплыть совсем не там, где она сделана.

2. Использование #include для связывания кусков кода - вчерашний день. Да, в паскале были и есть {$include a.inc}, и никто не запрещает их использовать тем же способом, что и в С. Но так не делают уже со времён 4-го турбопаскаля. Хотя, для определённых целей, их используют. В сочетании с первым, кстати, #include в С может натворить таких дел, что мало не покажется (ведь каждое макроопределение меняет язык). Опять же, последовательность #include оказывается ключевой. А кто будет следить за тем, чтобы при компоновке все библиотеки, которые оказались задействованы в дереве #include, оказались подключенными? Нет, конечно, есть Makefile (а за ним - autoconf, automake), но...(см.3). Отсюда даже в более поздних С-подобных языках переходят к модулям.

3. Более или менее серьёзная программа на С требует либо скрипт для сборки, либо Makefile. На Паскале это оказывается актуальным только в вопросе «где искать модули» (ну и тип сборки - релиз, отладочная информация - тоже, хотя многое можно указать прямо в коде). Во всём остальном - компилятор легко вытащит всё, что надо, за главный файл. Так что для того, чтобы писать на С, надо знать, как минимум, два языка (собственно С и язык скриптов/make).

4. Концепция С «Можно делать что угодно где угодно» не раз приводила к долгосрочным багам вида if (i=0) {...}. Понятно, что в паскале подобное невозможно в принципе (ну, если не писать специальных функций).

5. Указатели. С живёт указателями. Нужно всё время держать в голове, что с ними происходит в каждый момент времени, и не показывает ли этот указатель куда-то не туда. В паскале указатели тоже есть, но базовые типы работают и без них, а в более сложных случаях они скрыты (хотя тут опасность попасть не туда уже ненулевая).

6. Неоднозначность языка. 13 или 14? В паскале, опять же, для подобного нужны специально написанные функции.

7. Длительность компиляции. Да, на -O1, к уровню которой близок паскаль, скорость резко возрастает, но до паскалевской (не говоря уж о ранних Delphi) не дотягивает. Даже если не учитывать configure.

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

9. Кстати, а как там, в плюсах, с аналогом property? Нет, я знаю, в борландовском поделии они есть, а как в классике? Или gcc?

Теперь об обратных недостатках.

1. Паскаль - довольно жёсткий язык, поэтому желание сделать всё в одну строку может быть неосуществимо (ну или строка получится очень длинная).

2.Несколько меньшая популярность, особенно в среде linux.

3. Да, сильно разнесены блоки описания и реализации, правда, при наличии вменяемой IDE это не проблема (она легко определит переменную сама по простой комбинации клавиш).

4. Слабоватая система макроопределений.

Такие недостатки/достоинства, как вид операторных скобок, я не рассматриваю - это дело вкуса.

Теперь о недостатках реализации - FreePascal+Lazarus

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

2. Очень большие стандартные модули - там есть всё, что только может пригодиться - что в сочетании с отсутствием библиотек приводит к огромным бинарникам (особенно Lazarus).

3. Оставляет желать лучшего оптимизация (особенно - отсутствует удаление ненужных методов из классов).

4. Сам подход работы в Lazarus, в общем, противоречит системам пакетов большинства дистрибутивов Linux. Lazarus требует исходников как собственных, так и FreePascal (можно, правда, их урезать). Теоретически проблему можно решить декомпиляцией файлов ppu, но этим никто не занимается. Здесь же следует отметить частое желание Lazarus пересобрать себя, а уж пересобрать библиотеку компонентов - это святое дело чуть ли не для каждого нового проекта (особенно в последних версиях). При всём при том, как IDE Lazarus может очень многое - тут и автодополнение кода, и его форматирование, и поиск идентификатора (с возможностью перейти к реализации) вплоть до модуля System...

Короче, если нужен один серьёзный проект одним бинарным файлом по принципу «всё своё ношу с собой», то Freepascal очень неплох (вплоть до того, что в большинстве случаев можно будет обойтись безо всего - даже без libc и libm). С Lazarus чуть похуже: да, в бинарнике будет почти всё, но в Linux он будет ориентирован на gtk2 или на qt, и если в системе что-то совсем не то, то возникнут проблемы. Вот если надо с десяток мелких утилит, то объём, ими занимаемый, окажется большим. Впрочем, задача решаема, правда, нештатными средствами. Ну и, конечно, если надо собрать всё на месте, то без компилятора FreePascal (и Lazarus, пусть в урезанном виде, для приложений Lazarus) не обойтись.

В С++ это все не надо. Автор вроде о ООП паскале говорил, так и сравниваем его с С++, а не с pure C. А там где реально применим pure C паскалю уже никогда ничего не светит. Слишком узкая область и уже давно занятая.

Простите, а при чем тут ООП и С++? ИМХО, этот язык далеко не ООП. Очень далеко не ООП.

Итак, если всё вместе - начнём с недостатков С

Очень интересно. Давай.

1. Главный недостаток - неуместное использование макросов (#define).

Это не полноценный макрос. Лучше, чем ничего. Но всё же.

Макрос - очень мощный инструмент, фактически превращающий один ЯП в немного (или даже много) другой.

А при чём тут Pure C? Ну разве что на нем налабать VM или транслятор/интрепретатор. А так - макросы неполноценны. Аргумент - в топку.

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

Он там только для этого и пригоден.

Не только неудобно, но и опасно - ошибка может всплыть совсем не там, где она сделана.

Он для этого и создавался, на сколько я помню K&R.

2. Использование #include для связывания кусков кода - вчерашний день.

Пойду пацанам расскажу, удивятся.

Да, в паскале были и есть {$include a.inc}, и никто не запрещает их использовать тем же способом, что и в С. Но так не делают уже со времён 4-го турбопаскаля.

Почему не делают? В чем не нравится инклюды?

Хотя, для определённых целей, их используют. В сочетании с первым, кстати, #include в С может натворить таких дел, что мало не покажется (ведь каждое макроопределение меняет язык).

Это не include делает. Просто «я у мамы рукожоп» называется.

Опять же, последовательность #include оказывается ключевой.

Для чего?

А кто будет следить за тем, чтобы при компоновке все библиотеки, которые оказались задействованы в дереве #include, оказались подключенными?

WTF?! Чувак, это не критичный недостаток. Да и вообще не недостаток.

Нет, конечно, есть Makefile (а за ним - autoconf, automake), но...(см.3). Отсюда даже в более поздних С-подобных языках переходят к модулям.

Так. У тебя бардак в голове. Что есть для тебя модуль, и как ты хочешь его по иному реализовать в Pure C? Его и так можно назвать «модульным», просто понимание модуля у него не равняется пониманию пакетов в том же Java, но это не недостаток.

3. Более или менее серьёзная программа на С требует либо скрипт для сборки, либо Makefile.

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

На Паскале это оказывается актуальным только в вопросе «где искать модули» (ну и тип сборки - релиз, отладочная информация - тоже, хотя многое можно указать прямо в коде).

Чуваааак... Ну ключи же комилятора. Кликнуть на кнопку и макака может. А ведь надо понимать что происходит после клика в Delphi или VS на кнопку компилирования. Из-за незнания ключей проект на Delphi и весили чуть более чем до**я.

Во всём остальном - компилятор легко вытащит всё, что надо, за главный файл. Так что для того, чтобы писать на С, надо знать, как минимум, два языка (собственно С и язык скриптов/make).

Нафейхуа? Я вот когда начинал писать на Pure C знал только С и VB6. Ничего - собирал проекты. Без особых проблем, кстати. Да - make это повышение удобства. Но, среду Delphi тоже надо знать и понимать.

4. Концепция С «Можно делать что угодно где угодно» не раз приводила к долгосрочным багам вида if (i=0) {...}. Понятно, что в паскале подобное невозможно в принципе (ну, если не писать специальных функций).

Показать как? На любом языке можно плодить говнокод и трудночитаемый код. Вот птичий язык - да, понижает читабельность Pure C, но никак не приведенный аргумент. Наоборот - это преимущество, т.к. позволяет писать код так как удобнее человеку, а не парсеру.

5. Указатели. С живёт указателями. Нужно всё время держать в голове, что с ними происходит в каждый момент времени, и не показывает ли этот указатель куда-то не туда.

А в чем отличие от паскаля? Да и работа с памятью в принципе это подразумевает. Не хочешь мучений с памятью? Бери ВМ и не мучай ни себя, ни людей.

В паскале указатели тоже есть, но базовые типы работают и без них, а в более сложных случаях они скрыты (хотя тут опасность попасть не туда уже ненулевая).

Да и в Pure C возможно писать практически не используя указатели. В чем разница?

6. Неоднозначность языка. 13 или 14? В паскале, опять же, для подобного нужны специально написанные функции.

А вот тут не понял. Поясните.

7. Длительность компиляции. Да, на -O1, к уровню которой близок паскаль, скорость резко возрастает, но до паскалевской (не говоря уж о ранних Delphi) не дотягивает. Даже если не учитывать configure.

Еще один занимается измерением количества вздохов сборки проект. НЕ АРГУМЕНТ это.

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

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

9. Кстати, а как там, в плюсах, с аналогом property? Нет, я знаю, в борландовском поделии они есть, а как в классике? Или gcc?

С++ есть костыли. Правда я не смогу скорректировать. Но при чем тут С++ и Pure C? Первый - набор промышленных костылей, который почему то приняли за язык. Второй - красивый и лаконичный промышленный язык.

Теперь об обратных недостатках.

О! Интересно=) Больше еды, больше!

1. Паскаль - довольно жёсткий язык, поэтому желание сделать всё в одну строку может быть неосуществимо (ну или строка получится очень длинная).

У нормальных людей его нет. В чём недостаток? Наркоманов не привлекает? Ну и хорошо. Меньше гавнокода.

2.Несколько меньшая популярность, особенно в среде linux.

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

3. Да, сильно разнесены блоки описания и реализации, правда, при наличии вменяемой IDE это не проблема (она легко определит переменную сама по простой комбинации клавиш). А про разнесение кода - тоже не проблема, если руки отку надо.

WTF?! Опять мешаете понятие экосистема и язык. Для примера - Io прекрасный язык, но под него нет даже нормальной IDE окромя EMACS. Но это не недостаток языка, а недостаток экосистемы, т.к. в ней не смогли показать применение и убедить, что нужны инструменты разработки.

4. Слабоватая система макроопределений.

Не вижу отличий от Pure C. Конечто темлейтов я не припомню. Но всё же - и то, и то лишь кастрированные по самое небалуй макросы.

Такие недостатки/достоинства, как вид операторных скобок, я не рассматриваю - это дело вкуса.

Ну слава лиспу, хотя бы это не стали «анализировать».

Теперь о недостатках реализации - FreePascal+Lazarus

Ням, я скоро лопну. Слишком много еды.

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

Тогда в чем проблема? Да и это OpenSource, детка. Не коммерческий продукт. Не нравится - сделай сам. Не аргумент.

2. Очень большие стандартные модули - там есть всё, что только может пригодиться - что в сочетании с отсутствием библиотек приводит к огромным бинарникам (особенно Lazarus).

Вот про что я и говорю. Ключи не знаете. А ведь можно вырезать почти все, что не нужно.

3. Оставляет желать лучшего оптимизация (особенно - отсутствует удаление ненужных методов из классов).

Простите, подробнее. А то моя фантазия уже разыгралась.

4. Сам подход работы в Lazarus, в общем, противоречит системам пакетов большинства дистрибутивов Linux.

У людей свой подход. Что плохого?

Lazarus требует исходников как собственных, так и FreePascal (можно, правда, их урезать).

Требует для чего? Для компиляции? Тогда это нормально. Ибо Lazarus это не компилятор, а всего лишь IDE. Почитайте данный термин.

Теоретически проблему можно решить декомпиляцией файлов ppu, но этим никто не занимается.

Но можно же? Тогда не аргумент.

Здесь же следует отметить частое желание Lazarus пересобрать себя, а уж пересобрать библиотеку компонентов - это святое дело чуть ли не для каждого нового проекта (особенно в последних версиях).

В чем именно недостаток?

При всём при том, как IDE Lazarus может очень многое - тут и автодополнение кода, и его форматирование, и поиск идентификатора (с возможностью перейти к реализации) вплоть до модуля System...

И это недостаток и критика? По моему это даже очень хорошо.

Короче, если нужен один серьёзный проект одним бинарным файлом по принципу «всё своё ношу с собой», то Freepascal очень неплох (вплоть до того, что в большинстве случаев можно будет обойтись безо всего - даже без libc и libm).

И это скорее «+», нежели "-".

С Lazarus чуть похуже: да, в бинарнике будет почти всё, но в Linux он будет ориентирован на gtk2 или на qt, и если в системе что-то совсем не то, то возникнут проблемы.

Ну да, Tk не поддерживается. А он есть везде. Я всегда считал Qt и Gtk2 ущербными и жирными монстрами.

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

Опять же - решаемо. А тай - OpenSource, запили штатное средство, раз тебя так напрягает. Люди спасибо скажут.

Ну и, конечно, если надо собрать всё на месте, то без компилятора FreePascal (и Lazarus, пусть в урезанном виде, для приложений Lazarus) не обойтись.

Нифига себе. А я то надеялся и думал, почему мои lisp-проекты не собираются. Вообще - странно, правда, проекты не собираются без компилятора?! Куда годно?!

Это не полноценный макрос. Лучше, чем ничего. Но всё же.

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

Почему не делают? В чем не нравится инклюды?

Потому что есть модули. Это сразу и описание файла (некий аналог include) и код. Причём модуль более или менее целостный. Зачем нужны паровозы, когда есть тепло- и электровозы? Хотя да, иногда необходимость есть. Но, как правило, отнюдь не для связывания других кусков.

Это не include делает. Просто «я у мамы рукожоп» называется.

Что практически невозможно в паскале. Хотя да, если специально постараться, может что-то и получиться.

Он там только для этого и пригоден.

Не только. Можно, например, { и } на begin и end заменить. Но это так, для интереса.

А вот тут не понял. Поясните.

http://lurkmo.re/I++

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

А нужна ли эта масса ключей? В Паскале почти все ключи дублируются директивами компилятора. Если, всё-таки, эти ключи нужны - то хватит одной строчки скрипта, начинающейся с FPC. Сколько строчен надо для сборки реальной программы на C?

Из-за незнания ключей проект на Delphi и весили чуть более чем до**я.

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

Я вот когда начинал писать на Pure C знал только С и VB6. Ничего - собирал проекты.

Допустим, есть проект в одном каталоге с десятком файлов кода (не включая заголовки). В С - функция main находится в одном из них (main.c). В паскале - аналогичный (main.pas) начинается с program, остальные - с unit. В паскале достаточно

fpc {всякие разные опции, если надо} main.pas

В gcc

gcc {общие опции} -c u1.c

gcc {общие опции} -c u2.c

............................ gcc {общие опции} {опции сборки} main.c -o {имя бинарника}

Нифига себе. А я то надеялся и думал, почему мои lisp-проекты не собираются. Вообще - странно, правда, проекты не собираются без компилятора?! Куда годно?!

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

Вот про что я и говорю. Ключи не знаете. А ведь можно вырезать почти все, что не нужно.

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

Простите, а при чем тут ООП и С++? ИМХО, этот язык далеко не ООП. Очень далеко не ООП.

В С++ почти все указанные проблемы просто неактуальны. Есть умные указатели, множество контейнеров, исключения, свои потоки ввода вывода (хотя вот они то и говнецо, printf лучше). Я работая на С++ работаю с указателями КРАЙНЕ редко. Оно здесь не надо.

В заголовочном сообщение автор явно сравнивает с C/C++, прямым текстом. Значит надо писать на С++, а не на Си. И приводить аргументы про указатели и \0 завершающиеся строки просто глупо.

Почему не делают? В чем не нравится инклюды?

Ты стебешься? Серьезно не понимаешь чем плохи инклуды? Наверное зря пацаны рассматривают возможность добавления модулей в С++17, зряя... (это был сарказм)

Да и в Pure C возможно писать практически не используя указатели. В чем разница?

Если это не жесткий эмбедед, то практически нельзя. А контейнеров в pure c нет.