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

"GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от opennews (?), 23-Ноя-24, 21:46
В кодовую базу, на основе которой формируется запланированный на весну следующего года выпуск набора компиляторов GCC 15, принято изменение, включающее по умолчанию использование стандарта С23 с расширениями GNU ("-std=gnu23") при компиляции программ на языке C (ранее по умолчанию использовался стандарт C17 - "-std=gnu17"). Изменение потенциально может привести к проблемам при сборке существующих проектов, так как в новом стандарте имеются отличия, такие как добавление типов nullptr и  _BitInt(n), а также появление  ключевых слов bool, true и false,  которые могут конфликтовать с заданными в приложениях одноимёнными идентификаторами... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62278
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "GCC 15 будет использовать стандарт C23 по умолчанию"	+25 +/–
Сообщение от ДаНуНафиг (?), 23-Ноя-24, 21:46
Ну надо же, bool/true/false подвезли! Я дожил до этого момента!
Ответить | Правка | Наверх | Cообщить модератору

	8. "GCC 15 будет использовать стандарт C23 по умолчанию"	+7 +/–
	Сообщение от Аноним (8), 23-Ноя-24, 22:32
	А те, кому реально это было нужно — не ждали и использовали <stdbool.h>, начиная с C99…
	Ответить | Правка | Наверх | Cообщить модератору

	68. "GCC 15 будет использовать стандарт C23 по умолчанию"	+7 +/–
	Сообщение от Анон28679234 (?), 24-Ноя-24, 02:39
	Вообще довольно странно рассуждать о примитивных типах как о "реально нужных" или ненужных При определенной степени ментальных упражнений можно даже ассемблер называть синтаксическим сахаром для электроцепи, однако я не вижу очереди желающих написать себе сайт с помощью паяльника
	Ответить | Правка | Наверх | Cообщить модератору

	132. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (132), 24-Ноя-24, 10:17
	Поверьте налепив сверху на ассемблер макросов можно с легкостью слабать любой сайт ))
	Ответить | Правка | Наверх | Cообщить модератору

	174. Скрыто модератором	+/–
	Сообщение от Аноним (174), 24-Ноя-24, 13:55
	зачем это декаденство? любой сайт можно с легкостью спаять
	Ответить | Правка | Наверх | Cообщить модератору

	184. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (184), 24-Ноя-24, 15:06
	Ассемблер это и есть набор макросов над набором инструкций процессора. А вот если бы кто-то придумал способ превращать более абстрактные, высокоуровневые конструкции в ассемблер для любого набора инструкций...
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	185. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (132), 24-Ноя-24, 15:08
	LLVM ?
	Ответить | Правка | Наверх | Cообщить модератору

	72. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 03:35
	>  Ну надо же, bool/true/false подвезли! Я дожил до этого момента! Это еще что! Как тебе такое Элон Маск?! > Появилась поддержка использования спецификатора constexpr для определения объектов. А вот тут... >  Добавлена поддержка префиксов "0b" и "0B" для указания целых значений в двоичной форме ...всем микроконтроллерщикам радоваться полчаса!
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	121. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (121), 24-Ноя-24, 09:32
	"Хочу смеяться пять минут!" ©
	Ответить | Правка | Наверх | Cообщить модератору

	201. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от ryoken (ok), 24-Ноя-24, 16:29
	...пересмотреть что ли...
	Ответить | Правка | Наверх | Cообщить модератору

	228. Скрыто модератором	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 17:55
	У меня надолго было в башке "волшебные спички" )
	Ответить | Правка | Наверх | Cообщить модератору

	146. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Тот_Самый_Анонимус_ (?), 24-Ноя-24, 11:46
	Ну, кстати, 0b, 0B и %b были вполне логичны изначально. А вот true и false излишни. Меня радовало их отсутствие после мерзского паскаля.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	147. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от нах. (?), 24-Ноя-24, 11:49
	не, ну как только в процессорах появятся "true" и "false", а не jz, так сразу пусть и приходят. А пока да - совершенно вредоносная фигня, скрывающая суть операций. Тем более в языке с автоматическим приведением типов.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 15:22
	> не, ну как только в процессорах появятся "true" и "false", а не > jz, так сразу пусть и приходят. > А пока да - совершенно вредоносная фигня, скрывающая суть операций. Тем более > в языке с автоматическим приведением типов. Наличие или отсутствие "jz" в конкретном процессоре - вообще не гарантировано. А если ты хотел на ассемблере шпрехать - вот на нем и шпрехай. Прибитый к 1 архитектуре сишка нафиг не упал.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от нах. (?), 24-Ноя-24, 16:15
	> Наличие или отсутствие "jz" в конкретном процессоре - вообще не гарантировано. лолшта? Процессор без условного перехода - еще не изобрели. А когда изобретут, в нем вряд ли будут работать процедурные языки вообще.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:39
	>> Наличие или отсутствие "jz" в конкретном процессоре - вообще не гарантировано. > лолшта? Процессор без условного перехода - еще не изобрели. Как именно реализованы у конкретного проца условные переходы и какие там условия - это implementation defined и это как раз то от чего мы в си хотим абстрагироваться. Не хотели - юзали бы макроассемблеры, мля. > А когда изобретут, в нем вряд ли будут работать процедурные языки вообще. Ну какие-то условные операнды конечно быть должны, но так для понимания на тебе SUBLEQ. Такой вот набор команд. Не совсем jz, да? Конечно это мастеркласс брейнфаку как надо было но это тюринг полный набор команд :)
	Ответить | Правка | Наверх | Cообщить модератору

	236. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от нах. (?), 24-Ноя-24, 18:50
	> Как именно реализованы у конкретного проца условные переходы и какие там условия - это > implementation defined но проца с истиными true/false ты конечно же не покажешь. Проца без jz полагаю тоже. > и это как раз то от чего мы в си хотим абстрагироваться кто эти вы и в одной ли с вами они сейчас комнате? > Не хотели - юзали бы макроассемблеры, мля. У pdp-11 был прекрасный макроассемблер. Но авторы Си хотели немного сэкономить себе долбежку по клавиатуре (а вовсе не "абстрагироваться" - для феноменально т-пых повторяю - вот a[i++] - это никакая не абстракция, это особенность архитектуры именно этой машины, и может быть еще у vax была такая же. И ничего, все пользуемся.) > но это тюринг полный набор команд Но нигде не используется и не будет. Поэтому по прежнему придется помнить что все что нельзя привести к integer 0 - является true.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (181), 24-Ноя-24, 14:52
	> Ну, кстати, 0b, 0B и %b были вполне логичны изначально. ЧСХ я ими и пользовался уже лет 10. Просто как GNU Extension. Все равно вон та фирмварь чем-то кроме GCC - не соберется. Ибо в стандартном си даже положить объект в конкретную секцию нельзя. > А вот true и false излишни. Меня радовало их отсутствие после мерзского паскаля. Особенно радовадо в каком-нибудь uint8_t var = 0xFF + 1; ... if (var) else // А мы точно собирались - сюда?!
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	167. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (167), 24-Ноя-24, 13:15
	Микроконтроллерщики уже на C++
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	187. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 15:24
	> Микроконтроллерщики уже на C++ Отучаемся говорить за всех.
	Ответить | Правка | Наверх | Cообщить модератору

	237. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (237), 24-Ноя-24, 18:51
	> Добавлена поддержка префиксов "0b" и "0B" для указания целых значений в двоичной форме Пятьдесят джва года ждал! Как в DOS в своё время не хватало, всякие железки в порты тыкать.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

2. Скрыто модератором	–1 +/–
Сообщение от Аноним (2), 23-Ноя-24, 21:58
Как-то всё равно. Мой мак с macOS давно слез с Гэ-Цэ-Цэ, у которого, откровенно говоря, лицензия, которая выгодна только корпорациям.
Ответить | Правка | Наверх | Cообщить модератору

	4. Скрыто модератором	+9 +/–
	Сообщение от Блюститель лицензий (?), 23-Ноя-24, 22:03
	Сидеть на маке и жаловаться на лицензию, "выгодную корпорациям" - это какой-то новый уровень.
	Ответить | Правка | Наверх | Cообщить модератору

	5. Скрыто модератором	+4 +/–
	Сообщение от Маковод (?), 23-Ноя-24, 22:19
	Финн Линус же сидит (как и большая часть кернел девелоперов).
	Ответить | Правка | Наверх | Cообщить модератору

	169. Скрыто модератором	+/–
	Сообщение от Аноним (167), 24-Ноя-24, 13:22
	У Яфинна и кернел-девелоперов там Linux.
	Ответить | Правка | Наверх | Cообщить модератору

	10. Скрыто модератором	–1 +/–
	Сообщение от Аноним (8), 23-Ноя-24, 22:38
	> лицензия, которая выгодна только корпорациям. Толсто же. GCC распространяется по лицензии GPLv3+, которая заставляет раскрывать код и делиться патентами. Clang из макоси распространяется по лицензии Apache 2.0, не накладывающей никаких ограничений на закрытие кода. Х–м–м, и какая же из них «выгодна только корпорациям»? Такой сложный вопрос (нет).
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	14. Скрыто модератором	–1 +/–
	Сообщение от Маковод (?), 23-Ноя-24, 23:00
	> Х–м–м, и какая же из них «выгодна только корпорациям»? Любая, которая позволяет делать форки и потом коммерциализировать этот софт, который написан бесплатной мартышкой, уверовавшей в шваботку.
	Ответить | Правка | Наверх | Cообщить модератору

	20. Скрыто модератором	+/–
	Сообщение от YetAnotherOnanym (ok), 23-Ноя-24, 23:33
	> какая же из них «выгодна только корпорациям»? Та, которая заставит маленький стартап выложить всё на блюдечке с голубой каёмочкой забесплатно. Для Безоса и ему подобных.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	31. Скрыто модератором	–1 +/–
	Сообщение от Аноним (31), 24-Ноя-24, 00:11
	> Как-то всё равно. Мой мак с macOS давно слез с Гэ-Цэ-Цэ, у > которого, откровенно говоря, лицензия, которая выгодна только корпорациям. Два чая адеквату. Вся эта GPL — типичный троянский конь, где под прикрытием "свободы" корпорасты получают почти даром готовые продукты и бесплатную рабочую силу.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

6. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (6), 23-Ноя-24, 22:25
>Структуры, объединения и перечисления разрешено определять более одного раза в одной области видимости с одним и тем же содержимым и повторяющимся тегом. а это зачем?
Ответить | Правка | Наверх | Cообщить модератору

	9. "GCC 15 будет использовать стандарт C23 по умолчанию"	+3 +/–
	Сообщение от bircoph (ok), 23-Ноя-24, 22:35
	Чтоб меньше конфликтов было при всяких #include и inline.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "GCC 15 будет использовать стандарт C23 по умолчанию"	–4 +/–
	Сообщение от Аноним (6), 23-Ноя-24, 23:23
	> Чтоб меньше конфликтов было при всяких #include и inline. И как 50 лет жили без этого.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "GCC 15 будет использовать стандарт C23 по умолчанию"	+6 +/–
	Сообщение от Аноним (32), 24-Ноя-24, 00:14
	С матами и постоянными переименованиями всего и вся лишь бы этот комп-депилятор перестал жаловаться, а уже начал комп-депилировать.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 13:14
	Главное, чтобы потом не запутаться в синонимичности.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 13:18
	Остается вопрос - а когда определена сущность.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	95. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 06:55
	>> Чтоб меньше конфликтов было при всяких #include и inline. > И как 50 лет жили без этого. Ну, как, как, городили костыли типа #ifndef HAVE_WTF_H #define HAVE_WTF_H ...(основная тушка)... #endif
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	126. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (6), 24-Ноя-24, 09:44
	Теперь не будут?
	Ответить | Правка | Наверх | Cообщить модератору

	134. "GCC 15 будет использовать стандарт C23 по умолчанию"	+3 +/–
	Сообщение от Аноним (132), 24-Ноя-24, 10:22
	теперь будут городить современные модные костыли
	Ответить | Правка | Наверх | Cообщить модератору

7. "GCC 15 будет использовать стандарт C23 по умолчанию"	+6 +/–
Сообщение от Аноним (7), 23-Ноя-24, 22:30
> Вызов функции realloc() с нулевым размером переведён в разряд неопределённого поведения. Нужно больше неопределённого поведения! Потом, когда вылезут очередные уязвимости из-за работы с памятью, можно будет с уверенностью утверждать, что где-то ещё оптимизатор смог ускорить работу на 0.01% благодаря этому!
Ответить | Правка | Наверх | Cообщить модератору

	11. "GCC 15 будет использовать стандарт C23 по умолчанию"	+8 +/–
	Сообщение от Аноним (11), 23-Ноя-24, 22:41
	Ничего удивительного, в этом языке даже int + int является неопределенным поведением. Нам в 2024 ясно видна дикость этого, а вот палео-кодерам из палео-70-ых это казалось нормальной идеей.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (31), 24-Ноя-24, 00:06
	> int + int является неопределенным поведением Воо, это вообще лютая дичь, я до сих пор не понимаю, КАК такое возможно в языке для системного программирования.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (31), 24-Ноя-24, 00:08
	П.с. а еще больше недоумеваю от тех УМВРщиков, которые в упор это не замечают.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "GCC 15 будет использовать стандарт C23 по умолчанию"	+8 +/–
	Сообщение от Аноним (32), 24-Ноя-24, 00:16
	Потому что системный язык должен полагаться на то как происходит сложение на аппаратном уровне в конкретной системе, а не воротить абстракцию над абстракцией лишь бы все было везде одинаково. Кому надо одинаково идут на джаваскрипт зачем им Си?
	Ответить | Правка | Наверх | Cообщить модератору

	44. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 00:41
	> Потому что системный язык должен полагаться на то как происходит сложение на > аппаратном уровне в конкретной системе, а не воротить абстракцию над абстракцией > лишь бы все было везде одинаково. Кому надо одинаково идут на > джаваскрипт зачем им Си? Вон то на практике вело к дохреналиону багов, увы и ах. А абстракции что, как вон то алго не считай, а если ему надо не менее 32 битов для корректной работы - то хоть ты тресни, но ты или дашь эти 32 бита, или профачишь вычисления. В ряде случаев еще и с вулнами, отрицательными индексами массивов и прочими характерными факапами. И спасибо еще если это дамп памяти по сети или в эфир улетит. А то бывает и такое, heartbleed соврать не даст.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "GCC 15 будет использовать стандарт C23 по умолчанию"	+6 +/–
	Сообщение от mister_0 (?), 24-Ноя-24, 00:47
	int a + int b <= int max из этого условия можно вывести weakest predicate и проверить его до сложения int max - int a => int b если это условие не работает, то складывать не надо, будет страшный оверфлоу. один if и тот сделать не могут, подавай им сразу новый язык, бороу чекер, безразмерную арифметику и прочее.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "GCC 15 будет использовать стандарт C23 по умолчанию"	+3 +/–
	Сообщение от Аноним (55), 24-Ноя-24, 01:11
	> int a + int b <= int max > из этого условия можно вывести weakest predicate и проверить его до сложения > int max - int a => int b Да, но... 1) Это лишняя операция. 2) Половина долбоклюев это забудет. 3) На практике в системном программировании порой нужны доступы конкретного размера, скажем к HW regs. Ну то-есть железка может в принципе не поддерживать ничего кроме "доступ 32 бита шириной" и мне нафиг не вперся ваш int абстрактный, мне надо - доступ на шине 32 бита щириной. > если это условие не работает, то складывать не надо, будет страшный оверфлоу. > один if и тот сделать не могут, подавай им сразу новый язык, > бороу чекер, безразмерную арифметику и прочее. Это не халявно в рантайме и чревато глупыми багами. И выглядит как костыль.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от mister_0 (?), 24-Ноя-24, 01:58
	>Это не халявно в рантайме и чревато глупыми багами. И выглядит как костыль. у тебя есть процессор и три регистра по 32 бита ты загрузил в один регистр A 0x1000000 ты загрузил в другой регистр B 0x1000000 ты просишь процессор сложить A + B и записать в регистр C у тебя не хватило бит и это оверфлоу чтобы не было оверфлоу тебе надо что-то всё равно делать, это никогда не халявно. за шины волноваться не стоит их там 100500 между регистром процессора и регистром девайса, там всё нормально будет.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 07:16
	> у тебя есть процессор и три регистра по 32 бита Меня для начала колышет в системщине - делать доступы конкретного размера. А не абы какой от фонаря. Потому что часто надо при работе с железом, да и для предсказуемости математики самое то, чтобы как раз получать ГАРАНТИРОВАННЫЕ свойства. > ты загрузил в один регистр A 0x1000000 > ты загрузил в другой регистр B 0x1000000 > ты просишь процессор сложить A + B и записать в регистр C За 16-ричную математику этот аноним^W mister_0 получает твердую двойку! Ибо 0x2000000 прекрасно лезет в 32-битный регистр, сумма 25 битов всего. И если я скажу uint32_t something() {     uint32_t a = 0x1000000;     uint32_t b = 0x1000000;     return (a + b); } ...то вот это как раз - ГАРАНТИРОВАННО сработает, как раз по причине диапазона, и более того компилер даже по этой аннотации проверить может - если вдруг нет. И выдать варнинг, между прочим. А вот если я int в этом месте напишу - вот это будет залет. Ибо он и 16 битов может быть. При том на обычном компе это все прокатит. Но на каком-нибудь AVR голимом меня в таком коде будет ждать нефиговый сюрприз, если вдруг это не отловится почему-то. Когда вся математика отъедет нахрен. Заметьте, оптимизация вам тут все равно не светит. Если операция требует 25 битов, даже на атмеге компилер развернет 32-бит "этажерку" для этого. Да, это будет медленнее но это лучше чем напрочь некорректный счет в управляющей системе. И это как раз причина int по возможности вообще не юзать. Хреново он в стандарте определен, и кто из програмеров всерьез уповает что это 16 битов? Большая часть кода подразумевает минимум 32. И конечно вытворяет черти что на авр каком. Сериализовать int портабельно - это вообще отдельный вопрос. Т.е. IO по сети и с файлами это сразу задник. С uint32_t все сильно проше. Только с порядком байтов "в провод" определиться и - готово, мы знаем что всегда будет 4 байта. > у тебя не хватило бит и это оверфлоу Чтобы умничать по теме - в ней надо хоть что-то понимать, чтоли. > чтобы не было оверфлоу тебе надо что-то всё равно делать, это никогда не халявно. Или не надо. Как в вон том примере. Де факто там вообще будет нечто типа mov r5, #2000000h - ну или что там можно энному процу закодировать. Т.е. де факто это скорее всего в том примере будет предвычесление и кода не будет вообще - только сам результат. А если это потом нигде не юзается - даже и этого не будет. > за шины волноваться не стоит их там 100500 между регистром процессора и > регистром девайса, там всё нормально будет. На минуточку, есть еще mem-mapped периферия и проч. И вот оно довольно разборчивое на тему того какие туда доступы можно а какие нельзя. И давать лекции тому кто это все практикует - не рубя в топике - надо конкретно наглости набраться, "на уровне Кента" практически.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 11:45
	Есть регистр флагов, где валидность результата уже видна и не надо городить ваши фантазии.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	56. "GCC 15 будет использовать стандарт C23 по умолчанию"	+5 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 01:16
	> int max - int a => int b Если значение "int a" отрицательное, будет переполнение при вычитание (underflow), которое тоже есть UB. В целом ваш коментарий показателен, типичный сишник не только не знает Си, но с умным лицом берется рассуждать о других языках.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	59. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от mister_0 (?), 24-Ноя-24, 01:33
	несомненно для отрицательных чисел нужно использовать min int, а ещё конечно не стоит забывать о представлении числа и в дополнительной форме отрицательных больше чем положительных на одно. но идея вполне понятна, если ты боишься оверфлоу, то можешь вполне всё проверить. эти проверки можно встроить или генерить автоматом, но они всё равно будут. хочешь быстро используй специальную инструкцию https://stackoverflow.com/questions/14523480/assembly-detect... один чёрт всё равно придётся что-то придумать, что делать, если оверфлоу
	Ответить | Правка | Наверх | Cообщить модератору

	64. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (64), 24-Ноя-24, 02:17
	> эти проверки можно встроить или генерить автоматом, но они всё равно будут. Вместо дорогой пред-проверки с явными сравнениями и несколькими ветками можно было бы использовать дешёвую пост-проверку регистра флагов, выражающуюся одним conditional jump'ом, вдобавок очень хорошо обрабатываемым branch predictor'ом. В C это невозможно сделать даже явно, а в современных языках это делается по умолчанию.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от mister_0 (?), 24-Ноя-24, 13:26
	>В C это невозможно сделать даже явно, а в современных языках это делается по умолчанию. ага ну конечно, это в каких так сделано? точно не в дебаг компиляции онли? Бранч предиктор хорош, но исполнение нескольких бранчей с одбрасыванием результатов ненужных тоже происходит. Ещё раз нигде бесплатно за программиста оверфлоу не обрабатывают, но для этого и есть программист, чтобы с этим разобраться.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (73), 24-Ноя-24, 04:04
	Сначала проверь, что оба положительные, потом вычти одно из max int, сравни со вторым, потом уже можешь складывать.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	189. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (189), 24-Ноя-24, 15:39
	> Сначала проверь, что оба положительные, потом вычти одно из max int, сравни > со вторым, потом уже можешь складывать. И во сколько раз у нас накроется скорость всей математики таким манером? Не хотите себе крипто или кодек которые разика в 3-4 тормознее того что у вас сейчас? Сможете с дотнетчиками и жабистами на равных зарубаться, а то что они пыль из под ваших сапог нюхают, давайте наравне с ними, а?! Хинт: нормальные люди не борятся с законами природы, они ими пользуются. Для unsigned - врап вполне well defined, и крипто вполне себе уповает что uint8/16/32 - врапается вполне характерным образом, дабы не делать лишние операции. К тому же условные операции - в крипто например текут инфо о характере обрабатываемой инфы. Так выполняется столько, а этак столько? Битик ключа такой-то, i++, и вот ваш офигенный 256-бит ключ угадывается за ... чтоооо, 256 забегов, глазом не успели моргнуть?! А вот врап - он вообще железный в большей части процов. А если даже и не железный то потток команд будет одинаковый.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Bottle (?), 24-Ноя-24, 09:20
	...и теперь ты нагородил кучу проверок на пустом месте, которые ещё надо писать руками, а не использовать заранее безопасные типы, определённые стандартом языка. В каком-то месте забудешь, и получишь overflow. И, что характерно, ты эти проверки реализуешь гораздо медленнее, чем квалифицированный разработчик компиляторов. В итоге твоя программа будет и медленной, и кривой.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	212. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (212), 24-Ноя-24, 16:56
	> ...и теперь ты нагородил кучу проверок на пустом месте, которые ещё надо > писать руками, а не использовать заранее безопасные типы, Что еще хуже - при запиле руками, "в лоб", тот же int a + int b <= INT_MAX это как бэ, UB, который не покажет -Wall -Wextra, лишь санитайзерв в рантайме, тут нужно что-то типа if(a < INT_MAX - b) x=a+b
	Ответить | Правка | Наверх | Cообщить модератору

	218. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (212), 24-Ноя-24, 17:07
	> if(a < INT_MAX - b) x=a+b ЧСХ, если b негативное число, то тут ... правильно, UB.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 11:52
	стандартный вопрос - какому числу равен min int?
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	190. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (189), 24-Ноя-24, 15:40
	> стандартный вопрос - какому числу равен min int? Вообще в макросне указано - чему он равен в конкретной системе. Как и максимальный.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Neon (??), 24-Ноя-24, 05:38
	А простое сложение расползается кучей кода с кучей багов. Спасибо, не надо
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	91. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (91), 24-Ноя-24, 06:22
	если a = -10, то при int max - int a будет оверфлоу > один if и тот сделать не могут, подавай им сразу новый язык, бороу чекер, безразмерную арифметику и прочее.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	122. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (122), 24-Ноя-24, 09:33
	Когда мне нужно было решить задачу проверки на переполнение, я использовал intprops.h из gnulib. Как более удобная обёртка, что ли. Тоже в итоге там какие-то подобные проверки.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	128. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (32), 24-Ноя-24, 09:55
	Зачем тебе тогда си если ты собрался это проверять на каждом сложении? Чтобы побольше поторомозить? Ну так тебе уже сказали джаваскрипт твой выбор. Переполнение к слову не единственная проблема. И ты их проверять на каждом сложении .. устанешь.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	170. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 13:22
	Если вам нужен язык для вычислительной математике - берите фортран и не пудрите мозги.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	105. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:41
	На практике ничего иного не наблюдается. Языки с иными свойствами почему-то миру ничего дать не смогли. Поэтому там может быть хоть в 10 раз больше багов - это никак не влияет на оценку.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	125. "GCC 15 будет использовать стандарт C23 по умолчанию"	–2 +/–
	Сообщение от Bottle (?), 24-Ноя-24, 09:43
	Практика не показатель качества - выживают не самые сильные и умные, а самые адаптированные. И в контексте рынка адаптация может означать широту поддержки и широкую популярность какой-то ОС, написанной на копроязычке (привет, Юникс) для PDP-11.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (32), 24-Ноя-24, 09:57
	Тебе навешали лапши про какие то вульны и ты теперь истеришь не по делу.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 10:10
	Показатель. Воровские лозунги ничего не стоят и не значат. Да и в целом рассказы про показатели имеют смысл только в контексте выбора. Здесь выбора нет - остальные языки не слабы, а просто не существуют. Поэтому сразу мимо.
	Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

	176. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 14:30
	>ты или дашь эти 32 бита, или профачишь вычисления. Для вычислений используйте Фортран.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	46. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 00:45
	> Потому что системный язык должен полагаться на то как происходит сложение > на аппаратном уровне в конкретной системе Угу, именно поэтому они это не implementation-defined, не хотя бы unspecified, а вот сразу UB! Что бы когда ты писал код, то как он будет работать было именно ХЗ, в зависимости от платформы, железа, флагов, степени безумия разраба компилятора, которые может просто выкинуть твой код нафиг с обоснование "не, ну не бывает же UB в нормальном коде".
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	54. "GCC 15 будет использовать стандарт C23 по умолчанию"	–2 +/–
	Сообщение от анон (?), 24-Ноя-24, 01:10
	Такова плата за генерацию эффективного кода. Никто же не заставляет использовать именно Си
	Ответить | Правка | Наверх | Cообщить модератору

	69. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 02:50
	> Такова плата за генерацию эффективного кода. Так ведь всё с точностью до наоборот. В Си надо обложить код if`ами чтобы не получить UB, но если у тебя модульная арифметика (в том числе знаковая) тогда на это можно положиться и писать эффективный код.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от Bottle (?), 24-Ноя-24, 04:10
	О дааа! Тот самый эффективный код на Си, известный своими утечками памяти. А то, что указатели не обладают строгостью, как в Фортране, это мы конечно умолчим. И то, что "швитой штандарт" разрешает любым переменным занимать хоть 64 бита, лишь бы преодолевали минимальную границу длины от стандарта. Да, очень эффективное управление памятью для переменных вида int и float. Всего лишь в два-четыре раза больше положенного.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	152. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 12:23
	Уже давно есть типы фиксированной ширины и контроль переполнения. Задирание ширины проистекает от неопределенности программистом масштаба вычислений. int + int = long int
	Ответить | Правка | Наверх | Cообщить модератору

	80. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Neon (??), 24-Ноя-24, 05:39
	Это называется халтура. На от@бись
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	106. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:44
	Если бы не заставляли. Все слёзы и ненависть обусловлена тем, что никаких иных языков кроме си не существует. А те, которые существуют номинально - на них ничего невозможно написать.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	120. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (73), 24-Ноя-24, 09:31
	Аноним написал много латинских слов, и думает, что написал что-то умное. А на самом деле, implementation-defined, unspecified и undefined, это буквально одно и то же. Что конкретно скрывается за UB, должно быть задокументировано в документации к компилятору.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	143. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 11:33
	Если для вас > implementation-defined, unspecified и undefined, это буквально одно и то же. то это прекрасно объясняет причины текущего состояния айтишечки)) Предлагаю открыть стандарт и вдумчиво прочитать 3.4.1, 3.4.3, 3.4.4. А заодно еще заглянуть в секцию "4. Conformance" и почитать к чему может приводить наличие UB в коде, в отличие от остальных.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 00:46
	Ну давай, расскажи мне как ты собрался из Си "полагаться на то как происходит сложение на аппаратном уровне" если переполнение int`ов есть undefined behavior а не implementation-defined behavior.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	78. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Neon (??), 24-Ноя-24, 05:35
	Пусть на ассемблере кодят, раз им нужно сложение на аппаратном уровне в конкретной системе. Язык высокого уровня уже по любому абстракция
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	90. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от morphe (?), 24-Ноя-24, 06:13
	> Потому что системный язык должен полагаться на то как происходит сложение на аппаратном уровне в конкретной системе, а не воротить абстракцию над абстракцией лишь бы все было везде одинаково. Вот только всё современное железо реализует это как two's complement, и сложение везде переполняется. (Кроме каких-нибудь мейнфреймов на system z с binary-coded-decimals, но даже там C реализован не через это) Rust же гарантирует что сложение переполняется всегда, потому что стандартные числа в Rust всегда two's complement. (Что на каких-то абстрактных платформах может потребовать софтверной реализации, но таких фактически не существует) А в сях стандарт написан так, что сложение может происходить на абаках, а потому переполнение - undefined behavior, иначе говоря компилятор в праве оптимизировать код так, будто переполнения никогда не произойдут НА ЛЮБОЙ ПЛАТФОРМЕ.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	111. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (111), 24-Ноя-24, 08:54
	> А в сях стандарт написан так, что сложение может происходить на абаках Ты просто не умеешь этим гордиться, а они умеют.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:39
	Просто они знают, что ub является переполнение, а не сложение. Поэтому у них всё работает.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	42. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от mister_0 (?), 24-Ноя-24, 00:37
	ну так ты проверь перед сложением или можешь после сложения в регистр flags посмотреть, там есть бит переполнения. а ещё есть люди которые рапэраунд с оверфлоу путают
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	49. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (49), 24-Ноя-24, 00:48
	> или можешь после сложения в регистр flags посмотреть в С?
	Ответить | Правка | Наверх | Cообщить модератору

	50. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от mister_0 (?), 24-Ноя-24, 00:53
	ну придётся ассемблерную вставку сделать.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 01:04
	> ну придётся ассемблерную вставку сделать. А ничего что на сях мы писали - чтобы портабельно было, м?!
	Ответить | Правка | Наверх | Cообщить модератору

	123. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (73), 24-Ноя-24, 09:36
	Вы писали на сях, чтобы было быстро, а не чтобы было портабельно. Оптимальное соотношение между скоростью разработки и скоростью работы программы.
	Ответить | Правка | Наверх | Cообщить модератору

	191. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (191), 24-Ноя-24, 15:45
	> Вы писали на сях, чтобы было быстро, а не чтобы было портабельно. Мы писали на сях - чтобы было и быстро и портабельно, ага! :) > Оптимальное соотношение между скоростью разработки и скоростью работы программы. И именно поэтому логично брать размеры переменных - того размера которого уместно в энной задаче. Более того - это иногда как раз оптимизация. Скажем "int" в AVR по дефолту 16 битов и это в принципе 16-бит операция. Замена на явный uint8_t в каком-нибудь цикле может улучшить код, если я точно могу гарантировать что счетчик никогда не более 255. И тогда оно будет телепать 1 регистр x8 а не 2 x8 при случае. Конечно есть некий шанс, что оптимизер на таком уродце и int обрубит до 8 битов если по диапазону влезло - но вот это уже ниоткуда не следует.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 13:29
	Для портабельно используйте Java. Си это быстрота и гибкость.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	192. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (191), 24-Ноя-24, 15:46
	> Для портабельно используйте Java. Си это быстрота и гибкость. Для непортабельного у нас уже был ассемблер, но пример Colibri OS почему-то намекает как делать не стоит... :). А свою энтерпрайзятину - кушайте сами.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Neon (??), 24-Ноя-24, 05:40
	А на хрена тогда С нужен ? Если нужно сразу на ассемблере фигачить
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	51. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от mister_0 (?), 24-Ноя-24, 00:55
	но я выше ответил, что проще считать post condition выводить weakest predicate и проверять его до вызова и никаких тебе оверфлоу. или ты думаешь, что только использования раста и питона это единственный способ?
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	65. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (64), 24-Ноя-24, 02:19
	> или ты думаешь, что только использования раста и питона это единственный способ? Скажем так, единственный способ - это не использование С.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:48
	Пистон написан на си, поэтому там ситуация таже самая. Раст компилируется си компилятором, поэтому ситуация снова такая же. Хоть паскалик бы в пример привёл - не настолько позорно было бы.
	Ответить | Правка | Наверх | Cообщить модератору

	137. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 10:45
	Ты глупость написал и даже не покраснел. Если я напишу на PHP компилятор языка Х в машинный код, его поведение никак не будет связано с, собственно, PHP.
	Ответить | Правка | Наверх | Cообщить модератору

	139. Скрыто модератором	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 10:59
	Просто ты рядовой ретранслятор пропаганды. Раст компилируется не компилятором написанным на си, а компилятором си. Обладающим всеми свойсвами си и всеми недостатками си. На чём он там написан не важно(хотя и очевидно на чём).
	Ответить | Правка | Наверх | Cообщить модератору

	179. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 14:40
	Эвоно как, Михалыч! Оказывается LLVM это не оптимизирующий бэкенд, а всего-то компилятор Си. Надо им issue на гитхабе открыть, пацаны то не знают.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 11:38
	> Раст компилируется си компилятором Это не соответствует действительности. Фронт раста компилируется внезапно компилятором на расте. А бек - это llvm, который написана на современном с++, а не окаменелой мерзопакостной дыряшке. Да и даже если допилят gcc-rs, то gcc это сейчас тоже с++. Даже до них дошло что писать на сишке серьезные вещи не продуктивно.
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	150. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 12:01
	Соответствует, просто ты ангажированный агитатор, спамящий агитки. "написано на си/не на си" - агитатор не заметил, что я не писал что раст компилируется написанным на си или не на си. "есть гццрс" - агитатор спорит с тезисом "раст компилируется си компилятором" и показывает компиляцию раста си компилятором. "компилятор на расте" - которого не существует и где компиляцией занимается си компилятор.
	Ответить | Правка | Наверх | Cообщить модератору

	180. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 14:52
	LLVM - то ещё гуано. https://habr.com/ru/companies/pvs-studio/articles/859914/
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	107. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:45
	В си. __builtin_*_overflow() - 1000 лет есть.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	119. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 09:21
	Нет, похоже всё ещё хуже - там в новости написано "Добавлена поддержка заголовочных файлов <stdckdint.h>". Это даже в стандарте теперь есть, но почему-то эксперты говорят "в си нет способа".
	Ответить | Правка | Наверх | Cообщить модератору

	188. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 15:31
	Какие милые костили)) И даже это стандартизировали только через _пол-века_ после создания самого языка. А зачем следование параметров поменяли?
	Ответить | Правка | Наверх | Cообщить модератору

	194. Скрыто модератором	+1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 15:59
	Очередное умножение агитатора на ноль. Сначала он рассказывал, что нет способов. Потом, когда эти способы показали, начал рассказывать "ну раньше не было, только сейчас появились". Если ткнуть его носом уже в это враньё - он начнёт мазаться "ну это не по дефолту"/"а можно не использовать эти способы"/"я не понимаю что делаю, поэтому меня нужно принуждать к конкретному и единственному решению". И так далее.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 01:04
	> ну так ты проверь перед сложением или можешь после сложения в регистр > flags посмотреть, там есть бит переполнения. В сях нет стандартного способа посмотерть флаги, внезапно. > а ещё есть люди которые рапэраунд с оверфлоу путают Wrapround определен и гарантирован только для unsigned, если что.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	82. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Neon (??), 24-Ноя-24, 05:41
	> В сях нет стандартного способа посмотерть флаги, внезапно. Такой системный язык))). Близкий к аппаратуре
	Ответить | Правка | Наверх | Cообщить модератору

	97. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 07:28
	>> В сях нет стандартного способа посмотерть флаги, внезапно. > Такой системный язык))). Близкий к аппаратуре Внезапно он еще и про портабельность. А имплементация флагов у разных процов - довольно разная бывает. Так что - ограничения жанра, скажем так. В парадигмах C вообще возможны как таковые только mem-mapped доступы. Если нечто не отмаплено в память - ну, этого нет. На память об этом вся современная периферия как раз mem mapped, а всякие io пространства - легаси. Заодно mem mapped железки и DMA удобны, чего уж там. Самый лучший код - это его отсутствие!
	Ответить | Правка | Наверх | Cообщить модератору

	124. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (111), 24-Ноя-24, 09:40
	> В парадигмах C вообще возможны как таковые только mem-mapped доступы. Ну, у C есть ещё стандартизированные* расширения из ISO/IEC TR 18037. Среди которых named address spaces** и iohw.h. Флеш-память и EEPROM в AVR не отмаплены на адресное пространство RAM и требуют других инструкций, но с расширением компилятор сам их будет вставлять. Хоба: __eeprom volatile unsigned char ee_var = 0xff; // IAR const __flash int array[] = { 3, 5, 7, 11, 13, 17, 19 }; // GCC С одной стороны, всё-таки расширение, а не чистый язык. А с другой стороны, на расширение аж стандарт есть, это не линуксовые гнутости. Если бы отдельные пространства прижились, то расширение бы и в язык перекочевало. * Стандартность оказалась достаточно весома, чтобы GCC их не реализовывал в C++ ** https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
	Ответить | Правка | Наверх | Cообщить модератору

	195. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (195), 24-Ноя-24, 16:06
	>> В парадигмах C вообще возможны как таковые только mem-mapped доступы. > Ну, у C есть ещё стандартизированные* расширения из ISO/IEC TR 18037. Среди > которых named address spaces** и iohw.h. Ну вот такой вот хреновый стандарт, со звездочкой и 5-м шрифтом :) > Флеш-память и EEPROM в AVR не отмаплены на адресное пространство RAM и > требуют других инструкций, но с расширением компилятор сам их будет вставлять. 1 из многочисленных причин по которым AVR - слился. > Хоба: > __eeprom volatile unsigned char ee_var = 0xff; // IAR > const __flash int array[] = { 3, 5, 7, 11, 13, 17, > 19 }; // GCC Хоба, __eeprom и __flash не являются стандартными квалификаторами си, да еще - разные в разных компилерах, вау. А на СortexM наппример - const int arr[] = {2, 3, 7}; уйдет в RODATA (flash) сам, а не будет RAM жрать как на аврине глупой. Отличный мастеркласс от фирмы ARM что удобно си и програмерам, и почему линейные пространства рулят. Теперь попробуй DMA этого -> периферия? Ох, у уродца AVR и DMA нету, так что тщедушное ядро еще и должно само нестандартно дергаться на это? Ок, +1 гвоздь в крышку гроба. Ибо ЭТО сейчас умеет вон тот 20-центовый RISCV на его горе (DMA автомат и uncore вообще там "STM32-like"). > С одной стороны, всё-таки расширение, а не чистый язык. А с другой > стороны, на расширение аж стандарт есть, это не линуксовые гнутости. Реально это +1 причина забыть о AVR навсегда. В мире где за 20 центов продают RISCV с DMA, не имеющего такие проблемы, его время определенно вышло. > Если бы отдельные пространства прижились, то расширение бы и в язык перекочевало. Вместо этого брейнфака нормальные люди сделали mem-mapped периферию. И с ней работать на порядок проще, в нее можно DMA зарядить и все такое. И пока вы на малохольном ядре таскаете байты из флешки сами, 20-центовый китаец заряжает весь блок данных в периферию DMA и 32-бит проц вообще идет заниматься своими делами, забыв об этом. Во сколько раз суммарно это обставляет AVR - особенно с учетом цена/фичи - ну вы поняли.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (111), 24-Ноя-24, 18:33
	Ну блин, это была не реклама AVR, а история про то, что если не отмаплено, то в C ещё не всё так однозначно из-за этих "Extensions for the programming language C to support embedded processors". У C++, например, нет таких стандартных расширений и раздела Common extensions в стандарте нет. AVR очевидно устарел, сейчас он выглядит как учебное пособие - там всего немного и задокументировано хорошо, даташит - маленький, набор команд - маленький, тулчейн от GCC - маленький; не заблудишься. Контроль за размещением в SRAM vs Flash всё равно может пригодиться, скорость чтения-то разная.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:55
	> В сях нет стандартного способа посмотерть флаги, внезапно. Не позорься - написал выше этот способ. > Wrapround определен и гарантирован только для unsigned, если что. Опять же, нужно меньше позориться. ++*(unsigned*)&int_var - переполняй сколько хочешь.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	148. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 11:52
	> переполняй сколько хочешь. Поздравляю. Своим костылем с кастом к unsigned вы только подтверждаете что проблему UB, что убогость сишки в целом. Продолжайте в том же духе))
	Ответить | Правка | Наверх | Cообщить модератору

	196. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (195), 24-Ноя-24, 16:13
	>> В сях нет стандартного способа посмотерть флаги, внезапно. > Не позорься - написал выше этот способ. Тебе там уже написали что ты облажался. А, ты за добавкой пришел? Ну я тебе ее отсыплю, синьор-помидор. >> Wrapround определен и гарантирован только для unsigned, если что. > Опять же, нужно меньше позориться. ++*(unsigned*)&int_var - переполняй сколько хочешь. От того что ты накастовал это как unsigned - формат хранения (signed) int в памяти определеннее не станет. А то что ты приказал считать это unsigned и даже для unsigned оно определено, вовсе не гарантирует ожидаемый результат в именно signed, просто потому что это ниоткуда не следует в общем случае ;) Хотя комитет придурков это утомило - они с C23 все же как я помню утвердили, что signed теперь только two's complement. Но - не, сделать это нормально их не хватило, и все равно - UB местами оставили. Фйэспалм, лол. Или как сделать все на 90% и профачить весь профит остальными 10% долбоклюизма.
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	203. Скрыто модератором	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 16:33
	> Тебе там уже написали что ты облажался. Показывай, клоун. Чего мямлишь и прячешься за кого-то. > А то что ты приказал считать это unsigned и даже для unsigned оно определено, вовсе не гарантирует ожидаемый результат в именно signed, просто потому что это ниоткуда не следует в общем случае ;) > Хотя комитет придурков это утомило - они с C23 все же как я помню утвердили, что signed теперь только two's complement. Ты там определись, маня - у тебя слишком течёт методичка. И да, как-то быстро ты позабыл про "нет способа". Чего так?
	Ответить | Правка | Наверх | Cообщить модератору

	210. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:51
	>> Тебе там уже написали что ты облажался. > Показывай, клоун. Чего мямлишь и прячешься за кого-то. Так вон там выше тебе показаи что ты ub влепил. >> Хотя комитет придурков это утомило - они с C23 все же как я помню утвердили, что signed >> теперь только two's complement. > Ты там определись, маня - у тебя слишком течёт методичка. И да, > как-то быстро ты позабыл про "нет способа". Чего так? Какая методичка? Это вы про драфты стандартов C23 так чтоли? Там спасибо что хоть bool не отменили совсем. А то собирались, выпилив в пользу bit exact. Вот это было бы круто, да. В смысле - софт посыпался бы как горох. И таки вон тот костыль условно-валиден только для C23 и даже так - это вроде бы нигде железобетонно никакими регуляциями не гарантировано. Нечто из разряда определения железок и их полей как struct. Обычно работает - но то что это ОБЯЗАНО работать в обещм то ниоткуда не следует и тем более не регламентировано стандартом.
	Ответить | Правка | Наверх | Cообщить модератору

	219. Скрыто модератором	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 17:11
	"там уже написали, что ты облажался" => "показывай" => "вот там написали, что ты облажался" - в общем, этот клоун продолжает мазаться. Ничего не показал, на вопросы не ответил. И даже в этом снова запуталась в показаниях. Один и тот же случай - то уб, то валиден - и так через предложение. Ладно, похоже он решил даже не пытаться изображать адекватность, а просто спамить.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 08:38
	Судя по всему решение хорошее. Как иначе объяснить, что весь софт написан на этой дикости, а на чём-то ином не аписано ничего.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	222. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 17:22
	Весь нормальный софт написан на плюсах. Даже самый сишный компилятор гцц и тот не осилили на сишке продолжать. А на сишке или легаси нуано, или упертый Айм Финнишь, который просто не хочет признать свою ошибку. А до с++ была ада. Но быдлокоделам было легче писать на си.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 14:27
	Если по факту UB, то и объявить надо, что - UB.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

12. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
Сообщение от Аноним (12), 23-Ноя-24, 22:46
Значит ли это, что gcc 15 будет поддерживать стандарт c23 ПОЛНОСТЬЮ?
Ответить | Правка | Наверх | Cообщить модератору

15. "GCC 15 будет использовать стандарт C23 по умолчанию"	+5 +/–
Сообщение от Маковод (?), 23-Ноя-24, 23:02
Всё это ерунда, есть же православный ANSI C (C89). Всё остальное — ненужный реверс инжиниринг с синтаксическим сахаром.
Ответить | Правка | Наверх | Cообщить модератору

	16. "GCC 15 будет использовать стандарт C23 по умолчанию"	+5 +/–
	Сообщение от Маковод (?), 23-Ноя-24, 23:03
	Овер инжиниринг* (будь проклята автозамена)
	Ответить | Правка | Наверх | Cообщить модератору

	34. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (32), 24-Ноя-24, 00:19
	Сахар это язык zig. Си это та ложка дегтя.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "GCC 15 будет использовать стандарт C23 по умолчанию"	+2 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 00:34
	> Всё это ерунда, есть же православный ANSI C (C89). Всё остальное — > ненужный реверс инжиниринг с синтаксическим сахаром. Вот ты на нем и прогай. А я меньше чем на C99 в принципе не согласен, а лучше минимум 11, ибо делать из г-на и палок аналог static assert'а - ну такое себе.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

18. "GCC 15 будет использовать стандарт C23 по умолчанию"	–2 +/–
Сообщение от nc (ok), 23-Ноя-24, 23:26
Расширения GNU давно пора принимать в стандарты С и С++. Простые и полезные идеи, уже давно реализованные и многократно проверенные. Единственное чего не хватает - расширения __declspec(property) в С++, которое есть в msvc и clang, но нет в gcc.
Ответить | Правка | Наверх | Cообщить модератору

	135. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (111), 24-Ноя-24, 10:29
	> в стандарты С Нет, C практически заморожен. И не один GCC имеет власть - не захотят остальные реализовывать фичу, её из стандарта удалят (история с Microsoft, C11 и VLA (нет, то, о чём я говорю не вернули в C23)). > и С++ А он шевелится, но Страуструп постоянно говорит, что надо избегать фрагментации и создания несовместимых диалектов. Если сделать вид, что расширений GNU не существует, то и фрагментации языка они не вызывают - примерно так это работает. Вызывают, конечно, но это уже не головная боль комитета, поэтому будем считать, что не вызывают. Но народ пользуется расширениями и комитет описывает какой-то полумифический язык? Как хорошо, что это не проблема комитета. У стандартного C++ слишком много требований совместимости (обратной, API'шной, ABI'шной, в некоторой степени даже прямой, [s]диагональной[/s]), они язык тормозят и медленно-медленно погубят.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:23
	>> в стандарты С > Нет, C практически заморожен. И не один GCC имеет власть - Де факто актуальные компилеры C это GCC и Clang. > не захотят остальные реализовывать фичу, её из стандарта удалят (история с Microsoft, > C11 и VLA (нет, то, о чём я говорю не вернули в C23)). Майкрософт хотя-бы C99 уже смог в своих недоделках, чтобы им там еще про C23 что-то заикаться вообще? :) С VLA грабли по другим причинам. Ибо это - как правило аллокация на стеке (не так уж важно, но все усугубляет - его размер не бесконечен). При том - хрен его знает сколько доступно было, это ДО аллокации узнать нельзя. А если не получилось - узнать это можно только крахом/жесточайшим UB. Что для системного языка не предел мечтаний. Т.е. заведомо интерфейс для прострела пяток, вместе с коленками и черепом заодно, вообще без возможности корректной реакции на нехватку аллокации потенциально-большого объекта. > создания несовместимых диалектов. Если сделать вид, что расширений GNU не существует, > то и фрагментации языка они не вызывают - примерно так это работает. Расширения GCC просто периодически втягивают в стандарт. И в C и в C++. После чего майкрософт как зайчик идет имплементить - или noncompliant и не может декларить этот стандарт. > У стандартного C++ слишком много требований совместимости (обратной, API'шной, ABI'шной, > в некоторой степени даже прямой, [s]диагональной[/s]), они язык тормозят и медленно-медленно > погубят. У C++ так то разные версии есть...
	Ответить | Правка | Наверх | Cообщить модератору

	220. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (111), 24-Ноя-24, 17:15
	> Майкрософт хотя-бы C99 уже смог в своих недоделках, чтобы им там еще про C23 что-то заикаться вообще? :) > или noncompliant и не может декларить этот стандарт. Так ты 2+2 написал, а сложить не сложил. Я сложу: из C99 выкинули VLA, C99 стал C11, стандарт C11 Microsoft и задекларил. > Де факто актуальные компилеры C это GCC и Clang. Актуальность - это одно, а количество власти в комитете - другое. > С VLA грабли по другим причинам Не важно, GCC от него не отказался (и в микроконтроллерах не опаснее, чем использование кучи, а в общем-то безопаснее). > У C++ так то разные версии есть... Но надо и понимать глубину наших глубин. Новую версию нельзя расширять радикально, потому что от языка требуется некоторая прямая совместимость. В proposal'ах серьёзно пишут: "backward and forward compatibility"[1]. "WG21 is supposed to protect against dialects"[2] "There is a reasonable fear that attributes will be used to create language dialects"[3] "Unless done extremely carefully, the “modernized C++” would suffer from the problems encountered with “Safe C” languages: the inability to interoperate sufficiently smoothly with older C++ constructs to avoid needing to become a self-sufficient subset of a much-enlarged C++ language"[4] [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p18... [2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27... [3] https://stroustrup.com/C++11FAQ.html#attributes [4] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p26...
	Ответить | Правка | Наверх | Cообщить модератору

	223. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (111), 24-Ноя-24, 17:28
	> потому что от языка требуется некоторая прямая совместимость То есть требуется не только чтобы старый код работал в новых компиляторах (обратная совместимость). но и хорошее взаимодействие между старым и новым кодом. То есть старый код тянет назад будущие версии языка. Это как если бы в JS не стали добавлять "use strict", потому что он диалект создаёт. Проблему даже сложно осознать, но в C++ она есть.
	Ответить | Правка | Наверх | Cообщить модератору

38. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (-), 24-Ноя-24, 00:23
llvm не лучше? обоснуйте
Ответить | Правка | Наверх | Cообщить модератору

	115. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 09:04
	Хуже. ``` int f(int* p, int a) { p = __builtin_assume_aligned(p, a); } ```
	Ответить | Правка | Наверх | Cообщить модератору

40. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (-), 24-Ноя-24, 00:31
> атрибут [[noreturn]] позволяет указать, что функция не возвращает значений Вообще-то он указывает что функция никогда не возвращается. Скажем main в фирмвари - возвращаться некуда и его можно задекларить так (экономит немного кода в прологе функции).
Ответить | Правка | Наверх | Cообщить модератору

58. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (58), 24-Ноя-24, 01:20
14 версия при сборке пакетов ругалась на указатели, 15 будет ругаться если код не той версии. Страшно представить на что 16 версия ругаться будет.
Ответить | Правка | Наверх | Cообщить модератору

70. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
Сообщение от мяв (?), 24-Ноя-24, 02:59
что-то фигня какая-то с auto.. auto myNum = superCalculator(2,2); и иди гадай, кого там возвращает твоя функция. а потом твой друг пойдет гадать и лазать в соседнем файле, когда откроет код .. псоле чего окажется, что эту фцнкцию где-то там по дороге перекрыли/перепилили/вовсе другой файл включили и она тперь возвращает int, вместо uint :| зачем вообще такое добавлять в язык со сторой типизацией? ну, серьезно, это ж лол какой-то. послезавтра эта функция будет char* возвращать. и я, вместо жалобы на неправельный тип в декларации, увижу 100500 жалоб в черт пойми, каких частях кода. а auto молча станет char*.
Ответить | Правка | Наверх | Cообщить модератору

	71. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от мяв (?), 24-Ноя-24, 03:00
	я ж правильно логику работы auto поняла?
	Ответить | Правка | Наверх | Cообщить модератору

	84. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Neon (??), 24-Ноя-24, 05:43
	Какие проблемы ? Смотрим объявление функции. В современных IDE это автоматом подсвечивается при наведении на функцию
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	161. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (228), 24-Ноя-24, 12:49
	А без IDE и AI уже никуда?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Илья (??), 24-Ноя-24, 05:48
	Значит, типизация не строгая. Должно сломаться всё по цепочке. А то, что ты тип возвращаемого значения меняешь в публичном апи - это отдельный вопрос
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	163. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 12:57
	Ну неявно это можно понимать как тип "возвращенный функцией". Освобождает от знания интерфейса функции, но оставляет вопросы сопряжения с другими типами. В си никогда не было строгой типизации. Была идея "адаптивной типизации".
	Ответить | Правка | Наверх | Cообщить модератору

	99. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 07:45
	> что-то фигня какая-то с auto.. > auto myNum = superCalculator(2,2); Да вот блин да, научились у некоторых - а конкретно плюсеров. Но порой таки - удобно. Прикинь если есть несколько compound types - например struct, и мы переменную декларим в небольшой области видимости, как auto, и там может быть или 1 подвид, или другой, и нам не хочется греть мозг какой именно - ибо код дальше корректно рюхал оба. В таком случае оно выходит довольно элегантно. И как минимум в плбсах катит. А тут... посмотрим, посмотрим. > и иди гадай, кого там возвращает твоя функция. Вообще в ide-like это просто go to declaration (как правило шорткат). Хоть конечно и лишний клац. > по дороге перекрыли/перепилили/вовсе другой файл включили и она тперь возвращает int, > вместо uint :| Вообще я не очень понимаю зачем auto в C/C++ совать. Туда же примерно и автоматический вывод типов без явного указания. Это -1 барьер на пути багов. Лишняя аннотация намерений позволяет поймать баг если намерения все же обломались. > зачем вообще такое добавлять в язык со сторой типизацией? C никогда не был с вообще совсем строгой. И позволяет оверрайды. Можно приказать считать апельсины лимонами, сделав явный каст. Что будет дальше - на совести програмера, ессно. > а auto молча станет char*. Но есть вариант когда код был готов сожрать и то и другое. А с Generic такой вариант еще и "популяризован" фичой в конструкции яп. Си вообще забавная штука. Вроде низкоуровневый, но функция на самом деле может и получить и вернуть даже struct. Или struct'ы можно присваивать друг другу, однотипные конечно (технически это будет вызов memcpy - кодом выданным компилером на такое действо). А в struct можно еще и допустим указатель на функцию загнать - и тогда получится ну разве что не C++ с "методами", но - нечто достаточно похожее. Ибо struct.myFunc(arg) - будет вполне валидной конструкцией так то. Но поскольку это все же не C++ то это имеет свои лимиты.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	113. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Бывалый Смузихлёб (ok), 24-Ноя-24, 08:57
	Зато, как славно показали себя иные адепты строгой и явной типизации и отсутствия такого у того же ЖС вот то ли дело сишечка Стоило лишь в некоторые ЯП подвезти auto. Наворачивали за обе щёки и обмазывали вообще всё до чего могли дотянуться, а не использовали ранее - тупо потому что такой возможности не было
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	162. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от ProfessorNavigator (ok), 24-Ноя-24, 12:51
	В С++ auto есть уже достаточно давно, и да, может вызывать проблемы. В том числе с читаемостью кода. Но есть у него и плюсы. Когда у вас std::find_if возвращает например итератор вида std::vector<std::tuple<MyClassOne, MyClassTwo, std::shared_ptr<MyClassThree>>>::iterator, то проще написать auto it = std::find_if(...). В данном случае и так сразу видно, итератор чего вернётся, и понятно - каким он будет. Поэтому auto вполне уместно - от него читаемость кода только повысится. Но злоупотреблять им естественно не стоит. Иначе, как вы правильно заметили, потом просто запутаетесь, какая функция что возвращает, и будете ловить проблемы на ровном месте.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	235. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 18:45
	Не позволяйте автомату (компилятору) определять ваш код за вас. Кроме того есть версии библиотек.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

77. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (77), 24-Ноя-24, 05:35
Зачем снова новый тип char8_t, если уже есть char и unsigned char. Более того есть еще stdint.h где есть int8_t и uint8_t. Почему?
Ответить | Правка | Наверх | Cообщить модератору

	85. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Neon (??), 24-Ноя-24, 05:44
	Почему "Ы" ???  Чтоб никто не догадался!)
	Ответить | Правка | Наверх | Cообщить модератору

	140. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 11:24
	Почему? А потому что диды-недостандартописаки смогли подоcpaть даже в такой простой вещий как char. Вот ответь на простой вопрос - обычный char будет знаковым или беззнаковым? А вот хз, как повезет. Для gcc он по умолчанию signed, но если использовать флаг -funsigned-char, то будет unsigned. Но опять же не везде - для Android NDK он по умолчанию unsigned и если что нужно юзать -fsigned-char. А для MSVC он по умолчанию signed, но флаг нужно использовать другой. При этом char8_t определен однозначно: "char8_t is an unsigned integer type used for UTF-8 and is the same type as unsigned char." en.cppreference.com/w/c/string/multibyte/char8_t
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	155. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 12:29
	Диды писали для себя и не думали о глобализации. Еще они дали местным инженерам адаптировать для своей аппаратной платформы.
	Ответить | Правка | Наверх | Cообщить модератору

	217. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 17:03
	Японцы с тобой несогласны вся Азия приветствует Юникод.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 12:27
	Потому что стандартом символа стал уникод. Кроме того это унификация под типы фиксированной ширины.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	182. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 14:54
	Давайте проведем эксперимент в Debian vi test.c #include <stdio.h> int main(int argc, const char *argv[]) {     printf("%s\n", argv[1]);     return 0; } make test ./test Привет! Привет! Вопрос: Что я делаю не так ?
	Ответить | Правка | Наверх | Cообщить модератору

	199. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:28
	> make test > ./test Привет! > Привет! > Вопрос: Что я делаю не так ? Ну, для начала - не проверяешь что argv[1] вообще был, хотя-бы :). Так что если это запустить без аргументов... :)
	Ответить | Правка | Наверх | Cообщить модератору

	208. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 16:48
	Не проверяю для краткости. Вопрос не об этом. "Привет!" - это UTF-8 строка, а в main char** .
	Ответить | Правка | Наверх | Cообщить модератору

	216. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 17:00
	./test Привет! > hello.txt hexdump -C hello.txt 00000000  d0 9f d1 80 d0 b8 d0 b2  d0 b5 d1 82 21 0a        |............!.|
	Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

	229. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 18:12
	Про это и говорю. Вы прозрачно работаете с char не подозревая о его ширине. Когда-то она была равна 8 битам.
	Ответить | Правка | Наверх | Cообщить модератору

87. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
Сообщение от Аноним (87), 24-Ноя-24, 05:50
> Удалена возможность определения функций в стиле K&R C, используемом до принятия спецификации ANSI C и описанном в книге "The C Programming Language" Кернигана и Ритчи. Так это уже не тот язык С, который придумали его изобретатели Брайан Керниган и Деннис Ритчи. Это совсем совсем другой язык "С23" и т.д. и т.п. А значит, можно использовать старый стандарт 89 года, с оговоркой, что это настоящий язык С.
Ответить | Правка | Наверх | Cообщить модератору

	136. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (111), 24-Ноя-24, 10:42
	> старый стандарт 89 года Так это тоже "уже не тот язык С" - в K&R C не было UB (поэтому переиздание книжки K&R устарело примерно в момент выхода).
	Ответить | Правка | Наверх | Cообщить модератору

	178. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 14:38
	Это не важно.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (111), 24-Ноя-24, 16:29
	Не важно что? Пропасть между K&R C и C89 важна. "Переносимый ассемблер" поднялся выше, стал языком со сложными оптимизациями и лишился части старых низкоуровневых возможностей. Ритчи о будущем стандарте в 1988 высказался вот так. Вырываю из контекста, но слова с тех пор выстрелили по-всякому*. aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs The fundamental problem is that it is not possible to write real programs using the X3J11 definition of C. The committee has created an unreal language that no one can or will actually use. https://arxiv.org/pdf/2201.07845 --> https://groups.google.com/g/comp.lang.c/c/K0Cz2s9il3E/m/YDyo... * - -fwrapv и -fno-strict-aliasing в Linux как отступление от стандарта / "туалетной бумажки" / "bogus shit". - "Наличие UB - это лицензия компилятору на выкидывание кода, а не повод указать на ошибку". - Миф, что "-O3/-Ofast - опасные оптимизации" или иначе говоря реальность, в которой "в коде на C(++) разбросан опасный UB, который выстрелит при включении законных оптимизаций".
	Ответить | Правка | Наверх | Cообщить модератору

	209. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 16:50
	> Пропасть между K&R C и C89 важна. По сравнению с тем, что K&R и С23 это разные миры.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (111), 24-Ноя-24, 17:48
	Тогда выходит, что и C89 & С23 - разные миры. Это такая же ерунда, как про Кернигана, Ритчи и "их" C89. Парадигма языка менялась только в C89. C23 добавляет memset_explicit, не потому что он такой весь новый, а чтобы решить проблему, созданную в C89.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 17:21
	В 1988 году я ещё играл в "Лунолёт" на МК-61 и таких подробностей про С89 не знал. Я говорю "условно", чтобы принять ранний стандарт за эталон, так как он реализован в GCC. Оставлю опции компилятору. Но буду за этим следить тоже.
	Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

	238. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 18:52
	Опции GCC, управляющие диалектом языка. https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

88. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (87), 24-Ноя-24, 05:53
Оригинальный язык С описан в книге "The C Programming Language" Кернигана и Ритчи. Все остальное я могу с полным правом игнорировать. Отныне все мои проекты будут базироваться исключительно на книге "The C Programming Language".
Ответить | Правка | Наверх | Cообщить модератору

	157. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 12:34
	Главное держитесь подальше от учеников.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 17:33
	Грамматику языка С я реализую по этой книге. Что не будет сюда подходить, то отнесу на счет дополнительных правил. Можно сказать, что это будет новая ветка развития С, с того момента.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (167), 24-Ноя-24, 13:40
	И обязательно в самом оригинальном vi !
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	177. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Truth Seeker (?), 24-Ноя-24, 14:36
	Я использую vim - подсветка синтаксиса, авто-дополнение, многооконность в консоли, форматирование, замена и поиск regex, вставка результатов команды. Например, я могу вставить в текст прямо из сайта, не выходя из vim.
	Ответить | Правка | Наверх | Cообщить модератору

	193. Скрыто модератором	+/–
	Сообщение от Аноним (237), 24-Ноя-24, 15:52
	Не выходя из vim всякий может, а ты выйди из vim.
	Ответить | Правка | Наверх | Cообщить модератору

	215. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:59
	Скажи почему ты такой немодный? Модные и молодёжные будут использовать C23!
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

89. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (87), 24-Ноя-24, 06:01
> указания имён неиспользуемых параметров при определении функций (как в C++) > определения атрибутов как в С++ Также языком С++ лично я считаю язык представленный в книге The C++ Programming Language (1st edition). Все остальное - это выдумки, и я могу их с полным правом игнорировать.
Ответить | Правка | Наверх | Cообщить модератору

	117. "GCC 15 будет использовать стандарт C23 по умолчанию"	+3 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 09:17
	Требую больше постов о том, как ты игнорируешь. Я большой любитель поведения людей, которое можно описать словами "я такая противоречивая сегодня".
	Ответить | Правка | Наверх | Cообщить модератору

	240. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 18:57
	Это какой-то патентный троллинг.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

92. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от ijuij (?), 24-Ноя-24, 06:35
> Удалена возможность определения функций в стиле K&R C Это меня огорчает, у меня есть ещё код в подобном стиле!
Ответить | Правка | Наверх | Cообщить модератору

	93. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от ijuij (?), 24-Ноя-24, 06:46
	А так мне все нововведения нравятся, и особенно хочу отметить это: > Добавлены типы "_BitInt (N)" и "unsigned _BitInt (N))" для определения целых чисел с указанным числом битов 🔝
	Ответить | Правка | Наверх | Cообщить модератору

	101. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (101), 24-Ноя-24, 07:47
	Мммм. Как же мне не хватало переменных длиной 3, 7, 11 бит
	Ответить | Правка | Наверх | Cообщить модератору

	202. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:31
	> Мммм. Как же мне не хватало переменных длиной 3, 7, 11 бит Вообще иногда удобно. Если мне нужен диапазон 0..7 и при этом алго корректно работает, отдельно кодить валидацию и что вообще делать если на вход дали 20 ибо даже с uint8_t так можно было - сами понимаете. Хотя конечно если очень сильно хотелось - можно было битовыми полями в struct это организовать, но у struct'ов есть свои скелеты в шкафу. Главный из которых - если мы полтора параметра хотели, разворачивать огород с typedef struct было несколько не с руки.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (109), 24-Ноя-24, 08:53
	Это ж какой простор для UB! Ну и вообще, полностью идёт вразрез с идеей сишки. Всякие char/int реализуются аппаратно by design, а это-то как?
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	114. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от ijuij (?), 24-Ноя-24, 09:00
	> а это-то как? Там внедрено много кода, взгляни на коммиты в GCC: https://github.com/search?q=repo%3Agcc-mirror%2Fgc...
	Ответить | Правка | Наверх | Cообщить модератору

	142. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Советский инженер (ok), 24-Ноя-24, 11:29
	> Ну и вообще, полностью идёт вразрез с идеей сишки. т.е. когда поле структуры 3,7,11 бит - это не идет в разрез, а вот когда это отдельная переменная - то уже идет? так по твоему?
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	158. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 12:41
	Есть масочная операция над регистром и есть ячейка памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (111), 24-Ноя-24, 12:48
	Но это не ответ на вопрос о bitfield'ах.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (111), 24-Ноя-24, 18:53
	> вопрос о Так, я не антисемит, если что. (вчера) C++ Standards Contributor Expelled For 'The Undefined Behavior Question' https://slashdot.org/submission/17330375/c-standards-contrib...
	Ответить | Правка | Наверх | Cообщить модератору

	204. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:34
	> Есть масочная операция над регистром и есть ячейка памяти. А в чем проблема чтобы расширить битовые поля чтобы они не были только в struct? Ну или почему как member struct'а так можно - а по отдельности ни ни? Вы же понимаете что когда мы хотели это - мы таки заводили struct? Просто печатать было больше. И только.
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

	230. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 18:21
	struct это сущность Битовое поле это дополнительная операция над сущностью. Биты не хранятся.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 12:44
	Это изначально было неудобно и было вкусовщиной.
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

153. "GCC 15 будет использовать стандарт C23 по умолчанию"	–2 +/–
Сообщение от Аноним (153), 24-Ноя-24, 12:26
Успехов GCC конечно, но лучше я буду использовать odin-lang и даже zig-lang уже сейчас.
Ответить | Правка | Наверх | Cообщить модератору

	231. Скрыто модератором	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 18:23
	а я смотрю комедии. Если каждый скажет, что он предпочитает - флейм треснет.
	Ответить | Правка | Наверх | Cообщить модератору

156. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (156), 24-Ноя-24, 12:30
... которое теперь приводит к выводу типа при определении объектов, что позволяет использовать признак "auto" вместо типа для определения типа переменных на основе типа выражения для их инициализации типа всё понятно
Ответить | Правка | Наверх | Cообщить модератору

	213. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:56
	>теперь приводит к выводу типа при определении объектов, что позволяет использовать признак "auto" вместо типа для определения типа переменных на основе типа выражения для их инициализации. Например: "auto y = cos(x);". Русское быдло это не поймёт.
	Ответить | Правка | Наверх | Cообщить модератору

164. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (-), 24-Ноя-24, 13:04
На С++23 я уже видел проекты, а кто-нибудь видел проект на С23?
Ответить | Правка | Наверх | Cообщить модератору

	183. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от ijuij (?), 24-Ноя-24, 14:56
	Пожалуйста, наберитесь терпения! Скоро всё увидите, даже не сомневайтесь! 🌟
	Ответить | Правка | Наверх | Cообщить модератору

	205. "GCC 15 будет использовать стандарт C23 по умолчанию"	–1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:35
	> На С++23 я уже видел проекты, а кто-нибудь видел проект на С23? Учитывая что он финализировался без году неделю как? Coming soon! :D Я вот уже думаю - не заапгрейдить ли мне тут 1 из болванок для моих фирмварей на это :)
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	214. "GCC 15 будет использовать стандарт C23 по умолчанию"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:58
	> Учитывая что он финализировался без году неделю как? Coming soon! :D Да. Например https://github.com/stephenberry/glaze. > Requires C++23
	Ответить | Правка | Наверх | Cообщить модератору

207. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (-), 24-Ноя-24, 16:46
>GCC 15 будет использовать стандарт C23 по умолчанию Это ещё одно доказательство того, что GCC самый передовой в Мире компилятор.
Ответить | Правка | Наверх | Cообщить модератору

211. Скрыто модератором	+/–
Сообщение от Аноним (-), 24-Ноя-24, 16:55
Да здравствует великий Столлман!
Ответить | Правка | Наверх | Cообщить модератору

226. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (-), 24-Ноя-24, 17:44
>Добавлена поддержка подстановки "%b" для обработки двоичных значений в семействах функций printf() и scanf(). Раньше чтобы десятичное число вывести в двоичном виде как делали?
Ответить | Правка | Наверх | Cообщить модератору

	234. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
	Сообщение от Аноним (228), 24-Ноя-24, 18:39
	Самостоятельно формировали строку в буфере и выводили через спецификатор %s.
	Ответить | Правка | Наверх | Cообщить модератору

232. "GCC 15 будет использовать стандарт C23 по умолчанию"	+/–
Сообщение от Аноним (228), 24-Ноя-24, 18:30
А есть где нибудь статистика используемых ассемблерных инструкций тем или иным компилятором?
Ответить | Правка | Наверх | Cообщить модератору

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

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