The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Релиз набора компиляторов LLVM 22"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз набора компиляторов LLVM 22"  +/
Сообщение от opennews (??), 02-Мрт-26, 12:22 
После шести месяцев разработки представлен релиз проекта LLVM 22.1.0, развивающего инструментарий (компиляторы, оптимизаторы и генераторы кода), компилирующий программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован в машинный код для заданной целевой платформы или использован  JIT-компилятором для формирования машинных инструкций непосредственно во время выполнения программы. На базе технологий LLVM проектом развивается компилятор Clang, поддерживающий языки программирования  C, C++ и  Objective-C. Начиная с ветки 18.x проект перешёл на новую схему формирования номеров версий, в соответствии с которой нулевой выпуск ("N.0") используется в процессе разработки, а первая стабильная версия снабжается номером "N.1"...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=64898

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


4. "Релиз набора компиляторов LLVM 22"  +2 +/
Сообщение от Карлос Сношайтилис (ok), 02-Мрт-26, 12:27 
> Возможности, связанные с языком С: Реализован черновик спецификации, определяющей механизм отложенного выполнения "defer"

Если вы не идёте к RAII, RAII идёт к вам

Ответить | Правка | Наверх | Cообщить модератору

34. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (34), 02-Мрт-26, 14:42 
Давно пора. Только вот зачем они сделали эту фичу как control block, а не как декларацию с полноценными лямбда-функциями, мне не понятно. Так придётся колхозить замыкания, если надо захватывать значения переменных на этапе defer, что часто бывает нужно. И теперь даже если потом добавят лямбды, с текущим defer они не совместимы. В общем, подложили лишние грабли и себе, и C++.
Ответить | Правка | Наверх | Cообщить модератору

48. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сладкая булочка (?), 02-Мрт-26, 15:36 
> Давно пора.

Давно уже есть в gcc и используется (например, в коде systemd). Надо просто стандартизовать.

Ответить | Правка | Наверх | Cообщить модератору

61. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (34), 02-Мрт-26, 16:20 
Вот они и стандартизировали. Только не то.
Ответить | Правка | Наверх | Cообщить модератору

99. "Релиз набора компиляторов LLVM 22"  –1 +/
Сообщение от Аноним (99), 02-Мрт-26, 19:15 
> Давно пора.

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

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

106. Скрыто модератором  +/
Сообщение от Аноним (34), 02-Мрт-26, 19:29 
Ответить | Правка | Наверх | Cообщить модератору

138. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от sage (??), 02-Мрт-26, 22:15 
Это буквально как в Go.
Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

47. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сладкая булочка (?), 02-Мрт-26, 15:35 
> Если вы не идёте к RAII, RAII идёт к вам

Только defer - это не RAII.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

55. "Релиз набора компиляторов LLVM 22"  –2 +/
Сообщение от Аноним (34), 02-Мрт-26, 16:05 
Сделано главным образом именно для RAII.
Ответить | Правка | Наверх | Cообщить модератору

79. "Релиз набора компиляторов LLVM 22"  –1 +/
Сообщение от Аноним (79), 02-Мрт-26, 18:09 
Сделано чтобы нейросети писать сразу на LLVM.
Ответить | Правка | Наверх | Cообщить модератору

116. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Бертолетова соль (?), 02-Мрт-26, 20:08 
Вот бы сразу на Астме
Ответить | Правка | Наверх | Cообщить модератору

58. "Релиз набора компиляторов LLVM 22"  –3 +/
Сообщение от Аноним (58), 02-Мрт-26, 16:11 
> Только defer - это не RAII.

Конечно.
Только defer - это недо RAII.

Но в копролитный язык из прошлого века не могут добавить сразу нормально.
Пользователи не поймут. В прямом смысле.
У них мозг атрофировался еще во времена С89.

А тут такие изменения!
Они еще только-только пережили добавление keywordʼа bool.

А тут в С26 на горизонте маячит is_within_lifetime.
Прикинь! Лайфтаймы в СИшке!
Половина дидов просто сопьется от такого напряжения межушного ганглия.

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

64. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от Аноним (64), 02-Мрт-26, 16:38 
> А тут в С26 на горизонте маячит is_within_lifetime
> Прикинь! Лайфтаймы в СИшке!

Это у тебя что-то с межушным ганглием. is_within_lifetime - это про C++.

Ответить | Правка | Наверх | Cообщить модератору

65. "Релиз набора компиляторов LLVM 22"  –1 +/
Сообщение от Аноним (65), 02-Мрт-26, 16:49 
> is_within_lifetime - это про C++.

Ты все испортил! (с)

Я тут СИшников пугаю, а ты всё портишь!!
defer тоже было "про С++", а тут вот как оберрнулось.
Они запросто поверят и в лайфтаймы.


Ответить | Правка | Наверх | Cообщить модератору

71. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (71), 02-Мрт-26, 17:36 
>Половина дидов просто сопьется от такого напряжения межушного ганглия.

Я весь такой красивый, молодой и модный. Пишу на Си. Дедов никогда не видел. Может они где-то есть в Интернете?

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

76. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (76), 02-Мрт-26, 18:05 
Локальный мем как и hdr.
Ответить | Правка | Наверх | Cообщить модератору

159. Скрыто модератором  +/
Сообщение от анон (?), 03-Мрт-26, 04:16 
Ответить | Правка | Наверх | Cообщить модератору

92. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Анончик давай выпьем чаю. Анончик выручай. (?), 02-Мрт-26, 18:56 
> Половина дидов просто сопьется от такого напряжения межушного ганглия.

Я весь такой красивый, молодой и модный. Пишу на Си. Дедов никогда не видел. Может они где-то есть в Интернете?

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

101. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сладкая булочка (?), 02-Мрт-26, 19:18 
>> Только defer - это не RAII.
> Конечно.
> Только defer - это недо RAII.
> Но в копролитный язык из прошлого века не могут добавить сразу нормально.
> Пользователи не поймут. В прямом смысле.
> У них мозг атрофировался еще во времена С89.

В gcc уже давно есть и используется в проектах.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

102. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сладкая булочка (?), 02-Мрт-26, 19:20 
>> Только defer - это не RAII.
> А тут в С26 на горизонте маячит is_within_lifetime.

Путать С26 c C++26 - это талант.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

5. "Релиз набора компиляторов LLVM 22"  –8 +/
Сообщение от Аноним (5), 02-Мрт-26, 12:35 
Какой ещё ARM? Только ASML, только x64!
Ответить | Правка | Наверх | Cообщить модератору

11. "Релиз набора компиляторов LLVM 22"  +2 +/
Сообщение от Аноним (11), 02-Мрт-26, 13:15 
Чего ?
ARM это архитектура, а ASML делают литографы, которые потом покупает например TSMC и производит процессоры для Qualcomm или Apple.
p.s.:
- https://cdn.videocardz.com/1/2026/02/QUALCOMM-SNAPDRAGON-X2-...
- https://cdn.videocardz.com/1/2026/02/QUALCOMM-SNAPDRAGON-X2-...
Ответить | Правка | Наверх | Cообщить модератору

90. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (99), 02-Мрт-26, 18:53 
А, точно. Вот так правильно:
Какой ещё ARM? Только TSMC, только x64!
Ответить | Правка | Наверх | Cообщить модератору

6. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (6), 02-Мрт-26, 12:46 
Как ставить-то?
Ответить | Правка | Наверх | Cообщить модератору

9. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от dannyD (?), 02-Мрт-26, 13:12 
В генту уже доступен.
Ответить | Правка | Наверх | Cообщить модератору

29. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от злой_ой (?), 02-Мрт-26, 14:22 
как всегда машина времени:

$ cat /usr/ports/devel/llvm22/Makefile | grep ^DISTVERSION
DISTVERSION=    22.1.0
$ ls -la /usr/ports/devel/llvm22/Makefile
-rw-r--r--  1 root wheel 25902 26 Feb 21:47 /usr/ports/devel/llvm22/Makefile
$ ls -la /usr/ports/devel/llvm22/distinfo
-rw-r--r--  1 root wheel 180 26 Feb 21:47 /usr/ports/devel/llvm22/distinfo

Ответить | Правка | Наверх | Cообщить модератору

40. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (40), 02-Мрт-26, 15:02 
google + uuoc
Ответить | Правка | Наверх | Cообщить модератору

42. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (42), 02-Мрт-26, 15:08 
Ты портопомойку сравниваешь с main tree. Не надо так.
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

24. "Релиз набора компиляторов LLVM 22"  –1 +/
Сообщение от Аноним (42), 02-Мрт-26, 14:08 
Не спеши, может, компиляцию хрома опять сломали. Раст, опять же, к осени ждать только.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

7. "Релиз набора компиляторов LLVM 22"  –7 +/
Сообщение от Аноним (7), 02-Мрт-26, 12:57 
>поддержка именованных циклов

у раста подсмотрели)
https://doc.rust-lang.org/std/keyword.break.html

Ответить | Правка | Наверх | Cообщить модератору

10. "Релиз набора компиляторов LLVM 22"  +2 +/
Сообщение от Аноним (10), 02-Мрт-26, 13:13 
Технологии языков прошлого века, когда родителей раста ещё не было в планах.
Ответить | Правка | Наверх | Cообщить модератору

15. "Релиз набора компиляторов LLVM 22"  –3 +/
Сообщение от нах.. (?), 02-Мрт-26, 13:43 
Но подсмотрели то у Раста)
Ответить | Правка | Наверх | Cообщить модератору

27. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (34), 02-Мрт-26, 14:20 
На самом деле, эти идеи далеко не новы и обсуждались задолго до Раста. И у конкретно этого решения с метками есть свои минусы и противники, как и у альтернатив. Поэтому долго не стандартизировали. Видимо, просто плюнули и решили, что что-то - лучше, чем ничего.
Ответить | Правка | Наверх | Cообщить модератору

30. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от злой_ой (?), 02-Мрт-26, 14:27 
подсмотрели метки? у раста?

man perlsyn
/LABEL

уже и не вспомнить, с каких пор там оно.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

140. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от windowlicker (?), 02-Мрт-26, 23:02 
Какая разница? Подсмотрели то у Раста)
Ответить | Правка | Наверх | Cообщить модератору

38. "Релиз набора компиляторов LLVM 22"  +2 +/
Сообщение от Vindex (?), 02-Мрт-26, 15:00 
Эта фишка была в D ещё задолго до появления Rust
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

141. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от windowlicker (?), 02-Мрт-26, 23:03 
Но тем не менее подсмотрели не у D, а у Раста)
Ответить | Правка | Наверх | Cообщить модератору

59. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от Карлос Сношайтилис (ok), 02-Мрт-26, 16:16 
Так и не раст это придумал, а взял из "языков прошлого века".
А вот влили, потому что раст популИзировал
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

73. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (73), 02-Мрт-26, 17:45 
>у раста подсмотрели)

Не знаю, по крайней мере в чистой сишке этой гадости нет. А вот компилятор Раста делается на основе LLVM. Нет LLVM - нет rustc.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

139. Скрыто модератором  +/
Сообщение от анон (?), 02-Мрт-26, 22:48 
Ответить | Правка | Наверх | Cообщить модератору

8. "Релиз набора компиляторов LLVM 22"  +4 +/
Сообщение от Аноним (-), 02-Мрт-26, 12:58 
> Добавлена поддержка именованных циклов, позволяющих присваивать имена циклам и оператору switch, которые можно указывать в операторах break и continue для явного определения цикла, из которого производится выход.

Что только не придумают, лишь бы goto не использовать.

Ответить | Правка | Наверх | Cообщить модератору

77. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от нах. (?), 02-Мрт-26, 18:07 
причем придумка - всем хуже просто использования goto. (например семантика break LABEL получается совершенно контринтуитивной и еще ищи там в дветыщипятой строке закрывающую скобочку)
покусанные дейкстрой по прежнему героически борются с устройством компьютера, пожелаем им сдохнуть в муках.
Ответить | Правка | Наверх | Cообщить модератору

157. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (64), 03-Мрт-26, 01:54 
> покусанные дейкстрой по прежнему героически борются с устройством компьютера

Блин, лучше и не скажешь, все так.

Ответить | Правка | Наверх | Cообщить модератору

12. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сусанин (?), 02-Мрт-26, 13:28 
> Добавлена поддержка именованных циклов, позволяющих присваивать имена циклам...

Наконец-то сподобились перетащить это из Perl, в котором это уже десятки лет есть ровно с таким же синтаксисом.

Ответить | Правка | Наверх | Cообщить модератору

16. "Релиз набора компиляторов LLVM 22"  –4 +/
Сообщение от windowlicker (?), 02-Мрт-26, 13:44 
Из Раста же
Ответить | Правка | Наверх | Cообщить модератору

18. "Релиз набора компиляторов LLVM 22"  +4 +/
Сообщение от Аноним (18), 02-Мрт-26, 13:59 
Из чего? Это которые в разноцветных шапочках и из ямайки? Они тут причем?
Ответить | Правка | Наверх | Cообщить модератору

22. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (22), 02-Мрт-26, 14:06 
Из Фортрана же
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

21. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (21), 02-Мрт-26, 14:02 
GOTO ещё не перетащили?
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

25. "Релиз набора компиляторов LLVM 22"  –2 +/
Сообщение от Аноним (-), 02-Мрт-26, 14:10 
> GOTO ещё не перетащили?

Пф. зачем перетаскивать технологию устаревщую на десятилетия?
Это же пример убогого овнокода дидов.


Ответить | Правка | Наверх | Cообщить модератору

39. "Релиз набора компиляторов LLVM 22"  +3 +/
Сообщение от Аноним (34), 02-Мрт-26, 15:00 
Эта "устаревшая" технология с успехом решает все задачи на неё возложенные. И кстати, в конкретно этом случае с именованными циклами, польза последних по сравнению с имеющимся goto довольно сомнительна. Наверно, сделали для альтернативно одаренных с фобией goto.
Ответить | Правка | Наверх | Cообщить модератору

125. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (125), 02-Мрт-26, 20:32 
> Эта "устаревшая" технология с успехом решает все задачи на неё возложенные

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

Ответить | Правка | Наверх | Cообщить модератору

156. "Релиз набора компиляторов LLVM 22"  +2 +/
Сообщение от Аноним (64), 03-Мрт-26, 01:40 
Как бы тебе объяснить то чтоб ты уже наконец понял. Сишка это системный язык программирования для написания драйверов, ядер ОС, прошивок для МК и тд. Не нужны там эти ваши километры DWARF-лапши в бинарях. Да - простой goto, который транслируется в какой-нить JMP в x86 - это круто и достаточно. Целое ядро на миллионы строк кода так написано.
Ответить | Правка | Наверх | Cообщить модератору

128. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (128), 02-Мрт-26, 21:06 
https://graydon2.dreamwidth.org/218040.html

>things rust shipped without:
>* goto (not even as a reserved word)

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

14. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (14), 02-Мрт-26, 13:40 
Заголовок "Релиз набора компиляторов LLVM 22"
Портянка "Среди улучшений в Clang 22"

Так а в LLVM что-то изменили?

Ответить | Правка | Наверх | Cообщить модератору

17. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (17), 02-Мрт-26, 13:45 
Во-первых, clang - часть llvm, поэтому то что изменили в clang то изменили в llvm. Во-вторых, читай новость целиком.
Ответить | Правка | Наверх | Cообщить модератору

20. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (20), 02-Мрт-26, 14:00 
привет, goto, давно не виделись
Ответить | Правка | Наверх | Cообщить модератору

23. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (64), 02-Мрт-26, 14:08 
Это ж любимая С++ная программа всех любителей раста.
Ответить | Правка | Наверх | Cообщить модератору

49. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сладкая булочка (?), 02-Мрт-26, 15:39 
Среднестатистический пользователь раста туда вряд ли заглядывает.
Ответить | Правка | Наверх | Cообщить модератору

26. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (26), 02-Мрт-26, 14:10 
> операторы сравнения "<", ">", "<=" и ">=" синтезированы из оператора "<=>"

а это вообще что? как? куда? а главное — зачем?

Ответить | Правка | Наверх | Cообщить модератору

31. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (34), 02-Мрт-26, 14:31 
Это позволяет определить, сгенерирован ли оператор компилятором на основе operator<=> (фича C++20) или определён пользователем.

https://godbolt.org/z/YcG1jTv8Y

"Зачем" - не знаю, но видимо есть какие-то случаи, когда это может пригодиться.

Ответить | Правка | Наверх | Cообщить модератору

107. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сладкая булочка (?), 02-Мрт-26, 19:32 
>> операторы сравнения "<", ">", "<=" и ">=" синтезированы из оператора "<=>"
> а это вообще что? как? куда? а главное — зачем?

Очевидно, что "<=>" - изображение летающий тарелки. Вот прилетят они и увидят, что ты их уважаешь.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

33. "Релиз набора компиляторов LLVM 22"  –5 +/
Сообщение от Аноним (33), 02-Мрт-26, 14:38 
обязательно было вот это Г делать явным?

outer:
   for (int i = 0; i < IK; ++ i) {
     for (int j = 0; j < JK; ++ j) {
        continue;       // переход к CONT1
        continue outer; // переход к CONT2
        // CONT1
     }
     // CONT2
   }

В пхп давно оно неявное, достаточно указать номер уровня вложенности continue 2;

Ответить | Правка | Наверх | Cообщить модератору

35. "Релиз набора компиляторов LLVM 22"  +3 +/
Сообщение от Аноним (34), 02-Мрт-26, 14:46 
Ну да, а потом иди считай, куда твой break или continue на самом деле переходит. Заняться нечем?

С метками тоже переходит не туда, где метка (и это косяк этого решения), но по крайней мере визуально видно о каком цикле речь. К тому же, метку можно назвать как угодно.

Ответить | Правка | Наверх | Cообщить модератору

41. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от Аноним (33), 02-Мрт-26, 15:06 
> Заняться нечем?

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

> Ну да, а потом иди считай, куда твой break или continue на самом деле переходит.

А что, ты не должен после добавления нового уровня вложенности пересмотреть все свои условия для break и continue операторов? Или навалял и забыл? И ни на что не должно влиять ваше добавление? Добавил один уровень, ну вот какое значение стоит перед твоим continue, так к нему добавь +1, в чем проблема подсчета? А лучше бы пример привел бы, когда необходим именно именованный блок при добавления нового уровня вложенности.

> С метками тоже переходит не туда, где метка (и это косяк этого решения), но по крайней мере визуально видно о каком цикле речь.

всегда за всякими

    } // тут конец цикла
  } // вот тут конец условия а
} // ставили коментари

так же и с break и continue можно, не вижу проблемы.

continue 3; // for i
continue 2; // for j
continue 1; // for k

> К тому же, метку можно назвать как угодно.

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

Ответить | Правка | Наверх | Cообщить модератору

60. "Релиз набора компиляторов LLVM 22"  +2 +/
Сообщение от Аноним (34), 02-Мрт-26, 16:18 
> заняться не чем именно тем, кто мешает понятие меток с уровнем вложенности блочных операторов.

Да кому вообще он нужен, этот уровень вложенности? Важен не уровень вложенности а к какому именно циклу относится тот или иной break или continue. Я не должен считать количество вложенных циклов для этого.

> А что, ты не должен после добавления нового уровня вложенности пересмотреть все свои условия для break и continue операторов?

Чаще всего, нет, не должен. Т.к. часто внутренние циклы остаются корректными при добавлении внешних циклов. И хотелось бы, чтобы конструкции вроде "break отовсюду" оставались корректными и не требовали поддержки.

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

> так же и с break и continue можно, не вижу проблемы.
>
> continue 3; // for i
> continue 2; // for j
> continue 1; // for k

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

> если существует механизм меток и оператор безусловного перехода, тогда оператор цикла является избыточным.

Нет, т.к. оператор цикла предоаставляет дополнительное удобство, как то счетчик/итераторы, инкремент и проверку условия выхода. Всё это по-отдельности написать можно, но это будет более многословно и менее читабельно. Вот конкретно break/continue с меткой - тут уже более спорно, т.к. goto делает ровно то же самое и не хуже.

Ответить | Правка | Наверх | Cообщить модератору

67. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 17:31 
> Да кому вообще он нужен, этот уровень вложенности?

как кому, смысл вашего break и continue изменился, теперь он не оператор выхода из блока в котором он определен, а оператор выхода из произвольного (строго направленного вверх, наружу) вложенного уровня блоков. Break и continue это не оператор goto, который безусловно переходит по указанной метке.

Нельзя написать вот так:
outer:
   for (int i = 0; i < IK; ++ i) {
inner1:
     for (int j = 0; j < JK; ++ j) {
        continue inner2; // <------ недопустимо
     } // for-inner1
inner2:
     for (int k = 0; k < JK; ++ k) {
        continue outer; // переход к CONT2
        // CONT1
     } // for-inner2
   } // for-outer

> Чаще всего, нет, не должен.

ясно, дальше смысла обсуждать - нет.

> Т.к. часто внутренние циклы остаются корректными при добавлении внешних циклов.

Рассуждение из серии - а зачем использовать большую вложенность и т.д.

> И хотелось бы, чтобы конструкции вроде "break отовсюду" оставались корректными и не требовали поддержки.

Конструкции "break отовсюду" - неопределенная конструкция для компилятора. Поэтому придумали ЯВНЫЕ "метки-циклов", где можно было сделать неявные, потому-что эти метки уровня вложенности блоков циклов, а не метки в понимании оператора goto. Неявные метки циклов также не нуждаются в поддержке если вы добавляете внешний блок по отношению к операторам break и continue. Так же если вы добавите внутренний блок, ничего не изменится,  в поддержке нет необходимости если только сама логика выхода не изменится в вашей программе.

Было:

for (int i = 0; i < IK; ++ i) {
  for (int j = 0; j < JK; ++ j) {
    continue 2; // выход из цикла i
  }
}

Стало (добавляем внешний блок):

for (int k = 0; k < IK; ++ k) {
  for (int i = 0; i < IK; ++ i) {
    for (int j = 0; j < JK; ++ j) {
      continue 2; // выход из цикла i
    }
  }
}

Что тут надо поддерживать? я опять продолжаю выходить только из for (int i = 0; i < IK; ++ i). А если в таком случае вам нужно выходить уже из for (int k = 0; k < IK; ++ k), тогда это и есть изменение условий выхода, что требует изменения оператора continue на continue 3; Ровно такое же будет происходить и в случае с явными метками циклов.

Было:

outer:
for (int i = 0; i < IK; ++ i) {
  for (int j = 0; j < JK; ++ j) {
    continue outer; // выход из цикла i, по метке outer
  }
}

Стало:

for (int k = 0; k < IK; ++ k) {
outer:
  for (int i = 0; i < IK; ++ i) {
    for (int j = 0; j < JK; ++ j) {
      continue outer; // выход из цикла i, по метке outer
    }
  }
}

И тут ничего не надо менеджить, если только логика выхода не меняется. А если измениться, вам все равно надо переписать continue outer; и указать метку того цикла из которого необходимо выйти (пропустить, неважно). Вы скажите, что достаточно метку поднять выше, вот так:

outer:
for (int k = 0; k < IK; ++ k) {
  for (int i = 0; i < IK; ++ i) {
    for (int j = 0; j < JK; ++ j) {
      continue outer; // выход из цикла i, по метке outer
    }
  }
}

Да верно, но теперь эта метка относится к другому циклу, а там ниже по коду может есть необходимость выходить по метке именно 2 второго по вложенности цикла? и тут начнется мракобесие, в любом случае необходимость в пересмотре выходов останется, и код будет выглядеть так:

outer1:
for (int k = 0; k < IK; ++ k) {
outer2:
  for (int i = 0; i < IK; ++ i) {
outer3:  
    for (int j = 0; j < JK; ++ j) {
      continue outer1; // выход из цикла i, по метке outer1
    }
    continue outer2; // выход из цикла i, по метке outer2
  }
}

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

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

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

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

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

> Всё это по-отдельности написать можно, но это будет более многословно и менее читабельно.

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

> Вот конкретно break/continue с меткой - тут уже более спорно, т.к. goto делает ровно то же самое и не хуже.

goto не чистит за собой.

Ответить | Правка | Наверх | Cообщить модератору

82. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от Аноним (34), 02-Мрт-26, 18:24 
>> Да кому вообще он нужен, этот уровень вложенности?
>
> как кому, смысл вашего break и continue изменился, теперь он не оператор выхода из блока в котором он определен, а оператор выхода из произвольного (строго направленного вверх, наружу) вложенного уровня блоков. Break и continue это не оператор goto, который безусловно переходит по указанной метке.

В том-то и дело, что break/continue с меткой должен быть "почти" goto, с тем ограничением, что они работают не как произвольный переход, а в отношении цикла. Да, это переход строго наружу, но мне плевать на сколько уровней наружу, я задаю к какому циклу он относится, и всё.

>> Чаще всего, нет, не должен.
>
> ясно, дальше смысла обсуждать - нет.

Однако же, вы упорствуете.

>> Т.к. часто внутренние циклы остаются корректными при добавлении внешних циклов.
>
> Рассуждение из серии - а зачем использовать большую вложенность и т.д.

Нет, рассуждение из опыта и здравого смысла. Большинство циклов вполне себе закончены и самостоятельны, и не требуют модификации, если их обернуть в новые циклы. За исключением, конечно, конструкций вида "break отовсюду", он же "goto finish" и т.п.

> Что тут надо поддерживать?

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

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

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

> goto не чистит за собой.

Не знаю, что тут имеется ввиду, но если что, goto разрушает объекты, если этого требует переход. И defer тоже запускает.

Ответить | Правка | Наверх | Cообщить модератору

84. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 18:39 
> Блджать, я еще раз повторяю, считать по коду сколько циклов наверх мне нужно прыгнуть - это тупая и бесполезная работа.

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

label1:
for ()
{
label2:
  for ()
  {
label3:
     for ()
     {
label4:
       for ()
       {

..... продолжаю добавлять новые уровни вложенности

labelN:
         for ()
         {
             break M; // а вот тут мне также нужно пройтись наверх и найти метку чтобы приписать к этому брейку, я же не буду запоминать все имена меток всех циклов, я в любом случае иду искать "нужную" (диктуемой изначальной логикой программы) мне метку. И вы хотите сказать, что это не равносильно подсчету уровней вложенности? Равносильность даже синтаксически доказывается, просто за место label1 достаточно написать 1, за место label2 - 2 и т.д.

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

Ответить | Правка | Наверх | Cообщить модератору

93. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (34), 02-Мрт-26, 18:56 
> И вы хотите сказать, что это не равносильно подсчету уровней вложенности?

Нет, не равносильно. Потому что "break M" (где M - это метка) так и останется "break M" после добавления или уменьшения вложенности, и так и будет обозначать ровно то же, что и раньше - выход из внешнего цикла M. И когда я изначально буду писать "break M" мне не нужно смотреть весь верхний код и считать все внешние for и while.

А в хороших IDE вообще есть переход к метке по хоткею - это если надо увидеть сам цикл или цель goto.

Ответить | Правка | Наверх | Cообщить модератору

96. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 19:09 
> Нет, не равносильно. Потому что "break M" (где M - это метка)
> так и останется "break M" после добавления или уменьшения вложенности, и
> так и будет обозначать ровно то же, что и раньше -
> выход из внешнего цикла M. И когда я изначально буду писать
> "break M" мне не нужно смотреть весь верхний код и считать
> все внешние for и while.

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

> А в хороших IDE вообще есть переход к метке по хоткею -
> это если надо увидеть сам цикл или цель goto.

В том то и дело, посчитать уровень вложенности может любой редактор, и при написании break автокомплитом вам подсветит список вложенных вот таких строк:

for (int i = 0; i < JK; ++ i)
  for (int j = 0; j < JK; ++ j)
....
    for (int n = 0; n < JK; ++ n)

И при выборе соответствующего добавит номер уровня вложенности из которого надо выйти.

Ответить | Правка | Наверх | Cообщить модератору

105. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (34), 02-Мрт-26, 19:25 
> Я описал процесс изначального написания кода, и сделал акцент на "подсчитывать уровень вложенности", вы в любом случае будете идти вверх и искать ту самую метку.

Не буду я ничего искать. Если я пишу код, я помню метки и сразу напишу "break outer" и т.п. Да даже если я забуду метку, найти её сверху и скопировать гораздо проще, чем считать циклы.

> достаточно посмотреть на уровень предыдущего цикла (добавлением комментария

А комментарий протух или его нету.

> И при выборе соответствующего добавит номер уровня вложенности из которого надо выйти.

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

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

Ответить | Правка | Наверх | Cообщить модератору

112. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 19:55 
> Да даже если я забуду метку, найти её сверху и скопировать гораздо проще, чем считать циклы.

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

> А комментарий протух или его нету.

Ага а метка вечная такая "цикл_номер_1", ой добавился новый уровень вложенности, чет не красивое имя метки это же уже не "цикл_номер_1". Знаем, знаем, нейминг проблем, кемел кейс? или какие еще там кейсы нейминга? Мракобесие, не имеющее отношение к ЯП. Комментарии именно придумали для того, чтобы от этого мракобесия избавиться.

> Как она его добавит, если она не знает, куда надо выйти? С метками хотя бы автокомплит есть.

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

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

А "вы" (не вы лично) настолько поражены "синтаксическим диабетом", что мешаете ежа с ужом и пытаетесь натянуть как сову на глобус.

Повторяю, функции текстовых редакторов пихать в стандарты ЯП - НЕ НАДО!!!!!

> Вы бы попробовали поработать с проектиком средне-большого размера, особенно, написанного не вами, и прикинули, насколько удобно было бы вам тр@хаться с подсчетом циклов.

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

Всегда хорошим тоном было комментировать начала и концы блоков любых операторов.

if (A) // Условие А
{

}
else // иначе условия А
{

} // конец условия А

Даже если редактор при наведении на else не показывает подсказкой код условия "if (A)", то в комментарии хорошим тоном будет пихнуть весь код условия.

if (A) // Условие А
{
..... Тут код который не вмещается на целый экран и условие находится далеко вверху на 1000 строк.
}
else // иначе от - if (A) <----- продублировали код условия
{

} // конец условия А

Комментарии именно тот самый универсальный, полный свободы механизм не требующий никаких стандартов и изменений синтаксиса ЯП.

Ответить | Правка | Наверх | Cообщить модератору

124. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (34), 02-Мрт-26, 20:31 
> Ага а метка вечная такая "цикл_номер_1"

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

А может, вы и переменные называете var1, var2 и т.д.? Если так, то вопросов нет.

> в смысли как? как ваш парсер знает каков уровень вложенности циклов?

Вообще-то не знает, т.к. слава богу, пока что в C/C++ такой фигни нету. Но дело даже не в этом. Как ваша IDE подскажет, какое число поставить после break, если она не знает, откуда вы хотите выйти? Знаете вы сами, но сказать не можете, т.к. для этого надо посчитать циклы.

Опять же, с метками есть автокомплит, так что если я хоть примерно помню имя метки, IDE мне её подскажет.

> Всегда хорошим тоном было комментировать начала и концы блоков любых операторов.

Никогда такого хорошего тона не было.

> Даже если редактор при наведении на else не показывает подсказкой код условия "if (A)", то в комментарии хорошим тоном будет пихнуть весь код условия.

Нет, потому что такой комментарий протухнет еще быстрее. И это тупо дублирование кода.

Вы понятия не имеете, о чем говорите.

Ответить | Правка | Наверх | Cообщить модератору

129. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 21:12 
> А может, вы

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

> Как ваша IDE подскажет, какое число поставить после break, если она не знает, откуда вы хотите выйти?

как это она не знает? она не парсит мой код? она не знает про блоки и уровни вложенности? она по-блочно от моего break идет по дереву вверх и выводит каждое начало цикла в виде элемента списка. Каждый элемент имеет порядковый номер. Первый блок в которым находится break имеет порядок - 1 и т.д. наверх. Проблемы не вижу.

> Опять же, с метками есть автокомплит, так что если я хоть примерно помню имя метки, IDE мне её подскажет.

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

Ну смотрите из какого списка лучше выбирать из списка где указаны только одни имена меток или списка:

for (int i = 0; i < JK; ++ i)
  for (int j = 0; j < JK; ++ j)
....
    for (int n = 0; n < JK; ++ n)

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

> Никогда такого хорошего тона не было.

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

> Нет, потому что такой комментарий протухнет еще быстрее.

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

> И это тупо дублирование кода.

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

> Вы понятия не имеете, о чем говорите.

Пусть так и будет, вы продолжайте жонглировать и переписывать, таков путь всего формализма. Был такой Воеводский со своим HoTT, такое же мракобесие и в математике.

Ответить | Правка | Наверх | Cообщить модератору

103. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 19:21 
> (добавлением комментария, если этих уровней тысячи, если мы говорим за удобство читателю - то есть комментарии, дающие любую свободу, но не надо пихать всякую ерунду и переусложнять синтаксис ЯП)

и чем добавление комментария к

for () // Цикл уровня 1

отличается от вашей метки? да ничем. И спрашивается, зачем добавлять явные метки для циклов в ЯП? Уместна поговорка про кота, которому делать нечего.

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

108. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (34), 02-Мрт-26, 19:33 
> и чем добавление комментария к
>
> for () // Цикл уровня 1
>
> отличается от вашей метки? да ничем.

Вы серьёзно или троллите меня сейчас?

Отличается тем, что фиксирована и проверяется компилятором.

Ответить | Правка | Наверх | Cообщить модератору

115. "Релиз набора компиляторов LLVM 22"  –1 +/
Сообщение от Аноним (33), 02-Мрт-26, 20:07 
> Отличается тем, что фиксирована и проверяется компилятором.

а промах мимо уровня вложенности компилятором не фиксируется? Я не буду разве получать ошибку при break n; если уровень вложенности m и m < n? Ничего не изменилось. Я иду вверх по коду, чтобы найти имя метки? Ровно так же я иду по комментариям вверх чтобы найти тот уровень вложенности из которого я должен выйти, а в комментарии указан уровень.

А теперь фокус, добавил новый уровень вложенности и надо править все комментарии и заменить "уровень N" на "уровень N+1", ровно так же нужно править если у меня будут метки label1, label2, label3 ибо нелогичный нейминг будет, как и в случае именовании обычных переменных, когда PI = 4 :) вы от нейминг проблемы не избавились.

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

Ответить | Правка | Наверх | Cообщить модератору

123. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 20:29 
> Вы серьёзно или троллите меня сейчас?

Если по сути, то "вас" (всех) троллят - формалисты. ЯП - формальная система. Добавление любых избыточных конструкция "сокращений", таких операторов как for и break, приводят лишь к тому, что при изменении кода надо внимательно смотреть не заденет ли это изменение изменения ВСЕЙ логики программы. Отсюда, в ЯП достаточно было бы конструкции label, goto и оператор test для проверки условий, и тогда бы "мы" не выстрелили бы себе в ноги, а всегда бы перепроверяли бы логику программы после изменений. Одна только синтаксическая ерунда однострочных блоков не обрамленных в {} к каким идиотским ошибкам приводит.

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

94. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 19:00 
а теперь просто к этой конструкции именованных циклов добавьте внешний цикл с меткой и меняем логику выхода уже из этого цикла.

label0: // <----- добавили
  for ()
  {
label1:
    for ()
    {
....
labelN:
         for ()
         {
             break K; // <------  заменили метку

ровно тоже самое будет и с неявными метка:

  for () // <----- добавили
  {
    for () // <---- цикл1
    {
....
         for () // <----- циклN
         {
             break N; // <------  заменили метку просто прибавив единицу к старому значению уровня вложенности - N+1.

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

72. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от Аноним (33), 02-Мрт-26, 17:37 
я у же не говорю про то, что возьмет один дурак и изменит имя метки :) удачи искать что не так. А в случае с уровнем вложенности - это по факту инвариант (неизменяемое), он изменится только когда добавят новый уровень вложенности.
Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

75. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (-), 02-Мрт-26, 18:02 
> он изменится только когда добавят новый уровень вложенности

И вот _тогда-то_ утдачи искать, что не так.

Ответить | Правка | Наверх | Cообщить модератору

91. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 18:53 
> И вот _тогда-то_ утдачи искать, что не так.

меняется уровень - меняется логика, а чту тут такого может быть не так? Выше примеры есть.

Ответить | Правка | Наверх | Cообщить модератору

83. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (34), 02-Мрт-26, 18:28 
> я у же не говорю про то, что возьмет один дурак и изменит имя метки :) удачи искать что не так.

Вообще не проблема, т.к. при первой же сборке компилятор подсветит несуществующую метку в goto.

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

88. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 18:51 
> Вообще не проблема, т.к. при первой же сборке компилятор подсветит несуществующую метку в goto.

ну да, только пойми теперь без разбора всей логики к какому циклу эта метка относилась.

Ответить | Правка | Наверх | Cообщить модератору

95. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (34), 02-Мрт-26, 19:06 
>> Вообще не проблема, т.к. при первой же сборке компилятор подсветит несуществующую метку в goto.
>
> ну да, только пойми теперь без разбора всей логики к какому циклу эта метка относилась.

Блин, чувак, ты только что накуролесил в коде - ты можешь посмотреть git diff? Даже если куролесил не ты, git blame и show в помощь. (И последующий отзыв прав на push для того, кто закоммитил несобирающийся код.)

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

Ответить | Правка | Наверх | Cообщить модератору

98. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 19:14 
> Блин, чувак, ты только что накуролесил в коде - ты можешь посмотреть git diff? Даже если куролесил не ты, git blame и show в помощь.

я вижу как куролесят современные XZ.

> О чем речь вообще?

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

Ответить | Правка | Наверх | Cообщить модератору

100. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 19:16 
а если речь заходит про всякие гиты шЫты и прочие утилиты, отлично, контролем уровнем вложенности может заниматься ваш текстовый редактор, в чем проблема? Зачем в ЯП пихать функции текстового редактора?
Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

113. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от 12yoexpert (ok), 02-Мрт-26, 20:01 
>  Ну да, а потом иди считай, куда твой break или continue на самом деле переходит. Заняться нечем?

а нехер писать спагетти с 50 уровнями вложенности

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

126. "Релиз набора компиляторов LLVM 22"  –2 +/
Сообщение от Аноним (34), 02-Мрт-26, 20:40 
Ну т.е. давайте сделаем фичу, чтобы ей не пользоваться. Л-логика 80 lvl.
Ответить | Правка | Наверх | Cообщить модератору

132. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от 12yoexpert (ok), 02-Мрт-26, 21:40 
согласен. есть ведь goto - бери и пользуйся. нет, нужно создавать видимость бурной деятельности и выдумывать костыльные конструкции  
Ответить | Правка | Наверх | Cообщить модератору

36. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (36), 02-Мрт-26, 14:49 
Явное лучше неявного. Полностью одобряю подход авторов.
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

43. "Релиз набора компиляторов LLVM 22"  –2 +/
Сообщение от Аноним (33), 02-Мрт-26, 15:10 
> Явное лучше неявного.

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

Ответить | Правка | Наверх | Cообщить модератору

50. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сладкая булочка (?), 02-Мрт-26, 15:40 
> В пхп давно оно неявное, достаточно указать номер уровня вложенности continue 2;

Сейчас бы ориентироваться на пых.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

56. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (33), 02-Мрт-26, 16:08 
> Сейчас бы ориентироваться на пых.

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

Ответить | Правка | Наверх | Cообщить модератору

63. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (79), 02-Мрт-26, 16:29 
Единственно верный путь.
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

37. "Релиз набора компиляторов LLVM 22"  –1 +/
Сообщение от Аноним (37), 02-Мрт-26, 14:58 
50+ лет фанаты сишечки рассказывать что "ненужОн ваш RAII!" и без defer обойдемся!
А тут хоба - в драфт стандарта принял))
Ответить | Правка | Наверх | Cообщить модератору

44. "Релиз набора компиляторов LLVM 22"  –2 +/
Сообщение от Аноним (42), 02-Мрт-26, 15:10 
Ну это не RAII всё же. Его запретили везде не просто так.
Ответить | Правка | Наверх | Cообщить модератору

45. "Релиз набора компиляторов LLVM 22"  +3 +/
Сообщение от 12yoexpert (ok), 02-Мрт-26, 15:22 
о, у вас уже и RAII запретили
Ответить | Правка | Наверх | Cообщить модератору

46. "Релиз набора компиляторов LLVM 22"  +2 +/
Сообщение от 12yoexpert (ok), 02-Мрт-26, 15:24 
RAII это corruption, как раст, превращает straightforward обработку ошибок в какой-то бесполезный ад из костылей
но гуманитариям после курсов или совкового универа этого не понять, их удел - макдональдс или аутсорс
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

57. Скрыто модератором  +/
Сообщение от Аноним (33), 02-Мрт-26, 16:10 
Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз набора компиляторов LLVM 22"  –2 +/
Сообщение от Аноним (66), 02-Мрт-26, 17:15 
> RAII это corruption

RAII это основа одного из самых распространенных и успешных ЯП - с++.
Оно помогает перестать ковыряться в дидовой гоутушной лапше, а нормально обрабатывать ошибки. Но я не удивлен, что ты это не осилил.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

68. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (64), 02-Мрт-26, 17:31 
перестать ковыряться в дидовой гоутушной лапше, которая хотя бы функцией ограничена и начать ковыряться в еще более адовой лапше setjmp/longjmp.
Ответить | Правка | Наверх | Cообщить модератору

119. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (125), 02-Мрт-26, 20:14 
> начать ковыряться в еще более адовой лапше setjmp/longjmp

Лол. А где мне увидеть комбо компилятора/платформы, где исключения под капотом реально используют setjmp/longjmp, а не zero-cost DWARF и виндовый SEH?

Ответить | Правка | Наверх | Cообщить модератору

127. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (64), 02-Мрт-26, 20:40 
> zero-cost DWARF

Да пофиг, goto тоже zero-cost или как это у вас там называется в плюсах. Вместо дидовой гоутушной лапши, ограниченной одной функцией, теперь ковыряемся в DWARF-лапше размазанной по всем файлам.

Ответить | Правка | Наверх | Cообщить модератору

130. "Релиз набора компиляторов LLVM 22"  –1 +/
Сообщение от Аноним (125), 02-Мрт-26, 21:33 
> Да пофиг, goto тоже zero-cost или как это у вас там называется в плюсах

Оно ни капли не zero-const в плане читаемости и поддержки. В этом как бы весь смысл.

> теперь ковыряемся в DWARF-лапше размазанной по всем файлам.

О каких ковыряниях в DWARF-лапше ты говоришь? Есть стандартный trow/try/catch, который ведет себя предсказуемо и существует в куче языков помимо C++.

Ответить | Правка | Наверх | Cообщить модератору

134. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от Аноним (64), 02-Мрт-26, 21:58 
Дак и goto стандартный - есть в любом процессоре и ведёт себя предсказуемо.
Ответить | Правка | Наверх | Cообщить модератору

144. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (125), 02-Мрт-26, 23:44 
> Дак и goto стандартный - есть в любом процессоре

Зачем ты съехал в процессор, если речь идет о языках?

> и ведёт себя предсказуемо

Да "сигнуть черт знает куда" - это очень предсказуемо. Кстати, подскажи-ка, что там будет с C++ деструкторами или сабжевым defer после goto?

Ответить | Правка | Наверх | Cообщить модератору

154. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (64), 03-Мрт-26, 01:31 
> Зачем ты съехал в процессор, если речь идет о языках?

А ты зачем съехал на читабельность в контексте zero-cost, если это про накладные расходы в рантайме?

> Кстати, подскажи-ка, что там будет с C++ деструкторами или сабжевым defer после goto?

А сам проверить не можешь чтоли? Ничего не будет - они выполнятся.

Ответить | Правка | Наверх | Cообщить модератору

155. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (64), 03-Мрт-26, 01:34 
> Да "сигнуть черт знает куда" - это очень предсказуемо.

Всмысле черт знает куда? Куда указал туда и прыгнул - это даже в ассемблерном выхлопе элементарно проверить в отличие от лапши на плюсах.

Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

131. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (131), 02-Мрт-26, 21:37 
> Вместо дидовой гоутушной лапши, ограниченной одной функцией

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

> теперь ковыряемся в DWARF-лапше размазанной по всем файлам.

В том-то и дело, что не ковыряемся: логика отдельно (сам код), управление ресурсами отдельно (RAII), обработка ошибок отдельно (исключения).

Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

137. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (64), 02-Мрт-26, 22:08 
Ой, да что ты сочиняешь... логика у него отдельно, ага. Будто у тебя try/catch не в основном коде используются.
Ответить | Правка | Наверх | Cообщить модератору

145. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (125), 02-Мрт-26, 23:46 
> Будто у тебя try/catch не в основном коде используются.

Нет. В этом как бы и смысл исключений: отделять мух от котлет, а не как в сишочке с кодами ошибок и goto - все одной портянкой.

> Ой, да что ты сочиняешь... логика у него отдельно, ага.

Я смотрю, содержательного диалога с фанатом goto не получиться...

Ответить | Правка | Наверх | Cообщить модератору

150. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (64), 03-Мрт-26, 00:39 
#include <iostream>
#include <stdexcept>

int main() {
    try {        
        throw std::runtime_error("An error occurred");
    } catch (const std::exception& e) {
        std::cerr << "Caught exception: " << e.what() << std::endl;
    } catch (...) {
        std::cerr << "Caught an unknown exception" << std::endl;
    }
    return 0;
}

Это вот эта шляпа отдельно от котлет с мухами?

Ответить | Правка | Наверх | Cообщить модератору

151. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (125), 03-Мрт-26, 00:44 
> Это вот эта шляпа отдельно от котлет с мухами?

Вот конкретно то, что ты написал - нет. Но я хз, что ты этим кодом хотел сказать.

Ответить | Правка | Наверх | Cообщить модератору

153. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (64), 03-Мрт-26, 00:54 
Ну покажи тогда пжлст пример где try/catch не в основной логике, чтоб мухи отдельно от котлеток были
Ответить | Правка | Наверх | Cообщить модератору

110. "Релиз набора компиляторов LLVM 22"  –2 +/
Сообщение от 12yoexpert (ok), 02-Мрт-26, 19:47 
> Оно помогает перестать ковыряться в дидовой гоутушной лапше,

ога
1) goto - плохо
2) диды так обрабатывают ошибки
3) на C/C++ пишут только диды
так сказали веб-синьоры на курсах

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

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

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

111. Скрыто модератором  –2 +/
Сообщение от Аноним (111), 02-Мрт-26, 19:54 
Ответить | Правка | Наверх | Cообщить модератору

114. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (125), 02-Мрт-26, 20:02 
> RAII - манна небесная, позволяет ловить исключения

Нет, RAII - это не способ ловить исключения. RAII вообще не имеет никакого отношения к исключениям и их обработке.

Поздравляю, ты как всегда сел в лужу. 👍

Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

70. "Релиз набора компиляторов LLVM 22"  +2 +/
Сообщение от ИмяХ (ok), 02-Мрт-26, 17:35 
>>поддержка именованных циклов

Зумеры заново изобрели goto

Ответить | Правка | Наверх | Cообщить модератору

78. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от Аноним (79), 02-Мрт-26, 18:08 
А что ты спонсоры скажешь куда потратили деньги?
Ответить | Правка | Наверх | Cообщить модератору

80. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от нах. (?), 02-Мрт-26, 18:10 
не изобрели а снова победили!
Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

81. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Ананоним (?), 02-Мрт-26, 18:17 
Отец, прости их, потому что они не ведают, что творят...

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

Ответить | Правка | Наверх | Cообщить модератору

85. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (71), 02-Мрт-26, 18:43 
> Вместо того чтобы создать класс с деструктором и использовать по классике, им нужны всякие деферы.

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

Ответить | Правка | Наверх | Cообщить модератору

87. "Релиз набора компиляторов LLVM 22"  –1 +/
Сообщение от Ананоним (?), 02-Мрт-26, 18:49 
>> Вместо того чтобы создать класс с деструктором и использовать по классике, им нужны всякие деферы.
> На каждую функцию лепить классы? Вы же замахаетесь.

Кажется ты не понимаешь принципов ООП. Си подходит для низкоуровневых задач, там где надо всё руками для полного контроля, в ином случае подходит Си++. Ну а если гвозди забивать микроскопами, тогда и получится что микроскопы деградируют до очень сложных и дорогих молотков.

> А дефер нужен чтобы подчистить продукты жизнедеятельности функции - поочищать память, занулить
> нужное, закрыть дескрипторы и тд.

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

Ответить | Правка | Наверх | Cообщить модератору

89. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Ананоним (?), 02-Мрт-26, 18:51 
> поочищать память, занулить нужное, закрыть дескрипторы и тд.

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

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

109. "Релиз набора компиляторов LLVM 22"  –1 +/
Сообщение от Сладкая булочка (?), 02-Мрт-26, 19:35 
> Отец, прости их, потому что они не ведают, что творят...
> Извратили лаконичные языки хуже некуда. Вместо того чтобы создать класс с деструктором
> и использовать по классике, им нужны всякие деферы.

То есть для очистки ресурсов нужно втаскивать ООП в язык? Вы из какой палаты, товарищ?

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

121. "Релиз набора компиляторов LLVM 22"  –1 +/
Сообщение от Ананоним (?), 02-Мрт-26, 20:22 
С царской палаты я. ООП в языке уже есть, C++ называется. Просто вы там не тот инструмент выбрали, коль вам так нужна автоматика очистки.
Ответить | Правка | Наверх | Cообщить модератору

122. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (125), 02-Мрт-26, 20:28 
> То есть для очистки ресурсов нужно втаскивать ООП в язык?

А языках без gc ресурсы по-другому и не очищаются: либо деструкторы (и классическое ООП им не обязательно), либо 100500 раз ручками пишешь defer.

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

135. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от 12yoexpert (ok), 02-Мрт-26, 22:00 
какое вообще отношение деструкторы могут иметь к ООП?
Ответить | Правка | Наверх | Cообщить модератору

136. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сладкая булочка (?), 02-Мрт-26, 22:01 
>> То есть для очистки ресурсов нужно втаскивать ООП в язык?
> и классическое ООП им не обязательно

В сообщении, на которое был ответ https://www.opennet.ru/openforum/vsluhforumID3/139378.html#81 говорилось именно про классы с деструктором

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

В gcc уже есть расширение, которое позволяет через атрибут привязать к объекту указатель на функцию для очистки.

Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

147. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (125), 02-Мрт-26, 23:56 
> В gcc уже есть расширение, которое позволяет через атрибут привязать к объекту указатель на функцию для очистки.

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

Во-вторых, "уже есть" не GCC-расширение, а именно деструкторы в C++. С 80-х годов уже есть. GCC-расширение - чистой воды костыль, причем вендорлочный, в отличие от деструкторов C++.

Ответить | Правка | Наверх | Cообщить модератору

148. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сладкая булочка (?), 03-Мрт-26, 00:11 
>> В gcc уже есть расширение, которое позволяет через атрибут привязать к объекту указатель на функцию для очистки.
> Во-первых, оно работает только для объектов на стеке.

Как и defer также только для Scope-based resource management.  

Ответить | Правка | Наверх | Cообщить модератору

149. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сладкая булочка (?), 03-Мрт-26, 00:30 
> Для композитных объектов, вложенные объекты тебе придется по-классике ручками удалять.

А как вы в С будете неявно создавать композитные объекты? У вас будет какой-нибудь Foo *foo_new(), который будет неявно что-то там делать. Очевидно будет и void foo_free(Foo *f), вот вы и пишете в своей функции

Foo *f = foo_new();
defer foo_free(f);

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

        _cleanup_free_ char *subvolume = NULL, *parent = NULL;
        _cleanup_close_ int fd = -EBADF;

Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

152. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (125), 03-Мрт-26, 00:46 
> А как вы в С будете неявно создавать композитные объекты?

Речь шла не о том, чтобы их неявно создавать, а о том, чтобы они автоматом удалялись с родителем.

Ответить | Правка | Наверх | Cообщить модератору

158. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Сладкая булочка (?), 03-Мрт-26, 03:27 
>> А как вы в С будете неявно создавать композитные объекты?
> Речь шла не о том, чтобы их неявно создавать, а о том,
> чтобы они автоматом удалялись с родителем.

Вот условный void foo_free(Foo*) их и удалит, как указатель на всю структуру выйдет из области видимости.

Ответить | Правка | Наверх | Cообщить модератору

86. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (86), 02-Мрт-26, 18:48 
Не умеет в создание и интроспекцию DOS MZ и NE.
Ответить | Правка | Наверх | Cообщить модератору

97. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от Аноним (99), 02-Мрт-26, 19:13 
> Добавлена поддержка именованных циклов, позволяющих присваивать имена циклам и оператору switch

О, круто! Ещё надо присваивать имена присвоениям переменных и присвоениям имён циклам, операторам switch и присвоениям переменных.
> которые можно указывать в операторах break и continue для явного определения цикла, из которого производится выход.

Поперёк вложенности? Это ещё более круто! Это выведет возможности по наведению бардака в коде на совершенно новый, ранее недосягаемый уровень!

Ответить | Правка | Наверх | Cообщить модератору

104. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от Аноним (86), 02-Мрт-26, 19:23 
>Для включения следует использовать флаг "-fsanitize=alloc-token".

Без поддержки в валгринде бесполезно.

Ответить | Правка | Наверх | Cообщить модератору

133. "Релиз набора компиляторов LLVM 22"  +1 +/
Сообщение от Аноним (133), 02-Мрт-26, 21:49 
Он до сих пор более жирные бинарники генерирует чем gcc? А то я попробовал собрать u-boot для allwinner'а через clang 21. По сравнению с gcc 14 u-boot spl получился 22 кб, почти в лимит 24 вложился, против 16 кб в gcc.
Ответить | Правка | Наверх | Cообщить модератору

146. "Релиз набора компиляторов LLVM 22"  +/
Сообщение от Аноним (146), 02-Мрт-26, 23:55 
Оптимизация путём инлайнинга.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2026 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру