После года разработки опубликован релиз свободного набора компиляторов GCC 15.1, первый значительный выпуск в новой ветке GCC 15.x. В соответствии со схемой нумерации выпусков, версия 15.0 использовалась в процессе разработки, а незадолго до выхода GCC 15.1 уже ответвилась ветка GCC 16.0, на базе которой будет сформирован следующий значительный релиз GCC 16.1...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63141
А по выходам за границы там как? Может для этого какой-то стандарт?
Конечно есть стандарт называеться .at(index) в любой std
>" А по выходам за границы там как? Может для этого какой-то стандарт? "Называется си с плюсами)))
Слушайте, а что с GNU Pascal случилось? Почему компилятор никак не развивается? Почему всякое непотребство типа Modula-2 (вообще кто-то слышал что то об этом языке?) или Objective-C поддерживаются, а Паскаль нет?
почти все одиночки сидят на freepascal + lazarus, в некоторых корпорациях еще Delphi используется, но там лицензия от 3500 $
GNU Pascal как бы не нужен никому
Delphi много где используется в бизнес сегменте (не путать с серверами и ынтерпрайзом). А вот free pascal редкостное днище, которое даже до турбопаскаля 90-х не дотягивает даже по качеству документации, впечатление что сделано тяп-ляп неорганизованной толпой людей.
Delphi — это такой же паскаль, как Visaul Basic по сравнению с изначальным бейсиком.
Не уверен, что до сих пор где-то что-то живо написанное на обычном бейсике, а вот visual basic 6 живее всех живых, в том же бизнесе или в производственной среде. По крайней мере, vb6 скорее жив, чем мёртв.
И в этом плане тоже.
если какое-то древнее барахло кто-то как-то допиливает чтобы хоть как-то продолжало работать ибо денег сделать новое нет - это не значит что оно живее всех живыхдаже игоры на VB на винде запускать - то ещё удовольствие. То одной библиотеки не хватает, то - другой. Пока всё перепробуешь - желание играть исчезнет )
Вот когда работает и не трогают, потому что оно работает — в результате деньги и есть.
Просто умные люди не переписывают софт ради переписывания. Есть задача, она выполняется. Хотя кто-то и телефоны покупает каждый год, обогащая корпорастов.
Покупка телефона тоже решает некоторые задачи, просто у бизнеса задачи другие.
Дельфи и живёт в бизнесе потому что у него есть коммерческая поддержка. В гнутом виде никому не необходим.
делфи там живёт, т.к в своё время был весьма популярен и на нём много всего было сделано, что не желающие тратить лишнюю копейку предпочитают поддерживать и допиливать кое-как нежели разработать новый продукт на новых технологиях
> Слушайте, а что с GNU Pascal случилось?Пpoтуxло, зaвoнялoсь и испортилось, как и весь Пaскaль. На нём даже в шкoлaх никто уже не пишет. Место этому языку на пoмoйкe. Даже пoкoйный Niklaus Wirth сделал ставку на Обepoн, а не на Пaскaль.
Ну не совсем на помойке, скорее в зале славы музея. Канонический Pascal - это история, язык-демонстрация технологии структурного программирования, технология, которая вывела из кризиса индустрию программирования в 70-х годах.Кстати, неплохой язык был, простой и при этом надёжный. В нём указатели на данные и указатели на процедуры были надёжными, то есть для указателей отсутствовала арифметика и проверялось на отсутствие инициализации.
Oberon - это уже другое время, другие компьютеры, другие технологии.
Ну не совсем. Оберон это современное состояние оригинального Паскаля, от создателя (Никлауса Вирта).Паскаль (p-код, виртуальная машина) - -> Модула --> Модула-2 --> Оберон --> Оберон-2. На самом деле это всё один Паскаль. Никлаус Вирт мог бы как американцы писать Стандарт-1, Стандарт-2 и т.д.
Давайте посмотрим на последний рейтинг Tiobe (https://www.tiobe.com/tiobe-index/)В нём Delphi/Pascal за год поднялся с 11-го места на 9-е по популярности, между прочим обойдя PHP, Ada, Rust.
а в вот PYPL (рейтинг tutorials) показывает что Ada впереди
29 Deplhi/Pascal, 15 Ada и неожиданно 8 Rust
TIOBE отражает интерес к языкам, но не их использование
Спрос на спецов по Ada сейчас действительно приподнялся за счёт развёртывания оборонного заказа в США и в странах НАТО (кстати догадайтесь по ком звенит колокол).
Единственно верную статистику показывает только TIOBE.
растом пользуется полтора землекопа, жертвы маркетинга, его сложно не обойти
ха-ха нет. В C++ до сих завозят модули:(, а в Pascal-е оно было всегда
модули то есть, а поддержки в библиотеках нет и в CMake стандартно не поддерживаются - больше пяти лет уже прошло как было объявлено и принято в стандарт C++20
> Modula-2 (вообще кто-то слышал что то об этом языке?)Так это и есть улучшенная версия паскаля)
>Почему компилятор никак не развивается?А что тебе не хватает в гну-паскале?
> всякое непотребство типа Modula-2 (вообще кто-то слышал что то об этом языке?)По этому, как вы изволили выразиться, "непотребству" книхку издавались ещё до появления интернетов.
GNU Pascal заглох, потому что не было фреймворков и библиотек для него, а для Free Pascal'я - есть, Lazarus, QtPas и много всяких на github.
Чем вам Модула-2 не угодила, хороший язык для своего времени был. Используется до сих пор в сферах, где свисто-перделки не нужны.
> Поддержка указания диапазонов целых значений в выражениях "case"Скоро так и Паскаль догонят!
Как язык паскаль возможно лучшее что создано. Но то что он ушёл в обучение сыграло злую шутку.
>Как язык паскаль возможно лучшее что создано.Отвратительный язык, заточенный под англ. Это просто убого использовать операторные скобки и некоторые операции (целочисленное деление, остаток, логические операции) в виде слов.
Он был создан для обучения. А то что он ушёл в реальную разработку — ошибка.
В юникоде столько закорючек, а они английские слова используют, н-негодяи!
Дело не в английских словах. Мы используем латиницу и эллиницу в математике и физике, и даже в Таблице Менделеева. И в программировании это тоже не плохо.А плохо чрезмерное загрязнение ЯП ненужными словами.
С точки зрения живого языка then нужен для if, но с точки зрения формального языка — нет. Ведь Паскаль не брезгует символом + для обозначения сложения, а для матлогики зачем-то понадобились слова.
Слова воспринимаются глазом как операторы, поэтому использование гадких begin и end вместо вменяемых скобок усложняет чтение программы.
Уродское разделение подпрограмм на функции и процедуры, уродское объявление массивов, особенно многомерных, уродская переменная с именем функции в самой функции... Этот язык есть за что не любить.
(&(рефлекторно)(лиспанул))
Что значит "загрязнение" и "ненужными"? Во те ещё времена действовал лозунг "программирование - вторая грамотность!" и предполагалось, что этот самый кот (которого ещё и порядково меньше было) будут читать и писать не специально обученные машинисты, ой, "программисты" - а вот конечные пользователи, желающие добиться от железки чего-нибудь полезного. В этом плане максимальная близость к естественноиу языку и минимальная неожиданность считалась благом.
Наивнве были дiды, да. Кто только на эти грабли не наступал - от sql до 1с в результате пользователям всё, окромя чятжпт "сложна!", а программисты готовы любые закорюки учить, лишь бы "ни как у магглов!", ага.
Сейчас и вовсе - зайлайтинг-фолдинг-форматтеры-линтеры почти что угодно читаемым делают.Если пасквиль за что и не любить - так за строки. Впрочем, до сишников по к-ву проблем хорошо так не допрыгнули. Процедуры/функции в принципе логичны - не надо, не пользуйся, да? Массивы, кнешн, кривые - но ок.
Любой язык есть за что не любить - но право, на фоне победителя баттла паскаль б-жественно хорош, но индустрия печально знаменита выбором самых мегакривейших решений - теперь вот живём с этим.
>Что значит "загрязнение" и "ненужными"? Во те ещё времена действовал лозунг "программирование - вторая грамотность!" и предполагалось, что этот самый кот (которого ещё и порядково меньше было) будут читать и писать не специально обученные машинисты, ой, "программисты" - а вот конечные пользователи, желающие добиться от железки чего-нибудь полезного.Ну теперь мы видим насколько это тупиковый подход и почему Паскаль плох. Наверное потому си-подобный синтаксис так популярен, потому что не сильно загрязнён ненужным.
>В этом плане максимальная близость к естественноиу языку и минимальная неожиданность считалась благом
Я про то и говорю. Для меня англ — неестественный язык. И за то ругаю Паскаль. ЯП — это в первую очередь про математику, и, как в математике, вполне хорошо использовать систему знаков для действий, а слова оставить для имён переменных и функций.
>>Что значит "загрязнение" и "ненужными"? Во те ещё времена действовал лозунг "программирование - вторая грамотность!" и предполагалось, что этот самый кот (которого ещё и порядково меньше было) будут читать и писать не специально обученные машинисты, ой, "программисты" - а вот конечные пользователи, желающие добиться от железки чего-нибудь полезного.
> Ну теперь мы видим насколько это тупиковый подход и почему Паскаль плох.Ну вот сейчас мы видим, как плох Си и насколько велики размеры тупика, ага?
А на тот момент, когда остроконечники побеждали тупоконечников это было, мягко говоря, не очевидно.
И да, выиграли сишники не по причине "близости к истине изначальной концепции переносимого ассемблера" - а из-за того, что паскаль требовал от пользователя чуть-чуть, капельку, малость больше дисциплины. Ну-там, отделять интерфейс от реализации, объявлять переменные не методом "под себя" - а делать это в специально отведенном месте, не кастить все, что попало к *void и т.д. - а на такое ущемление свободов творческие личности пойтить никак не могли. Ну и при наличии определенного преимущества в эффективности (Вах! Пустая форма на делфи занимает 300кб, а-за-за! Нонешняя Go'шечка: "подержи мое пиво!") результат был немного предсказуем, а синтаксис тут если и "причем" то в очень и очень малой степени.> Наверное потому си-подобный синтаксис так популярен, потому что не сильно загрязнён
> ненужным.Нет. Си-подобный синтаксис это то, что мы получили "в нагрузку" вместе с Си. Сам по себе он плох, но привычен настолько, что в типовую голову мысль, "А что, можно как-то по-другому?!" влазит с очень большим трудом. Ну, как идея переработать алфавит в пользу большего удобства при чтении наплевав на legacy времен царапанья гусиным пером по бумаге.
>>В этом плане максимальная близость к естественноиу языку и минимальная неожиданность считалась благом
> Я про то и говорю. Для меня англ — неестественный язык. И
> за то ругаю Паскаль. ЯП — это в первую очередь про
> математику, и, как в математике, вполне хорошо использовать систему знаков для
> действий, а слова оставить для имён переменных и функций.И это тоже очевидная сейчас ошибка. "Язык программирования" _сейчас_ примерно вообще, полностью, вдребезги-напополам не про математику. Совсем. Если брать по объему написанного - он про рисование формочек и перекладывание жисонов по сети, математики там на уровне "свернул проволоку интегралом и достал из унитаза потерю".
>И да, выиграли сишники не по причине "близости к истине изначальной концепции переносимого ассемблера" - а из-за того, что паскаль требовал от пользователя чуть-чуть, капельку, малость больше дисциплины.Ну я не говорил о преимуществе Си, там есть и недостатки. Я говорил именно о синтаксисе, который был заимствован кучей языков.
>Нет. Си-подобный синтаксис это то, что мы получили "в нагрузку" вместе с Си. Сам по себе он плох, но привычен настолько, что в типовую голову мысль, "А что, можно как-то по-другому?!"
«Мы» — это кто? Я познакомился с Си/Си++ после Паскаля, и не хочу возвращаться обратно. Для меня синтаксис Си — это наоборот преимущество. Исключая некоторые моменты (например дробное и целое деление).
>И это тоже очевидная сейчас ошибка. "Язык программирования" _сейчас_ примерно вообще, полностью, вдребезги-напополам не про математику.
Это если обучать г-но кодеров. Нормальный программист должен понимать цифровую схемотехнику, и всё что выше. Не обязательно пользоваться, а просто понимать как оно устроено.
>>Нет. Си-подобный синтаксис это то, что мы получили "в нагрузку" вместе с Си. Сам по себе он плох, но привычен настолько, что в типовую голову мысль, "А что, можно как-то по-другому?!"
> «Мы» — это кто? Я познакомился с Си/Си++ после Паскаля, и не
> хочу возвращаться обратно. Для меня синтаксис Си — это наоборот преимущество.
> Исключая некоторые моменты (например дробное и целое деление).Ну, для меня это что-то из разряда "пишем рецепты на латыни и читаем молитвы на церковнославянском". После *цати лет церковно-приходской оно уже так удобно-удобно, что аж и не замечаешь. Зато со стороны смотришь - о-о-оо! Ваааау! Поди что-то сложное делает - простому человеку и не понять...
>>И это тоже очевидная сейчас ошибка. "Язык программирования" _сейчас_ примерно вообще, полностью, вдребезги-напополам не про математику.
> Это если обучать г-но кодеров. Нормальный программист должен понимать цифровую схемотехнику,
> и всё что выше. Не обязательно пользоваться, а просто понимать как
> оно устроено.Ну хорошо бы конечно чтобы "да" - но для того, чтобы ездить на автомобиле _уже_ не надо быть автомехаником и понимать, как что устроено - просто садишься - и едешь, никаких сакральных знаний. А еще в середине прошлого века шофер вааа! большой человек, это ж СТОЛЬКО знать надо - одним сцеплением без синхронизации пользоваться, чуть не вовремя двойной выжим сделал - и привет...
>Ну, для меня это что-то из разряда "пишем рецепты на латыни и читаем молитвы на церковнославянском"Продолжим вашу цепочку: «программируем на английском». За что я и пинаю Паскаль: слова вместо символов.
>Ну хорошо бы конечно чтобы "да" - но для того, чтобы ездить на автомобиле _уже_ не надо быть автомехаником и понимать, как что устроено - просто садишься - и едешь, никаких сакральных знаний.
Знание физики и устройства автомобиля всё же даёт преимущество в мастерстве управления и оптимизации износа. Плюс не забываем что мастерство позволяет достичь лучшей результативности и меньшей требовательности к аппаратным ресурсам (например можно экономить на АКП).
>>Ну, для меня это что-то из разряда "пишем рецепты на латыни и читаем молитвы на церковнославянском"
> Продолжим вашу цепочку: «программируем на английском». За что я и пинаю Паскаль:
> слова вместо символов.Тут не в "словах"\"символах" дело, а в искусственном использовании отдельного языка для отделения себя от всех остальных с искусственным же обоснованием важности-и-нужности такого решения. Впрочем, врачи обычно не рассказывают, что рецепты на латыни действуют лучше - да и попы про то, что боженька окромя церковнославянского языков не разумеет - зачесывают не все.
>>Ну хорошо бы конечно чтобы "да" - но для того, чтобы ездить на автомобиле _уже_ не надо быть автомехаником и понимать, как что устроено - просто садишься - и едешь, никаких сакральных знаний.
> Знание физики и устройства автомобиля всё же даёт преимущество в мастерстве управления
> и оптимизации износа. Плюс не забываем что мастерство позволяет достичь лучшей
> результативности и меньшей требовательности к аппаратным ресурсам (например можно экономить
> на АКП).Но в реальности всем настолько пофиг, что просто пофиг. Жизнь, по слухам - одна, и тратить её на 0,5% эффективности в очень узкой области... Б-жечки-кошечки, зачем? Рыночек порешал, в общем - порешает и тут.
>Тут не в "словах"\"символах" дело, а в искусственном использовании отдельного языка для отделения себя от всех остальных с искусственным же обоснованием важности-и-нужности такого решения. Впрочем, врачи обычно не рассказывают, что рецепты на латыни действуют лучше - да и попы про то, что боженька окромя церковнославянского языков не разумеет - зачесывают не все.ЯП настолько же искусственны, насколько искусственна сама техника. Не нравится язык техники — не надо её использовать.
>Но в реальности всем настолько пофиг, что просто пофиг. Жизнь, по слухам - одна, и тратить её на 0,5% эффективности в очень узкой области... Б-жечки-кошечки, зачем? Рыночек порешал, в общем - порешает и тут.
Ну потому и имеем тормозящие и жрущие память и батарею приложения. Потому что корпорациям плевать на экономию ваших ресурсов, им важно деньги зарабатывать.
Это не нормально, когда приложения банков весят под 100 мегабайт, но вы схаваете, ведь жизнь у хозяина банка одна и не барское дело — экономить ресурсы холопов.
А в итоге благодаря таким вот «оптимизациям» деградируют специалисты при прогрессе техники, хотя комментарием ниже вы призывали к обратному.
Грустно это.
>>Тут не в "словах"\"символах" дело, а в искусственном использовании отдельного языка для отделения себя от всех остальных с искусственным же обоснованием важности-и-нужности такого решения. Впрочем, врачи обычно не рассказывают, что рецепты на латыни действуют лучше - да и попы про то, что боженька окромя церковнославянского языков не разумеет - зачесывают не все.
> ЯП настолько же искусственны, насколько искусственна сама техника. Не нравится язык техники
> — не надо её использовать.Вы это 0 и 1 написали, надеюсь? Все остальное - не "язык техники", а язык т-пых кожаных мешков, ниасиливших настоящую речь. Плохой техножрец, негодный - фу таким быть!
>>Но в реальности всем настолько пофиг, что просто пофиг. Жизнь, по слухам - одна, и тратить её на 0,5% эффективности в очень узкой области... Б-жечки-кошечки, зачем? Рыночек порешал, в общем - порешает и тут.
> Ну потому и имеем тормозящие и жрущие память и батарею приложения. Потому
> что корпорациям плевать на экономию ваших ресурсов, им важно деньги зарабатывать.
> Это не нормально, когда приложения банков весят под 100 мегабайт, но вы
> схаваете, ведь жизнь у хозяина банка одна и не барское дело
> — экономить ресурсы холопов.Да вполне нормально. Вы же ресурс калорий за обедом не рассчитываете и тарелку на два раза не облизываете - ещё поди и не доедете иногда - экая, понимаешь, растрата ресурсов!
Но чот идея кон-тро-ли-ро-вать много желающих не соберёт.> А в итоге благодаря таким вот «оптимизациям» деградируют специалисты при прогрессе
> техники, хотя комментарием ниже вы призывали к обратному.
> Грустно это.Да не деградируют, Господи. Решают другие задачи. Мы в институте вот считали ветровую нагрузку на элементы фасада - ручками Вот. Сейчас это делает cad автоматически - стали ли архитекторы хуже? А если учесть, что то, что в СССР делало проектное бюро человек на 200 сейчас делают 5-7?
> Мы в институте вот считали ветровую нагрузку на элементы фасада - ручками Вот. Сейчас это делает cad автоматическиЕсть только одна проблема. Те архитекторы, которые не в курсе, что на этот параметр надо обращать внимание
>> Мы в институте вот считали ветровую нагрузку на элементы фасада - ручками Вот. Сейчас это делает cad автоматически
> Есть только одна проблема. Те архитекторы, которые не в курсе, что на
> этот параметр надо обращать вниманиеОни сейчас с вами в одной комнате? Подмигните два раза, если да.
Считать расчёт ветровой нагрузки руками или там сопромат двутавры вместо выбора по каталогу - ну можно конечно и даже хрен ты потом это всё забудешь (т.е. Как считать забудешь с гарантией патамучта нах. ни разу в жизни не понадобится - но сам факт расчёта в памяти определённо останется) - но кпд сей мнемонической технологии некоторым образом удручает
>Вы это 0 и 1 написали, надеюсь? Все остальное - не "язык техники", а язык т-пых кожаных мешков, ниасиливших настоящую речь. Плохой техножрец, негодный - фу таким быть!К чему эти кривляния?
>Да вполне нормально. Вы же ресурс калорий за обедом не рассчитываете и тарелку на два раза не облизываете - ещё поди и не доедете иногда - экая, понимаешь, растрата ресурсов!
>Но чот идея кон-тро-ли-ро-вать много желающих не соберёт.Всегда доедаю до конца.
Ваши рассуждения хороши в мире неисчерпаемых ресурсов. А вот в мире где человечество потребляет больше чем воспроизводит природа — это приведёт к средневековью в будущем. ричём даже пары поколений не пройдёт.>Да не деградируют, Господи.
Именно деградируют. Для того, чтобы решать другие задачи надо хотя бы понимать как решаются предыдущие. Чтобы в голове возникал нужный уровень абстракции. А если программист путает союз И и логическое И — то перед вами деградант. Чему Паскаль способствует, не разделяя слово и логическую операцию.
> ненужными словамиДа ты ещё язык Ada не видел. Кстати моё мнение, что слова гораздо лучше закорючек сишных, более наглядно. Тем более ты их целиком не пишешь, за тебя их вставляет твоя IDEшка.
>что слова гораздо лучше закорючек сишных, более наглядноЯ уже писал выше.
1. Если слова лучше, то откажитесь от использования математических знаков: они тоже закорючки. Будьте последовательны до конца.
2. Слова воспринимаются как команды. Без begin и end код смотрится лучше (субъективно, конечно же). Чем меньше служебных слов, тем лучше.
Математическая нотация с её минимализмом ненадёжна (где-то поставил лишнюю точку над символом или шрих - и ошибка), а языки программирования разрабатывают с оглядкой на надёжность, поэтому в синтаксисе и ключевых словах присутствует избыточность (это как код Рида-Соломона или Витерби). Поэтому не " ^T ", а "pointer to T"
Неужели я так сложно выражаю мысли?Ведь если
>Поэтому не " ^T ", а "pointer to T"
то тогда логично что
>не 2 + 3, а 2 add 3, а лучше sum(2, 3)
Но ведь вы же, сторонники избыточности, плеваться будете от таких предложений.
Мысли выражаете понятно. Только это не про линейку виртовских языков. Вы говорите что человеку быстрее и понятнее минимизированный Сишный синтаксис - я с этим согласен, да и все согласны. Но Вирт и Эшбиа создавали свои языки не чтобы программисту было легче читать, а чтобы случайно не сделать ошибку при наборе. Отсюда многословность и неуклюжесть конструкций.Делать sum(2,3) вместо 2+3 нет смысла, так как если случайно напишем 2++3 то эта ошибка сразу же отловится компилятором. А вот ^^T - не отловится. Поэтому pointer to T.
Ну и рыночек сделал выбор: эти творения на свалке.>2+3 нет смысла, так как если случайно напишем 2++3
А если наберём 22+3 — то не отловится. Это выдуманный пример.
>рыночек сделал выборПравильно заметили. Рынку не нужны языки повышенной надёжности, как Modula-2, Oberon, Ada. У них другая область применения.
Я не вижу тут повышенной надёжности. Это выдуманный пример.А вот более компактный код повышает читабельность, а вместе с ней и скорость восприятия написанного. Это влияет на работу. В отличие от мнимой надёжности слов.
> РынкуТак всё верно. Рынку нужны языки с минимальным порогом входа, чтобы можно было привлечь "специалистов" без профильного образования после курсов :-)
>>что слова гораздо лучше закорючек сишных, более наглядно
> Я уже писал выше.
> 1. Если слова лучше, то откажитесь от использования математических знаков: они тоже
> закорючки. Будьте последовательны до конца.
> 2. Слова воспринимаются как команды. Без begin и end код смотрится лучше
> (субъективно, конечно же). Чем меньше служебных слов, тем лучше.Так этот тезис в обе стороны действует - что ж вы книжки закорючками не пишете? Это ж сколько места можно съэкономить, заменив аж целое слово на какую-нибудь скобочку? Но чот иероглифическое письмо людям en masse как-то не зашло, а те, кому когда-то "зашло" сейчас старательно не знают, как от него избавиться...
Всему своё место.
Шахматная нотация удобнее для записи партий, чем описательная (которая была в средневековье).
Химические формулы удобнее, чем описание реакций.
В математике и физике то же самое.
И в программировании, которое тоже суть математика, так должно быть. Слова в программировании — это для переменных/функций/классов, а остальное либо максимально коротко, либо знаками.
> Всему своё место.
> Шахматная нотация удобнее для записи партий, чем описательная (которая была в средневековье).
> Химические формулы удобнее, чем описание реакций.
> В математике и физике то же самое.
> И в программировании, которое тоже суть математика, так должно быть. Слова в
> программировании — это для переменных/функций/классов, а остальное либо максимально
> коротко, либо знаками.Ну, тут, видимо - надо просто зафиксировать расхождение аксиоматики. Для вас - "программирование - это математика" со всеми вытекающими - для меня "способ объяснить компьютеру то, чего ты от него хочешь" - отсюда и разница в требованиях.
Предполагаю, кстати, что оба мы по своему правы )))
Программирование и есть математика: жёсткая формализация, и никакого отклонения от стандартов языка. Никакому живому языку (даже английскому) такая формализация и не снилась.Вы объясняете компьютеру то, что вы от него хотите языком математики.
Я приведу простой пример. Дана задача: определить являются ли два числа положительными.
С точки зрения математики пишем так:> (a > 0) И (b > 0)
Однако многие, я бы сказал что большинство учеников, изучающих тему, пишут такое:
> a И b > 0
И чем младше ученик, тем вероятнее он это напишет, потому что ссылается на свой опыт использования живого языка. Именно поэтому я считаю использование слов вместо знаков действия вредным, ибо надо различать союз, как часть речи и математическое действие. Именно в этом Вирт обделался.
>[оверквотинг удален]
> Вы объясняете компьютеру то, что вы от него хотите языком математики.
> Я приведу простой пример. Дана задача: определить являются ли два числа положительными.
> С точки зрения математики пишем так:
>> (a > 0) И (b > 0)
> Однако многие, я бы сказал что большинство учеников, изучающих тему, пишут такое:
>> a И b > 0
> И чем младше ученик, тем вероятнее он это напишет, потому что ссылается
> на свой опыт использования живого языка. Именно поэтому я считаю использование
> слов вместо знаков действия вредным, ибо надо различать союз, как часть
> речи и математическое действие. Именно в этом Вирт обделался.Это повод компьютеры делать умнее, а не людей - тупее под потребности железки.
>Это повод компьютеры делать умнее, а не людей - тупее под потребности железки.Делать компьютер умнее == делать людей тупее! Чем умнее становится вычислительная техника => тем ниже порог вхождения => тем тупее становится средний пользователь.
>>Это повод компьютеры делать умнее, а не людей - тупее под потребности железки.
> Делать компьютер умнее == делать людей тупее! Чем умнее становится вычислительная техника
> => тем ниже порог вхождения => тем тупее становится средний пользователь.Да с чего бы? Просто пользователь больше занят решением своих задач уровня предметной области, а не правильному произнесению молитвы железному болвану, чтоб он сделал чего-нибудь.
Компьютер для человеков, а не специально обученные человеки для компьютеров.
>Компьютер для человеков, а не специально обученные человеки для компьютеров.Речь шла о программистах, а не о пользователях. Когда программист не понимает как работает железо — это и есть профнепрегодность.
Да и в любой области так: чем больше загнано под капот, тем тупее пользователь. Специализированный софт тоже надо уметь использовать.
Забыл ещё implementation секцию! :)) А то вдруг прогеру скучно менять только одо место - пусть попрыгает по листингу и поменяет декларации! :)
Там и другие секции есть ;)
Это же модуль описывается, а не файл с набором чего то.
Хотя, двойное переписывание ручками, это точно пережиток прошлого.
Даже тупо набивать все эти begin end тупо напрягает, куда короче и быстрее {}, не говоря уже о всяких извратов типа array of integer
> Даже тупо набивать все эти begin end тупо напрягает, куда короче и быстрее {}Для вас лапчатых есть язык, где можно эмодзи натапать.
>> Даже тупо набивать все эти begin end тупо напрягает, куда короче и быстрее {}
> Для вас лапчатых есть язык, где можно эмодзи натапать.Их наверное даже на ассемблере можно натапать. Ккак и в любом ЯП умеющем в консоль плеваться. Консоли нынче обычно юникодные.
> использование гадких begin и end вместо вменяемых скобокУ тебя проблемы, дружище.
>В юникоде столько закорючек, а они английские слова используют, н-негодяи!Так, вроде, появился язык, где вместо ключевых слов эмодзи.
+1. Паскаль испортило, как это ни смешно, begin-end. Если всякие "остатки от деления" используются дай бог в 1% программ, то begin-end - сплошь и рядом. И если вместо чтения названий функций тебе приходится ещё и читать бегины-енды, это просто катастрофа, даже если они подсвечены.
Интересно, я один такой, что мне что begin-end, что {} — фиолетово? Споры тупоконечников с остроконечниками какие-то, честное слово.
Не один.
> Интересно, я один такой, что мне что begin-end, что {} — фиолетово? Споры
> тупоконечников с остроконечниками какие-то, честное слово.А мне не фиолетово. Ибо
1) Быстрее печатать. Даже с автодополнением в IDE/редакторах - обычно надо нажать несколько клавиш. Или это автодополнение периодически будет прикалываться и мешаться.
2) Визуальный мусор. Скобки визуально хорошо выделяют
{
блок кода
}С другой стороны
BEGIN
END
...извините тупо разной длины и как именно БЛОК КОДА это воспринимается ХУЖЕ. Т.е. факап юзабилити. А, занудам академикам про это не рассказывали.
Вот казалось бы 21 век уже - а поди ж ты не всем кодерам рассказали, что код читается чаще, чем пишется и что основные затраты несутся на фазе поддержки программного продукта, а не при его разработке... бедолаги все еще уверены, что количество их клатц-клатц по клавиатуре хоть в какой-то степени хоть кого-то интересует.И да, BEGIN\END появились несколько раньше чем IDE с хайлатингом\фолдингом блоков кода, прикинь? И да, без этого вот всего глазом при чтении с плохонького монитора это прям ОФИГЕТЬ, как лучше чем )}(} - особенно с учетом того, что авторформат кода появился так же несколько позднее - да и при его наличии находятся мм-ммм... любители накласть в одну строчку съэкономив клатц-клатц.
Да не думал никто о плохих мониторах. Тогда и шрифты были моноширинными, и разрешение экрана было невысокое, и всё было видно неплохо. Хватит сказки придумывать.>Вот казалось бы 21 век уже - а поди ж ты не всем кодерам рассказали, что код читается чаще, чем пишется и что основные затраты несутся на фазе поддержки программного продукта, а не при его разработке...
И именно поэтому операторная скобка не должна выглядеть как оператор. Хватит хвататься за парадигмы 20-го века.
> Да не думал никто о плохих мониторах. Тогда и шрифты были моноширинными,
> и разрешение экрана было невысокое, и всё было видно неплохо. Хватит
> сказки придумывать.Оу. Вы обладателю аквариума об 256 оттенков зеленого это будете рассказывать? Нет, может конечно лет на 20 раньше оно прям сильно лучше было, а к середине 90х испортилось, не знаю - 8К-HDR-WAYLAND by Никлас Вирт не застал. Но сейчас мне прям напрягаться приходится, чтобы понять, где какая )}))})
>>Вот казалось бы 21 век уже - а поди ж ты не всем кодерам рассказали, что код читается чаще, чем пишется и что основные затраты несутся на фазе поддержки программного продукта, а не при его разработке...
> И именно поэтому операторная скобка не должна выглядеть как оператор. Хватит хвататься
> за парадигмы 20-го века.Действительно. Человеки с той поры НАСТОЛЬКО эволюционировали что устаревшие парадигмы необходимо отбросить. Синтаксис начала 70х годов прошлого века, например, ага.
>Оу. Вы обладателю аквариума об 256 оттенков зеленого это будете рассказывать?БК 0010 — четыре цвета. Всё выглядело нормально. Любая точка была видна (хоть и выбор был только из бейсика).
>Человеки с той поры НАСТОЛЬКО эволюционировали что устаревшие парадигмы необходимо отбросить.
Необходимо отбросить парадигмы устаревшего оборудования.
Да и жить парадигмами начала создания ЯП (когда ЯП приближали к живым языкам) тоже пора перестать. Иначе придётся признать что лучше Кобола нет ничего.
>>Оу. Вы обладателю аквариума об 256 оттенков зеленого это будете рассказывать?
> БК 0010 — четыре цвета. Всё выглядело нормально. Любая точка была видна
> (хоть и выбор был только из бейсика).Только глаза от моих 320*240 через три часа вытекать начинали, ага.
>>Человеки с той поры НАСТОЛЬКО эволюционировали что устаревшие парадигмы необходимо отбросить.
> Необходимо отбросить парадигмы устаревшего оборудования.
> Да и жить парадигмами начала создания ЯП (когда ЯП приближали к живым
> языкам) тоже пора перестать. Иначе придётся признать что лучше Кобола нет
> ничего.Ну, популярность chatgpt с постепенным переходом к "программированию-по-постановке" немножко как бы намекает, да? Компьютеры - все ж таки для человеков, а не техножрецы для компьютеров.
>Только глаза от моих 320*240 через три часа вытекать начинали, ага.Только говорил я о «не видно», а не о «кайфово было».
>Ну, популярность chatgpt с постепенным переходом к "программированию-по-постановке" немножко как бы намекает, да?
Возможно. Только когда этот чат будет делать не то, что от него просят кто будет разбираться? Те самые техножрецы. Всегда будет актуальна полная цепочка понимания знаний от n-p-перехода до оконной формы. И чем ниже уровень понимания (ниже в плане абстрагирования) — тем более востребован специалист.
Для тебя реально в написании кода скорость набора узкое место?
Именно поэтому в Modula-2 begin-end существенно меньше. Пример с IF:
IF Условие THEN
Операторы
ELSIF Условие THEN
Операторы
ELSIF Условие THEN
Операторы
...
ELSE
Операторы
END
Т.е. стали использоваться разные операторные скобки для разных случаев. Бейсик передаёт привет. Это просто ужасный пример.
ха-ха. Посчитайте пробелы-табы в Питоне. begin...end дело привычки. Вот в Ada вообще к end добавляется имя функции и это наглядно :)procedure Main is
A, B : Integer := 0;
C : Integer := 100;
D : Integer;
begin
A := A + 1;D := A + B + C;
end Main;подобное объявление типов используется в TypeScript, Kotlin и Go отчасти как и оператор :=
begin/end, если они не расположены в одной строке, а на разных, "читать" не надо. Они короткие, и воспринимаются целиком за одну фиксацию.
Бред сивой кобылы
for x in xset
do begin
траляляend;
вроде не сильно мешает
Их еще набивать нужно. Лишний напряг даже с IDE, потому что IDE разные бывают и помнить все сочетания клавиш у разных IDE - тоже лишний напряг.
Сильно мешает, особенно когда у тебя программа на миллион строк. Тебе сказали уже выше об этом!
Программы на миллион строк никто вручную не набивает без использования IDE с автоматической подстановкой слов.
Для набора { или } никакая автоподстановка не нужна вообще. Почувствуйте разницу!
Да что уж там, сразу на миллиард. И всё пилит один человек.
> Да что уж там, сразу на миллиард. И всё пилит один человек.В одном файле! В блокноте!
В блокноте с уапрвлением в стиле vim.
Какая наxрен разница, сколько человек пилит. Если вместо 5 символов в "begin" достаточно одного "{", то это явно недоработка языка (Pascal). Не надо быть гением, чтобы это понять. Даже ежу это понятно!
> Какая наxрен разница, сколько человек пилит. Если вместо 5 символов в "begin"
> достаточно одного "{", то это явно недоработка языка (Pascal). Не надо
> быть гением, чтобы это понять. Даже ежу это понятно!Вы поди из тех, кто все переменные одной буквой называет?
Нормально называю, но люблю короткие, понятные и лаконичные имена, т.к. с длинными код получается абсолютно нечитаемым.
И да, использую всякие
typedef int32_t i32
чтобы вместо всяких int32_t и т.п. использовать короткие i32 и т.п. Код получается короче и намного легче воспринимается.
> Нормально называю, но люблю короткие, понятные и лаконичные имена, т.к. с длинными
> код получается абсолютно нечитаемым.
> И да, использую всякие
> typedef int32_t i32
> чтобы вместо всяких int32_t и т.п. использовать короткие i32 и т.п. Код
> получается короче и намного легче воспринимается.Не-не, такой "Hello, world!" нам не нужен...
Разумеется, каждому своё. Тебе ещё долго предстоит многому учится)
> for x in xset
> do begin
> траляля
> end;
> вроде не сильно мешаетОно еще и визуально замусорено. Сравните с
for x in xset
{
траляля;
}Ну и что тут читабельнее как логический блок кода? :)
В первом варианте гораздо читабельнее. Что это за закорючки я понятия не имею (не программист), а вот в паскале всё ясно даже мне - домохозяину за 50.
>Что это за закорючки я понятия не имею (не программист)Неспециалист и не должен это читать. С такой «логикой» можно и таблицу Менделеева отменить. Там вообще непонятный набор букв.
> Паскаль испортило, как это ни смешно, begin-end.Так для лапчатых, которые ничего кроме смартфона не держали отродясь, есть язык, где вместо ключевых слов можно натапать эмодзи. А серьезные люди наоборот приветствуют многословность, т.к. оно минимизирует ошибки и увеличивает читабельность. Ada как отличный тому пример.
Ты сам это придумал, злобный заклятый аноним? Или мамка подсказала? Признавайся!
>А серьезные люди наоборот приветствуют многословностьА эти «серьёзные люди» с вами в одной комнате? Какой-то странный аргумент: придумать неких абстрактных людей и ссылаться на них, в то время как можно просто посмотреть на реальность.
Вот вам пример: Dev-cpp — среда для Си++, изначально написанная на Паскале. Все форки на Паскале, как и оригинал, умерли, а единственный живой форк — на плюсах.
Вот что он форкал: https://github.com/royqh1979/Dev-CPP
А вот что он написал: https://github.com/royqh1979/RedPanda-CPPИ мне трудно найти программы на Паскале, которыми бы я пользовался. Среди них только Double Commander, остальное на других языках. Видать остальное писали не слишком серьёзные люди.
> Поддержка присвоения имён циклам для того, чтобы ссылаться на них в коде.зачем, если есть goto?
Только хотел написать, что они goto переизобрели.
так у них с логикой проблемы, метка то после цикла должна быть :) а то у них выход из цикла означает начать его заново.
К хорошему всегда возвращаются. Никогда не понимал отказа от goto, ведь это крайне удобная вещь, с которой можно писать очень оптимизированный код, а не раздувать его ради простой функциональности на 100500 строк.
> Никогда не понимал отказа от goto,так вам не на С надо писать, а на асм. В Си чисто по религии goto (фактически асмовский jump) быть не должно.
С jmp, jnz/jne можно очень красивый код писать. А рилигия в программировании, как и любые догмы, скорее вредны. Нужно всегда отталкиваться от целесообразности и конкретных требований\пожеланий к проекту.
> С jmp, jnz/jne можно очень красивый код писать.так С создавали, чтобы абстрагироваться от асм и код был более структурным, а не jmp акробатика вверх-вниз. Но почему-то эту акробатику в виде примитивного goto оставили.
>> С jmp, jnz/jne можно очень красивый код писать.
> так С создавали, чтобы абстрагироваться от асм и код был более структурным,
> а не jmp акробатика вверх-вниз. Но почему-то эту акробатику в виде
> примитивного goto оставили.Потому что иногда с ним все же лучше чем без него. Но - именно иногда. Впрочем если ты надругательство над структурным программированием по полной хотел - попробуй setjmp/longjmp, во. С другой стороны, из этого делают всякие корутины и тому подобное. Вот прям на си. Потому что так можно было. Вот благодаря этому как раз.
> попробуй setjmp/longjmpполезно для выхода из рекурсий.
В 8080 была такая замечательная вещь — CALL по условию/RET по условию. Количество джампов сокращало в разы.
Так это же стек затрагивало, а значит уже сильно медленнее.
j<условие> метка
ret
метка:
— 10 + 10 тактов.r<условие>
— 5/11 тактов.
Прикинь, в ARM почти любая инструкция может быть исполнена по условию.
У армов конечно, как и у ириски - очень вкусные инструкции, но лично меня всегда немного раздражало что нужно всегда отдельно грузить из памяти в регистры, перед операциями.
Понятно что иначе никак, но просто интеловский набор команд, когда можно сразу вторым операндом указать память, да еще со сдвигом, мне больше нравиться, просто лаконичнее выглядит.
> Понятно что иначе никак, но просто интеловский набор команд, когда можно сразу
> вторым операндом указать память, да еще со сдвигом, мне больше нравиться,
> просто лаконичнее выглядит.У ARM регистров общего назначения сильно больше чем у i8080. Мягко говоря. И цель чтобы команды были - простыми. А потому быстрыми в исполнении, и минимальным размером ядра cpu, если на минималках.
ARM - это state of art, красивый и современный набор команд, x86 в целом по сравнению с ним - понятно чего. Но вон те constraints дизайна неизбежно наложили свой отпечаток. С другой стороны x86 в результате вообще - в минимализм не смог. А i8080 никто всерьез юзать уже не хочет. Поэтому в мобилках, планшетках и (около)эмбедовке x86 просто нет.
Фирма ARM продала что-то типа 8 миллиардов, чтоли, ядер за прошлый год. А intel сколько? :)
> в ARM почти любая инструкция может быть исполнена по условиюНо почему тогда армы до сих пор годятся только для телефонов? Сколько там уже пророчат смерть wintel?
Помнится были даже смарты на интеле...
И всякие мини планшеты, тоже на интеле, у асуса таких было много, да и не только у них.
Вернее, не совсем планшеты, с резистивным тач экраном и выдвижной кверти клавиатурой, как прокачанные кпк.
Хороше время было!
Почему не совсем планшеты? Вполне полноценные планшеты на андроиде были, у самого парочка валяется, один до сих пор рабочий даже.
Для тебя вся техника Apple и ноуты на Snapdragon какая-то шутка?
> Для тебя вся техника Apple и ноуты на Snapdragon какая-то шутка?И не только для него. Ты ж не будешь спорить, что там телефонный процессор (SoC)?
И что в нём телефонного?
я, конечно, многое на этом сайте видела, но называть семейство процессоров, где старшие модели могут выделять до *70 ватт* тепла телефонными - это что-то новое
Серьёзные люди, называющие десктопный процессор телефонным… ну ладно.
>Сколько там уже пророчат смерть wintel?Ну шо вам на это сказать? Вот сколько уже пророчат вендекапeц, а он, всё ещё не натупил, но... Кто хотел, тот уже давно для себя устроил этот вендекапeц - давно и успешно пользуется на десктопе GNU/Linux. Так же и с железом.
> давно и успешно пользуется на десктопе GNU/LinuxДистрохопинг с периодическими возвращениями на Windows 11 от безнадёги, не означает, что "успешно пользуются".
Gentoo c конца 2004. Венда на локалхосте в качестве десктопа никогда не использовалась и до этого.
Значит и комп особо был не нужен для реальных дел
> Но почему тогда армы до сих пор годятся только для телефонов? Сколько
> там уже пророчат смерть wintel?Вон там такие телефонные ARM - в TOP500 отсвечивают. Наверное, вы ошиблись и имели в виду - телефонную станцию? :)
Могла быть, лет 10 назад. В ARMv8 биты предикации выкинули, а в Thumb их никогда и не было.
> Могла быть, лет 10 назад. В ARMv8 биты предикации выкинули, а в
> Thumb их никогда и не было.В thumb2 есть еще более умный IT<block> который кодирует условное выолнение нескольких команд за ним. Компактно, умно и эффективно.
Ну вы мне прямо глаза открыли.
Вообще это не исключительная особенность ARM.
А вот то, что под ARM — особенно современный — писать на ассемблере может только злостный мазохист, я и так знаю.
А в данном случае речь была о том, что 8086 вроде как и преемник 8080, а вот кое-чем полезным пришлось пожертвовать (до сих пор помню впечатления при переходе с Z80 на 8086: «а что, так можно разве?! …а вот так, что ли, нельзя?»).
Ты говоришь чушь и сам не понимаешь почему - просто повторяешь других, говорящих такую же чушь.
> говорящих такую же чушьв каком месте она у вас заела?
А надёжность?
"В своей следующей работе Дейкстра обосновал тот факт, что для кода без goto намного легче проверить формальную корректность."
> А надёжность?
> "В своей следующей работе Дейкстра обосновал тот факт, что для кода без goto намного легче проверить формальную корректность."И сел со своей войной против goto в лужу.
Более подходящего способа для управления ресурсами в Си чем goto нет.После такого его невозможно воспринимать всерьез.
Си невозможно принимать всерьёз? Ну, это вы, конечно, погорячилась - но что-то определённо есть
Дейкстра вроде как главным образом боролся против неструктурных языков (оригинальный Бейсик), где нет блоков кода и все управление потоком выполнения основано на goto. В чем проблема использовать goto там, где он удобен и не ломает структурную парадигму? Break с меткой появился вроде бы изначально в Джаве по причине отсутствия там оператора goto. По сути break и continue — это просто ограниченные goto (даже в варианте без меток).Но к черту все это, продолжения (continuations) — наше все)
1. Не очень понимаю, на что он намекает. Для кода без развилок и циклов проверить формальную корректность ещё проще. Он предлагает выкинуть развилки и циклы?
2. Там, где требуется проверять формальную корректность, goto можно не использовать.
3. Сейчас бы хвастаться отсутствием goto в языке с поддержкой исключений. goto хотя бы из функции не выходит, тогда как исключения прошивают весь стек вызовов.
>goto хотя бы из функции не выходитДа ну, шо вы говорите? Вы можете метку впендюрить куда угодно в пределах файла.
И в C, и в C++ метка обязана быть в той же функции, что и ссылающийся на неё goto.
> И в C, и в C++ метка обязана быть в той же
> функции, что и ссылающийся на неё goto.Он, наверное, setjmp/longjmp на саом деле хотел, но боялся себе в этом признаться :)
И много ты проверяешь "формальную корректность"? Ты хоть сам понимаешь, что это вообще?goto - он даже в процессоре есть. Теперь что, процессор - формально некорректный??
Прежде чем взывать к идолам, стоит сначала включать голову.
конечно надо же сделать как в расте (Ё..... тут пятиэтажный мат)Named loops also have a distinct advantage of having substantial prior art across multiple other programming languages. C is not bound by any other language but to have a control feature behave in exactly the same way as precedent set by the wider Community is extremely good for readability and lowers the surprise factor. The idiom has been proven to work well in practice, and there is no good reason for C to diverge from a model the rest of the programming language meta-community seems to have found clearest.
For instance, in Rust:
fn main() {
'outer: loop {
println!("Entered the outer loop");'inner: loop {
println!("Entered the inner loop");// This would break only the inner loop
//break;// This breaks the outer loop
break 'outer;
}println!("This point will never be reached");
}println!("Exited the outer loop");
}
Выдыхай. Эту фичу тру-UNIX деды придумали для Limbo тридцоть лет назад, оттуда ее позаимствовали в Go и Rust. Одобрено ЪUNIXЪ-Омниссией с 1995, проверено временем.
> Эту фичу тру-UNIX деды придумали для Limbo тридцоть лет назадну вообще отлично, вы только это не мне, а тем "придумывателям" расскажите, которые в пример раст приводят.
> Выдыхай. Эту фичу тру-UNIX деды придумали для Limbo тридцоть лет назад, оттуда
> ее позаимствовали в Go и Rust. Одобрено ЪUNIXЪ-Омниссией с 1995, проверено
> временем.Вы там что, грибов объелись? Еще не сезон же вроде? Какое Limbo нахрен тру-UNIX? Когда это какой-то левый новолел, как и хрусты всякие? Примерно настолько же извратное и кривое :)
А вот так, Plan 9/Inferno больше UNIX по духу, чем позерские настоящие UNIX'ы.
И разработано теми самыми UNIX-дедами, Томпсон, Ричи, Керниган, Пайк.
for (int i = 0; i < n; ++ i) {
for (int j = 0; j < n; ++ j) {
if (something (i, j))
goto end;
}
}
end:С goto куда интуитивно, чем пихать лейбл в начало оператора for (даблфейспалм). По логике меток, вы возвращаетесь и начинаете циклы заново, а не выходите из него вовсе.
тог уж так надо было так писать, куда интуитивно чем в начале.
for () { } : for-end-identifier;
Тут много зависит от тимлида :) Если упёртый и аргументы в пользу goto не принимает, то придётся в функцию оборачивать и делать ретёрны.
из таких вложенных циклов я обычно выхожу устанавливая в максимальное значение инкрементируемую переменную.for (int i = 0; i < n; ++ i) {
for (int j = 0; j < n; ++ j) {
if (something (i, j))
i = n;
break;
}
}
Красиво, но фактически это тоже костыль, может быть даже похлеще goto, потому что всё равно оно вернётся и оценит i < 0 и только потом выйдет из цикла.
> может быть даже похлеще gotoда мне и for не нужен будет если я буду использовать goto :)
А потом узнаете про промахи кэша при таких выходах, и что вложенные циклы вообще не нужны, нисколько, никогда.
> и что вложенные циклы вообще не нужны, нисколько, никогда.ну это что такое?
Несерьёзно, выкинь это!
> Несерьёзно, выкинь это!а ну да, я должен там лонг джамп запилить.
Блин, ну, если честно, то эта муть вообще не читабельна. Единственный нормальный способ, который до этого был, - это goto.
Будь сам тимлидом и устанавливай свои правила)
> По логике меток, вы возвращаетесь и начинаете циклы заново, а не выходите из него вовсе.При чём здесь логика меток? Это логика оператора break.
> С goto куда [более] интуитивно
лол, какая разница, что "интуитивно"? Интуитивность важна для того, кто только-только начал писать на языке программрования. Те же кто набрал опыта имеют интуицию заточенную под язык, и всё что язык делает и то как он это делает для них будет интуитивным. Язык порождает интуицию, а не интуиция язык.
> for () { } : for-end-identifier;
Кек, а вот это меня в C раздражает как раз. __attribute__ которые добавляются после типа, а не перед его декларацией, чтобы я мог сразу видеть это. Или вот эти typedef struct {...} name_of_type;. Если я разглядываю декларацию типа, то самое важное что мне надо знать -- это имя типа и "тип типа" (структура, инум, юнион, функция, или что?), но тут имя отправляется в конец. Почему они слово struct не решили перенести в конец, мне совсем неясно. Но это было бы логичнее, можно было бы просто сорцы читать с конца в начало.
> При чём здесь логика меток? Это логика оператора break.потому-что запись вида end: это метка в том же самом C для оператора goto. И изменение логики break лишь в том, что к ней теперь добавляется так называемый идентификатор цикла, который необходимо прервать. А этот идентификатор приписывается к оператору for в виде:
for-end-identifier:
for (int i = 0; i < n; ++ i) {
}и эта запись ничем не отлична от метки goto. break на такой метке теперь должен остановить цикл, а goto начать его заново. А что если:
for-end-identifier1:
for (int i = 0; i < n; ++ i) {
}for-end-identifier2:
for (int i = 0; i < n; ++ i) {
break for-end-identifier1;
}Такое возможно? думаю нет, и break-у нужно понимать в каких for-ах он вложен. А значит "метка" есть явный идентификатор оператора for, и оператором goto к ней не перейти.
> лол, какая разница, что "интуитивно"?
Ну какая разница между головой и ж*пой?
> Интуитивность важна для того, кто только-только начал писать на языке программрования.
ну да, какая разница между войной и спецоперацией?
> Язык порождает интуицию, а не интуиция язык.
ну да язык - отражение культуры, особенно когда его придумал немец.
Соглашусь только с одним, что тут вопрос "о палке", какой из концов считать началом, и интуиции каждого и "спорщиков" будет говорить лишь об одном - "тот конец начало, который ближе ко мне!".
Если бы for переписать вот так:
{
break identifier;
} identifier for (int i = 0; i < n; ++ i);было бы куда интуитивно, а нет, "палка" говорит, что начало оператора должно быть ближе к "верху".
А вот "вторая - закрывающая" скобка } - это и есть конец тела цикла, и куда вам интуиция подсказывает приписать идентификатор? А с другой стороны, идентификатор это ведь "имя собственное" его надо в начало приписывать ведь надо - "величать" :)
> Кек, а вот это меня в C раздражает как раз. __attribute__ которые добавляются после типа, а не перед его декларацией, чтобы я мог сразу видеть это.
Я вообще сторонник идеи не отсоединять идентификатор от типа, не писать
int a,b;
a = 1;
b = 2;а писать переменные с типом сразу.
int_a = 1;
int_b = 2;type_identifier = value;
и в любом месте где читается текст программы видно, что эта переменная типа int, для статически типизированных ЯП.
> Или вот эти typedef struct {...} name_of_type;. Если я разглядываю декларацию типа, то самое важное что мне надо знать -- это имя типа и "тип типа" (структура, инум, юнион, функция, или что?), но тут имя отправляется в конец.
потому-что "имя" это identifier и он идет после "типа" как в случае int a, type identifier;
А ваш struct (union и т.д.) это и есть тот самый "тип" - составной тип, который описан в {}. Тут все интуитивно, потому-что сохранена логика type identifier;
Да не удобно, соглашусь, но опять таки, логика не нарушена.
А вот математики делают на оборот, сначала идентификатор пишут, а потом тип :)Удобно было бы вам вот так?
typedef name_of_type : struct {...};
typedef name_of_type : union {...};
typedef name_of_type : enum {...};:)
> Почему они слово struct не решили перенести в конец, мне совсем неясно. Но это было бы логичнее, можно было бы просто сорцы читать с конца в начало.
Ну вот я читаю код и дохожу до:
break for-end;
и идя вниз нахожу
} for-end;
и понимаю, что этот брек сюда указывает, и продолжаю читать дальше вниз - логично?
пс: есть практика оставлять комментарий после }, чтобы ясно было к какому циклу она относится :)
for ()
{
for ()
{
} // 2
} // 1
> Это логика оператора break.Есть ещё continue. А вообще этот синтаксис меток для for из языка Perl взят, которому уже почти 30 лет)
Они из Perl этот синтаксис стянули. В Perl именно так. И там это чуть ли не с рождения языка, т.е. уже почти 30 лет) Удобно.
> Они из Perl этот синтаксис стянули.и в php давно он есть, ток там без явных меток на операторах, а тупо уровень вложенности.
В Perl метки для for именно так сделаны, как сейчас в GCC реализовали, один в один, т.е. полная копия. PHP намного моложе Perl'а.
> PHP намного моложе Perl'а.в пхп хренью не страдали и сделали правильно без меток.
break N; где N по дефолту равен 1.
//www.php.net/break
В Perl и сейчас в C++ сделали правильно. В PHP неправильно и очень опасно.
> В PHP неправильно и очень опасно.не вижу обоснования, могу предположить вот такое:
for () {
for () {
if () {
break 2;
}
}
}тут если менять местами for - ничего не меняется, мы же предполагаем выход именно из второго цикла в любом случае.
Но если вдруг добавить третий цикл "снаружи", то да возможно можем забыть 2 сменить на 3 и это не "опасно" если есть тесты, которые сразу выявят непредвиденный результат.
for () {
for () {
for () {
if () {
break 2;
}
}
}
}Но даже если "именовать" в таком случае циклы, то мы также можем забыть сменить метку в break на нужный for (внешний новый). Отсюда, что "именованные", что "пронумерованный" break равносильно "опасны" в данном понимании. Я просто не знаю, что вы имеете ввиду под понятием "опасно", тем более "очень опасно".
>Директива "#embed", предназначенная для встраивания в код~/.ssh/github
Вот Вы смеетесь, а эмбед это вообще чуть ли не самое крутое, что ввели в язык.
Понятно что можно всякое нехорошее с ним делать, но и крутые штуки, типа встраивания ресурсов в технодемки, делать тоже можно и нужно.
Чо не сделают, лишь бы xxd не использовать. Все бы им в комбайны превращать.
Что не сделают, лишь бы костыли не использовать.
Из-за этой xxd устанавливать Vim? А Vim - это сильно-сильно на любилеля.
К счастью самую полезную программу из пакета Vim обычно поставляют отдельно от всего остального.
Нехорошее можно и без embed сделать. Всё, что делается embed'ом можно сделать и без него. Можно например вызвать из Makefile утилиту, которая сделает из содержимого /home объектный файл или сишный сорец, а потом прилинковать это к проекту. Делов-то.Либо ты доверяешь сорцам и их системе сборки, либо не доверяешь им и каким-то образом огораживаешься от возможных атак. #embed в этом ничего не меняет.
До этого это делалось скриптом линкера.
ld-скрипты это наверное лучший способ, так как должно быть куда быстрее, чем xxd. Анон выше забыл, что большой бинарник им не соберёшь -- компилятор будет вечно парсить жирный сгенеренный массив.Но все же хорошо что есть теперь способ стандартный, который рано или поздно (хотя темпы в этом плане у сишечки неторопливые) доберется до всех.
> компилятор для языка COBOLОчень актуальное, а главное своевременно решение. П.С. А кто-то видел живьём вообще этот КОБОЛ? А то рассказывают про банки и прочий энтерпрайз, но кого не спросишь, делают выпученные глаза.
> А кто-то видел живьём вообще этот КОБОЛ?Нет
Да, видел живьём Fico Blaze Advisor в отечественном банке.
А что то от этого изменится?
Пойдите на работу в банк и прочий энтерпрайз, увидите… а, для этого кобол для начала надо изучить.
> Пойдите на работу в банк и прочий энтерпрайз, увидите…Это я удачно зашёл. Докладываю вам из глубин банков и прочих ынтерпрайзов... вижу java, кое-где c# и даже go, но не cobol. Лол.
В РФ? Тут, к счастью, такого слоя легаси не успело нарасти (за неимением самих банков).
SAP ABAP это кобол. Правда, не гну.
> SAPТак оно мертво уже лет 10 как. Разве нет?
В каком месте оно мертво?Далее в России он конкурирует с 1С, а в мире его доля местами до 80% доходит.
В Мосэнерго уже заместили SAP ?
SAP - это громадный, тухлый монстр. Вместо помощи бизнесу, наоборот - перекорёживает всё под себя. Оно мне надо?? SAP - это как и кобол, древний реликт, который выкинут с радостью, как только напишут замену.
В Австралии уже попробовали написать замену.
> SAPОдна из моих girlfriends потеряла работу во времена ковида, хотя очень неплохой спец по SAP. Новую работу так и не нашла. В итоге пошла в курьеры. Так что да, протухло и уже не актуально. Особенно теперь в России.
>А кто-то видел живьём вообще этот КОБОЛ?Вот вам свежачёк-с https://github.com/meyfa/CobolCraft
Cobol в Tiobe на 20-м месте, даже поднимается
Деды умирают, им ищут замену. Вот и поднимается.
> Cobol в Tiobe на 20-м месте, даже поднимаетсяДа у него прям ренессанс какой-то попер, динозавры на переходе решили заспорить с лысыми потомками обезьян на тему вымирающих видов :)
>> Возможность объявления переменных в операторе "if", например, "if (int x = get ()) {...}".Ничего не понял это же прямо сейчас уже доступно нет??
https://godbolt.org/z/bPKqvsood в данном случае if это просто проверка либо на 0, либо можно использовать и для nulltpr.
Вы кинули код на C++, тогда как речь про Си.На Си такого синтаксиса нет.
Сейчас доступно в C++, а в статье речь о том, что это добавили в C.
Опять придется инструкции по сборке пакетов переписывать.
LFS ?
Как всегда в попсовых дистрах появится лет через 5?
В Дебиан 13 точно не попадет, потому что тулчейн для сборки, где GCC играет ключевую роль, заморожен от 15-го марта :)Будет в Дебиан 14, или более новая версия, если до заморозки успеет выйти 16-ая версия.
Не гентупроблемы ;)
Да-да. Справедливости ради, если нужен GCC 15, то всегда можно накатить в контейнер и не париться.
Да можно и ручками собрать и установить в какое-нибудь отдельное место /usr/local/gcc
> Да можно и ручками собратьНе-не, это уже какое-то извращение)
Imagine building an app from sources in 2025, smh smh
А как же исходники ? Ведь весь смысл открытого кода в них. Зачем они, если из них не собирать ?)))
В контейнере и в системе - это как бы совсем разные истории.
В контейнере у тебя какая операционка? ;)
В Fedora 42 уже есть
□ Атрибут "unsequenced", сигнализирующий, что результат не зависит от порядка выполнения.
□ Атрибут "reproducible", указывающий, что функция всегда возвращает один и тот же результат при одинаковых входных данных, т.е. не зависит от иных факторов.
□ Возможность объявления переменных в операторе "if", например, "if (int x = get ()) {...}".
□ Поддержка присвоения имён циклам для того, чтобы ссылаться на них в коде.Гляжу на всё это и понимаю, что видел это в Nim. Авторы языка используют все конструкции из новых стандартов Си.
> Гляжу на всё это и понимаю, что видел это в Nim. Авторы
> языка используют все конструкции из новых стандартов Си.Только сам он - какой-то ужастик, типа помеси сишки с питоном, очень сомнительное счастье.
у автора nim больше гибкости в этом плане, он пилит архитектуру и код практически в одно лицо
> Директива "#embed", предназначенная для встраивания в код бинарных ресурсов.Вот это хорошо, наконец можно будет забить на костыли и подпорки для вещей типа включения фонта в бинарь.
А гнутое расширение case 1..5 и проч они не хотят в новый стандарт взять?
Действительно, теперь ещё линуксовые бинари деблобировать из-за всяких утаистов (вероятно, нарушающих лицензии).
> Действительно, теперь ещё линуксовые бинари деблобировать из-за всяких утаистов (вероятно, нарушающих лицензии).когда из всей фразы понял только "гну"
> Действительно, теперь ещё линуксовые бинари деблобировать из-за всяких утаистов
> (вероятно, нарушающих лицензии).Это удобно для всяких инклудов допустим фонтов и прочих картинок в допустим бутлоадер/ядро/фирмвар. А деблоб фонта вы конечно можете себе сделать, только не понятно как вы читать что-то будете.
> Поддержка указания диапазонов целых значений в выражениях "case", например, "case 1 ... 10:".
Встраиваемые бинарные ресурсы давным давно были на винде
> Встраиваемые бинарные ресурсы давным давно были на винде1) Если это про ms resource compiler - то это несколько другое. И таки - не сишка.
2) Ну и как мне ваша винда поможет заинклюдить вон тот фонт на вот этом микроконтроллере чтобы вот тут на LCD текст выдать? А вот это - очень даже. Это конечно и без #embed делали, но требовало всяких левых конверторов, генераторов, усложнения процедуры билда и проч. А теперь будет - с полоборота.И если мы о винде, как там у мерзкософта, поддержку C23 они уже запилили в свой выюжалбэйсикстудил? Или у них так до сих пор C99 обкоцаный? А может у них уже и C2Y есть? Как у сабжей? Не, не завезли? :)
import std; для с++ все ещё не завезли или я чего-то упускаю?
В каком смысле "завезли"? Его что, нельзя было писать в коде??
можно, но только в комментариях. или в коде на python/nim
В общем тенденция такова: какой-нибудь С50 (вопреки всем обещаниям!) начнёт таки всё больше и больше превращаться в С++, в то время как С++50 начнёт всё больше и больше превращаться в Раст. В общем делайте выводы сами!
>какой-нибудь С50 (вопреки всем обещаниям!) начнёт таки всё больше и больше превращаться в С++Скорее в golang. Встраивание бинарных ресурсов, объявление переменных при if-операторе, defer, etc.
Встраиваемые бинарные ресурсы давным давно были на винде в Visual C
> Скорее в golang. Встраивание бинарных ресурсов, объявление переменных при if-операторе,
> defer, etc.Golang из C автор lwan.ws уже и сегодня запилил. Потому что может. Вот прям с корутинами и гламурным апи вебсервака тоже умещающимся на полстранички.
Только потом в отличие от игогошки еще призовые места в тематичных бенчах берет.
ну так проги на го читаются с диска уже после того, как проги на плюсах отрабатывают
> ну так проги на го читаются с диска уже после того, как
> проги на плюсах отрабатываютВеб серверу это не очень актуально, но у в отличие от игого - бинарник менее 150 кил, супербыстрый, зависимостей мизер, а примеры в комплекте - не только hello world но и вполне жизненные штуки, типа чата на вебсокетах, реализации freegeoip базы (с лимитами лукапов!) или даже какой-то "тематический" апсерверный бенч работы с базой (скулайт) где оно всех радостно подвинуло. Так что теперь на си можно не хуже игого микросерфисы делать, если этого хотелось.
Уже сделали - Rust ненужен.
> Rust ненуженНужен пока не избавятся от undefined behavior.
C должен превращаться в C++ только в compile-time и с контролируемым растолстеванием результирующего бинарика.Так было всегда и именно поэтому всё так медленно развивается.
уже можно начинать читать учебники по 23 плюсам, или всё ещё половина стандарта не поддерживается?вроде страничку с поддержкой они обновили, и про попоболь с import std там ни слова
да какой там 23, они 20 ещё полностью не реализовали! Полностью реализован только 17 стандрат
и то вроде только в clang полность реализован 17 стандарт, в gcc даже он не полностью реализован!!!
нет, не реализован, и шланг ничем в этом плане остальные компиляторы не опережает, разве что сильно отстаёт от gcc
> нет, не реализован, и шланг ничем в этом плане остальные компиляторы не
> опережает, разве что сильно отстаёт от gcc
> https://en.cppreference.com/w/cpp/compiler_support/17Да вроде там все более-менее в пределах погрешности ок? Лагает stdlib - но кто им вообще у шланга пользуется? Все тягают glibc и stdlibc++ от гну.
Читаешь все это безобразие и понимаешь, какая же С/С++ мощь. Не для средних умов!
>> какая же С/С++ мощь <<Такая мощь, что сам создатель С++ начал плакать о том, что на С++ осуществляются какие-то таи нападки и его срочно нужно защитить:)
а под via c7 он оптимизировать код умеет?
Даже под C3 умеет (14 версия, по крайней мере).
под c3 не умеет. вернее совсем не может, потому что у c3 нет cmov комманд, а они эти cmov комманды во всех либах есть, и полученный код на c3 крашится при запуске. ни один современный линукс по этому на c3 стартонуть не может.
Это как бы само собой подразумевается, что либы пересобирать придётся.
это так умрешь раньшt, чем столько всего самому пересобирать.
Это ж не Хром собирать. Ну и делать это, естественно, не на машине с C7.
Не хочется собирать — пишите без рантайма, делов-то)
Простите, но такая оптимизация как мёртвому припарки. Для старого железа - старый софт.
А новый софт под него совсем-совсем нельзя писать?
Пиши на старых инструментах типа Delphi 7.
А этот VIA C7 лучше C2D ?
Смотря под какие задачи. Под некоторые мои - да.
у него криптопроцессор офигительный. у c2d такого нету.
А он там того, без задних дверей? Китайская таварись маойра, всё-таки.
двери эти старые, узкие. много через них не просунется. да и нечего особо, чтоб им там интересно было.
C2D просто за счёт вычислительной мощности будет примерно на том же уровне.
> C2D просто за счёт вычислительной мощностиЗвучит как отголосок из далёкого 2007 года. Вы часом не разморожены?
А на фига такое ?
а вот надо!
C++23 эт хорошо. Но когда уже доделают С++20?
конкретно что не работает из C++20 ?
Модули?
>Фронтэнд для языка D обновлён до версии 2.111.0.А что там с Гошкой, какой версии эталонного сейчас (GCC 15.1) соответствует gccgo?
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgo/VERSION;h=...[gcc.git] / libgo / VERSION
1 go1.18Гугль уже давно не развивает gccgo и goLLVM
Когда читаешь нововведения, думаешь: где-то я уже это видел! Причём лет 30 назад. Вопрос: насколько надо быть тугодумами, чтобы вносить полезные вещи ДЕСЯТИЛЕТИЯМИ? Ладно бы отрасль была новая, неизученная (как ИТ в 70-ые). Но уже лет 20 как устоялись многие тенденции, куча языков протухла как раз по причине несоответствия запросам отрасли. И вот просыпается С++ комитет (кто-то б3днул слишком громко) и начинается вспоминание всех полезняшек из 80-ых :)) ПОЗДНО, дедушки, боржоми уже не поможет! На глиняном фундаменте С++ вы городите эйфелевку - так не пойдёт.Кто молодцы, так это создатели D - всё переосмыслили и выкатили нормальный язык. Вот на его базе уже можно что-то там расширять, улучшать... главное - ядро языка - адекватное.
Ну и пиши на нем, зачем кресты поминаешь.. подозрительный комент
Создатели ди большие поклонники додиеза. Публика не оценила: там, где додиез пойдёт, уже есть додиез.