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

"Релиз набора компиляторов GCC 13"	+/–
Сообщение от opennews (??), 26-Апр-23, 17:09
После года разработки опубликован релиз свободного набора компиляторов GCC 13.1, первый значительный выпуск в новой ветке GCC 13.x. В соответствии с новой схемой нумерации выпусков, версия 13.0 использовалась в процессе разработки, а незадолго до выхода GCC 13.1 уже ответвилась ветка GCC 14.0, на базе которой будет сформирован следующий значительный релиз GCC 14.1... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59038
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Скрыто модератором	–7 +/–
Сообщение от Аноним (1), 26-Апр-23, 17:09
Под Байкал компилируется?
Ответить | Правка | Наверх | Cообщить модератору

	3. Скрыто модератором	+4 +/–
	Сообщение от Жироватт (ok), 26-Апр-23, 17:10
	Тулчейны вроде есть...собери - проверь
	Ответить | Правка | Наверх | Cообщить модератору

	10. Скрыто модератором	–6 +/–
	Сообщение от Аноним (10), 26-Апр-23, 17:37
	а смысл компилировать под байкал?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	39. Скрыто модератором	+1 +/–
	Сообщение от Аноним (39), 26-Апр-23, 19:49
	Чтобы запустить в Qemu-ARM64
	Ответить | Правка | Наверх | Cообщить модератору

	38. Скрыто модератором	+1 +/–
	Сообщение от FF (?), 26-Апр-23, 19:37
	Байкал это попсовый ARM Cortex A, троллишко
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Релиз набора компиляторов GCC 13"	–8 +/–
Сообщение от asdasd (?), 26-Апр-23, 17:09
> разрешение использования constexpr и auto при определении объектов На кой auto в C? В C++ он нужен из-за монструозных template'тов.
Ответить | Правка | Наверх | Cообщить модератору

	4. "Релиз набора компиляторов GCC 13"	+4 +/–
	Сообщение от warlock66613 (ok), 26-Апр-23, 17:13
	Для уменьшения дублирования кода.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (58), 26-Апр-23, 21:31
	И прострела пяток поизящнее, как на JS :)
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Релиз набора компиляторов GCC 13"	+3 +/–
	Сообщение от warlock66613 (ok), 26-Апр-23, 22:01
	> И прострела пяток поизящнее, как на JS :) На самом деле применение автовывода типов может помогать бороться со слабостями системы типов. Например, в C# есть атавизм в конструкции `foreach`: `foreach(ItemType item in collection)` неявно приводит элементы `collection` к типу `ItemType`. Поэтому возможность писать `foreach(var item in collection)` позволяет перенести часть ошибок с этапа выполнения на этап компиляции. В Си тоже есть такие слабости типизации, которые могут быть устранены умелым применением `auto`.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от Аноним (78), 26-Апр-23, 22:06
	> На самом деле применение автовывода типов может помогать бороться со слабостями системы типов. И обувает статический анализатор на возможность проверить баганул ли тут кодер или нет. Если кодер явно заказал тип и он не сощелся, тут почти наверняка зарыт баг. А если там auto написано - оно такой себе catch all. И вон то уже отловить не катит. А чтоб совсем не скучать в сях раньше был auto но это _другой_ auto и означал он иные вещи. А теперь счастливой отладки, и попробуйте угадать какой auto имеется в виду, старый или новые :) > Например, в C# есть атавизм в конструкции `foreach`: `foreach(ItemType item in collection)` > неявно приводит элементы `collection` к типу `ItemType`. Софт на шарпее вообще любит крайне неочевидно баговать, течь и проч и отлаживать его занятие очень на любителя. Неявная автоматика один из замечательных методов прострела себе пяток. > В Си тоже есть такие слабости типизации, которые могут быть устранены умелым > применением `auto`. Например как? Обычно им пользуются чтобы код лаконичнее сделать. Это конечно достигается, но ценой потери декларации намерений кодера в этом куске кода.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Илья (??), 26-Апр-23, 22:51
	> Софт на шарпее вообще любит крайне неочевидно баговать, течь и проч и отлаживать его занятие очень на любителя. Неявная автоматика один из замечательных методов прострела себе пяток. Очень интересно было бы пример услышать. Я думаю, ты выдаёшь желаемое за действительное. Дебаггер работает отлично, средства анализа кода лучшие из всего, что представлено на рынке. Решарпер, рослин. Райдер и visual studio или vocoder как среды разработки. Статическая типизация везде. Есть даже di контейнер, который на этапе компиляции не пропускает забыть регистрацию. Что тебе ещё надо? Чего тебе ещё надо?
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от Аноним (-), 27-Апр-23, 01:14
	> Очень интересно было бы пример услышать. Я думаю, ты выдаёшь желаемое за > действительное. Например малоочевидные утечки памяти в мало-мальски крупных дотнет программах просто норма жизни. И хрен поймешь, GC это протупляет или проблема серьезнее. > разработки. Статическая типизация везде. Есть даже di контейнер, который на этапе > компиляции не пропускает забыть регистрацию. Однако в целом это переросточный неспешный урод с страшноватым синтаксисом и проблемами перфоманса. Вплоть до того что LSE оказалось дешевле купить тиму сишников чем накидывать десятки миллионам тем кто так и не смог обеспечить обещаную латенси. > Что тебе ещё надо? > Чего тебе ещё надо? Потанцевать на могилке всего этого барахла. Что характерно даже майки наверное депрекейтнут это в пользу того же хруста.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Инжиниринг (?), 27-Апр-23, 10:16
	> Например малоочевидные утечки памяти в мало-мальски крупных дотнет программах просто норма жизни. Это не общеизвестный пример. Есть ссылка на баги в таких проектах?
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от InuYasha (??), 27-Апр-23, 17:50
	Я под НДА, но проекты на моно у нас текут. Могу сказать только что там дохрена-дохренища строковых манипуляций.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 27-Апр-23, 23:06
	> Это не общеизвестный пример. Есть ссылка на баги в таких проектах? Те проекты - confidential/proprietary и сослаться на это вообще совсем не вариант. Да, гамно с ломовыми утечками памяти, проблемами перфоманса и кучей багов можно получить и за весьма приличные деньги. А опенсорсных крупных проектов на дотнете я особо и не знаю. Крмое может разве что самого mono. Я вообще не понимаю нахрена оно такое надо. Майки походу тоже, с одной стороны хруст зажмет, с другой веб, и окажется это ни два ни полтора очередным deprecated, все как майкрософт любит.
	Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

	108. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (108), 27-Апр-23, 01:12
	Всегда удивляло что находятся люди, которые избыточный код считают дополнительной проверкой.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	207. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от warlock66613 (ok), 27-Апр-23, 16:49
	> Например как? Например если взять следующий код без авто.     short i = -3;     unsigned short u = i; Тут будет неявное преобразование типа. С авто его не будет.     short i = -3;     auto u = i;
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	237. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (237), 27-Апр-23, 23:10
	>     short i = -3; >     unsigned short u = i; При том если вы написали unsigned вы реально имели в виду намерение поработать с положительными числами и дальнейший код, вероятно, уповал на данное допущение. За вон то - можно варнинг в два счета получить, особенно если вас хватит на -Wconversion. > Тут будет неявное преобразование типа. С авто его не будет. И варнинг за назначение знакового беззнаковому, что явно баг. >     short i = -3; >     auto u = i; А вот тут варнингов не будет, но если вы вон там unsigned писали, вероятно, дальнейшая логика этого хотела, но вы заныкали это намерение и вот тут варнинга уже не будет. Добро пожаловать в мир багов. И спасибо за отличную иллюстрацию как именно можно стрельнуть себе в пятку auto.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Илья (??), 26-Апр-23, 22:39
	> Например, в C# есть атавизм в конструкции 'foreach': 'foreach(ItemType item in collection)' неявно приводит элементы 'collection' к типу 'ItemType'. В c# в обоих случаях с типом не будет проблем. Давай пример, а?
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	5. "Релиз набора компиляторов GCC 13"	+3 +/–
	Сообщение от Жироватт (ok), 26-Апр-23, 17:16
	Для детей, выросших на всяких нескучных язычках с выводм типа при копиляции? Ну чтобы не пугать их компиляторозависимыми {инт, инт_малый, инт_большой, инт_оче_большой, инт_с_перламутровыми_пуговицами, инт_от_майкрософтов}. А может в качестве иллюстрации того, что почти все типы в С так или иначе есть особо интерпретирумое в зависимости от указнного в коде токена, int. А может просто, по приколу, чтобы число-размер от sizeof(х) было нескучным.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	7. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (7), 26-Апр-23, 17:32
	В си всё void* и любые типы это всего-лишь небольшой сахарок компилятора, было бы чем пугать. Мне кажется сомнительной идея перетягивать всё из плюсов, всё равно типизации в языке 0.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Релиз набора компиляторов GCC 13"	–3 +/–
	Сообщение от Жироватт (ok), 26-Апр-23, 17:51
	Ну, указатели (тупо целое положительное число в hex) уже вводит их в ступор. И если с функцией, возвращающее это число, они еще более-менее справляются, и даже могут дать команду освободить занятое по нему, то примитивнейшая арифметика с ним, их уже выводит в кататонический ступор. А ты говоришь чем пугать, чем пугать. > Мне кажется сомнительной идея перетягивать всё из плюсов, Ну, лишний сахарок, если его немного, редко когда откровенно вредным. Особенно если он сможет в распознавание user-defined типо, вроде struct this_is_very_important_self_documented_struct_type_caption_of_piece_userdata_staff, спрятанного в заголовочнике
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от warlock66613 (ok), 26-Апр-23, 22:05
	> указатели (тупо целое положительное число в hex) Oh, my sweet summer child…
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (78), 26-Апр-23, 22:08
	Не пугай кататоника.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Жироватт (ok), 27-Апр-23, 08:16
	Таки шо вы таки говорите...
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	228. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (228), 27-Апр-23, 21:12
	Оно точно положительное? Есть отрицательный указатель? Может просто hex для удобства, а на самом деле указатель и в двоичной и в десятичной и в восмеричной нотации можно написать?
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	265. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 07:10
	Адрес в памяти по определению положителен. Указатель помимо адреса может включать содержимое сегментного регистра, например.
	Ответить | Правка | Наверх | Cообщить модератору

	277. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от warlock66613 (ok), 28-Апр-23, 10:49
	Я бы для начала спросил: а является ли указатель числом (адресом)? И ответ: нет, не является. (Но даже и с адресом уже кстати всё может быть не так просто. Например, он может быть не числом, а парой чисел.)
	Ответить | Правка | Наверх | Cообщить модератору

	282. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 12:54
	> Я бы для начала спросил: а является ли указатель числом (адресом)? И ответ: нет, не является. ISO/IEC 9899:2017 6.2.5 Types 21 Arithmetic types and pointer types are collectively called scalar types. ... Не вижу где стандарт формализует, что такое скаляр, но из математики известно, что это одно число. Указатель это абстракция над адресом, описывает так же и тип адресуемого объекта (в следствии чего инкремент указателя может увеличить адрес на больше чем 1). > (Но даже и с адресом уже кстати всё может быть не так просто. > Например, он может быть не числом, а парой чисел.) С адресом всё достаточно просто на физическом уровне, если иметь представление о шине адреса. Пара чисел для динамического ОЗУ (строка + столбец) окажутся просто разными разрядами одного числа. Если есть преобразование в виртуальные адреса, то на уровне приложений его не видно. Процессор может адресовать ячейку парой регистров, о чём я написал (в DOS-е вроде 20 бит был указатель, сегментный регистр + РОН).
	Ответить | Правка | Наверх | Cообщить модератору

	292. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от warlock66613 (ok), 28-Апр-23, 15:49
	> в DOS-е вроде 20 бит был указатель Не совсем в DOS (а вообще в реальном режиме) и не совсем 20 (мог быть и 20, и 16, и даже 32 бита, причём не в виде единого числа, а именно в виде пары 16-битных чисел), но это уже несколько анахронизм. А из современного в поисках необычных указателей лучше посмотреть на архитектуру CHERI. Но главное, что всё это относится только к указателю во время выполнения. А есть ещё время компиляции, когда даже на "обычных" архитектурах указатель не является адресом. ( > Не вижу где стандарт формализует, что такое скаляр Да вот ровно в процитированной вами строчке и формализует: arithmetic types and pointer types. Nothing more, как говорится. )
	Ответить | Правка | Наверх | Cообщить модератору

	301. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 18:35
	>> в DOS-е вроде 20 бит был указатель > Не совсем в DOS (а вообще в реальном режиме) и не совсем > 20 (мог быть и 20, и 16, и даже 32 бита, > причём не в виде единого числа, а именно в виде пары > 16-битных чисел), но это уже несколько анахронизм. Я так и не понял, зачем повторно вырезаете мои слова про сегментный регистр и регистр общего назначения (РОН) и пишете про два числа. Адрес, по которому процессор читает или пишет, определяется опкодом (полями R/M и SIB) и префиксом смены сегментного регистра, если он есть. В результате декодирования и исполнения команды на шину адреса выставляется одно "число". >> Не вижу где стандарт формализует, что такое скаляр > Да вот ровно в процитированной вами строчке и формализует: arithmetic types and > pointer types. Nothing more, как говорится. Здесь формализован тип указателя. Сказано, что указатель является скаляром, как и целые. Т.е. одно число. Откуда взялось два?
	Ответить | Правка | Наверх | Cообщить модератору

	302. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от warlock66613 (ok), 28-Апр-23, 19:09
	> Адрес, по которому процессор читает или пишет, определяется <...> В > результате декодирования и исполнения команды на шину адреса выставляется одно "число". Ну надо же, какой умный этот ваш процессор. >>> Не вижу где стандарт формализует, что такое скаляр >> Да вот ровно в процитированной вами строчке и формализует: arithmetic types and >> pointer types. Nothing more, как говорится. > Сказано, что указатель является скаляром, как и целые. Не знаю, то ли вы переводите неправильно с английского, то ли ещё что, поэтому переведу: > Arithmetic types and pointer types are collectively called scalar types. > Арифметические типы и типы указателей вместе называются скалярными типами. Это просто определение "скалярного типа", не больше и не меньше. Ни о каких числах тут речи не идёт.
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 20:04
	>> Адрес, по которому процессор читает или пишет, определяется <...> В >> результате декодирования и исполнения команды на шину адреса выставляется одно "число". > Ну надо же, какой умный этот ваш процессор. Вы заявляли про два числа. Откуда они взялись? >>>> Не вижу где стандарт формализует, что такое скаляр >>> Да вот ровно в процитированной вами строчке и формализует: arithmetic types and >>> pointer types. Nothing more, как говорится. >> Сказано, что указатель является скаляром, как и целые. > Не знаю, то ли вы переводите неправильно с английского, то ли ещё > что, поэтому переведу: >> Arithmetic types and pointer types are collectively called scalar types. >> Арифметические типы и типы указателей вместе называются скалярными типами. > Это просто определение "скалярного типа", не больше и не меньше. Ни о > каких числах тут речи не идёт. types - это множественное число. Ни о каком одном типе тут речи не идёт. И арифметический тип - скалярный тип. И указатель - скалярный тип. Может надо еще и scalaris перевести с латыни? Ступенчатый. В единичной системе счисления осталось записать для наглядности. Далее в том же пункте указаны агрегатные (составные) типы: Array and structure types are collectively called aggregate types. "Два числа" это как раз составной тип.
	Ответить | Правка | Наверх | Cообщить модератору

	306. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от warlock66613 (ok), 28-Апр-23, 21:33
	> Вы заявляли про два числа. Откуда они взялись? В программах на Си для реального режима x86 дальние (far) указатели представлены парой шестнадцатибитных чисел — селектором и смещением.
	Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

	308. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 29-Апр-23, 11:05
	>> Вы заявляли про два числа. Откуда они взялись? > В программах на Си для реального режима x86 дальние (far) указатели представлены > парой шестнадцатибитных чисел — селектором и смещением. Вопрос был, откуда это мнение взято. Цитирую IA-32 SDM, Vol 1: 1.3.4 Segmented Addressing ... The following notation is used to specify a byte address within a segment: Segment-register:Byte-address For example, the following segment address identifies the byte at address FF79H in the segment pointed by the DS register: DS:FF79H То есть, _адрес_ ячейки записывается парой чисел, подобная форма записи принята в том мануале. Цитирую Ваше сообщение #277 "является ли указатель числом (адресом)? И ответ: нет, не является." По-вашему, указатель не является адресом, значит к нему "пара чисел" из SDM не применимо. В стандарте Си указатель назван скаляром. Из чего следует, что "в программах на Си для реального режима x86" одно число (значение указателя) загружается в регистровую пару из селектора и РОНа.
	Ответить | Правка | К родителю #306 | Наверх | Cообщить модератору

	345. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (78), 02-Май-23, 03:12
	> В программах на Си для реального режима x86 дальние (far) указатели представлены > парой шестнадцатибитных чисел — селектором и смещением. Интересно насколько вообще то нечто вообще соответствовало каким либо стандартам си.
	Ответить | Правка | К родителю #306 | Наверх | Cообщить модератору

	319. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (319), 30-Апр-23, 09:23
	так адрес в памяти или адрес памяти ?
	Ответить | Правка | К родителю #265 | Наверх | Cообщить модератору

	320. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 30-Апр-23, 10:37
	Адрес ячейки. Ячейка памяти находится в памяти. Русский язык позволяет опускать очевидные из контекста слова, заодно отсеивая башпрограммистов.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (149), 27-Апр-23, 10:09
	>  Ну, указатели (тупо целое положительное число в hex) уже вводит их в ступор. Начитаются такого и потом конпелируют только с -O0 потому, что даже -O1 "бажит" их божественный код...
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	49. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (49), 26-Апр-23, 20:55
	> В си всё void* и любые типы это всего-лишь небольшой сахарок компилятора, было бы чем пугать. В любом языке со статической типизацией типы -- это "всего-лишь небольшой сахарок компилятора". Информация о типах теряется после компиляции, типы не переживают AST. > всё равно типизации в языке 0. 0 в ассемблере.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	60. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (60), 26-Апр-23, 21:36
	> В любом языке со статической типизацией типы -- это "всего-лишь небольшой сахарок компилятора". C++ там есть рантайм инфа о типе для динамического каста.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (78), 26-Апр-23, 22:11
	> Информация о типах теряется после компиляции, типы не переживают AST. Какой-нибудь ubsan очень резко не согласится с тобой. Он очень даже переживает это и прекрасно расскажет в какой переменной с каким типом ты дал маху. Разумеется оверхед на рантайм проверки значений добавится а размер бинаря станет крупнее, за счет хранения вот этих сведений и кода с проверками. Но так можно из сей сделать что-то типа явы или дотнета, если вы это и правда хотели, особенно если asan еще включить :) >> всё равно типизации в языке 0. > 0 в ассемблере. И даже там чуть более чем ноль может быть. Скажем можно проверить что константа лезет в регистр, все такое.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	21. "Релиз набора компиляторов GCC 13"	–2 +/–
	Сообщение от Бывалый смузихлёб (?), 26-Апр-23, 18:34
	Когда в якобы типизированные ЯП вводили подобия auto - иные адепты типизации и параллельно ненавистники недостаточно-типизированного жс с ходу начинали сс.ать кипятком и в три пасти жрать из корыта Дело, похоже, совсем не в детях. А если бы не хотели их пугать - так не показывали бы лишний раз раст
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	143. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от 4рл (?), 27-Апр-23, 09:37
	inttype.h сто лет в обед, а вы до сих пор "платформозависимые" используете?
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	6. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от name (??), 26-Апр-23, 17:31
	>auto в C Вот и настал тот день, когда я больше не хочу писать на Си. Я долго его ждал, но не мог придумать почему.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	8. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от _RORO_ (ok), 26-Апр-23, 17:35
	Даже не из-за остутствия контроля за границами массивов?
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от name (??), 26-Апр-23, 18:47
	А я не пользуюсь массивами :-р Вообще, убогая структура дынных.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Апр-23, 19:30
	Привет мир продолжит работать без auto, не переживай ты так
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (228), 27-Апр-23, 23:20
	формалисты введут обязательное правило использование auto. А так-как у них мозга нет, то и объяснять им бесполезно. Они устали отбиваться от насмешек молодых про застарелость typedef и отсутствие типа для булевой переменной.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от _RORO_ (ok), 26-Апр-23, 19:32
	Без них ты бы даже коммент не смог написать, потому что любая строка это массив букв
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	42. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от name (??), 26-Апр-23, 20:22
	Только лох использует строки-массивы. Самурай юзает связанные письки.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Dzen Python (ok), 26-Апр-23, 21:17
	(((((defun opennet(net(open(net()))))))))
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (119), 27-Апр-23, 04:37
	Интересно, что некие гендерфлюидные нотки здесь есть, но в целом да.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (121), 27-Апр-23, 04:41
	Флюгик, чуток со скобками ошибся. Но в целом простительно.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	63. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (60), 26-Апр-23, 21:43
	<зануда вкл> буквы в букваре <зануда выкл> можно получать доступ к строке через указатель. имя массива это указатель на первый элемент. можно через указатель хранить разреженные строки (символы через один или через два байта - привет интернализация)
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	65. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (60), 26-Апр-23, 21:49
	строка это тип string в С это указатель с определенной дистанцией смещения оканчивающийся null-символом. в C++ это класс с методами в придачу. в rust это тип с типажами в придачу. Так что не любая, а для Вас это массив.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	74. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (74), 26-Апр-23, 21:58
	> А я не пользуюсь массивами :-р Вообще, убогая структура дынных. Блин как же ты пакеты по сети передаешь в портабельном кроссплатформенном виде?
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	141. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от name (??), 27-Апр-23, 09:29
	А зачем массивы при передаче пакетов? Структы, указатели на память.. в каком месте массивы?
	Ответить | Правка | Наверх | Cообщить модератору

	229. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (228), 27-Апр-23, 21:21
	Вероятно подразумевалось, что массив понятен всем ОС и языкам. Передается он как полезная нагрузка на уровне приложений. Хотя для этого существует маршалинг, потому что передавать надо не только общие типы.
	Ответить | Правка | Наверх | Cообщить модератору

	240. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 27-Апр-23, 23:21
	> А зачем массивы при передаче пакетов? Структы, указатели на память.. А указатели на память, типа, не массивы? В сях вообще отличие достаточно маргинальное, можно по индексу, можно по указателю. По индексу порой может быть читаемее, особенно если характерным смещениям дать символические имена. Более того - массив с указанием максимального размера так то помогает статическому анализу и инструментам типа asan/ubsan, сразу видно если лажа вышла. А без этого указания - нет указания ваших намерений и сильно менее понятно, корректно вон то или нет. Одна из тех вещей которые в си сдалали дурно - указатели в довольно большом числе случаев не подлежат полноценному статическому анализу. Из-за отсутствия деклараций намерений кодера, ага. Тяжелые штуки типа asan конечно и такое могут словить зачастую, но это дофига оверхеда, сильное замедление, да и падеж в рантайм хуже чем в компил тайм. > в каком месте массивы? В том же что и указатели на память. Память так то сама массив байтов, внезапно. А чтоб красиво, структурировано и на си - это struct, но вот в провод, воздух или файл его портабельно не пошлешь, чтобы это вышло дешево и сердито.
	Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

	126. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Илья (??), 27-Апр-23, 06:52
	А чем ты пользуешься?
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	140. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от name (??), 27-Апр-23, 09:28
	В общем случае графами. В частных - списками и деревьями.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от _RORO_ (ok), 27-Апр-23, 12:43
	Ну так в графах и деревьях под капотом тоже массив
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от name (??), 27-Апр-23, 13:58
	Лолшто
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 07:13
	Посмотрите исходники malloc().
	Ответить | Правка | Наверх | Cообщить модератору

	286. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от name (??), 28-Апр-23, 14:19
	От меня это не зависит. Я там за границы массива не выйду.
	Ответить | Правка | Наверх | Cообщить модератору

	289. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 15:10
	Зато можно вызвать mmap() и реализовать граф поверх той памяти, заменив указатели индексами. Получится под капотом массив.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (228), 27-Апр-23, 21:27
	не всегда оправдано.
	Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

	9. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от СекторГаза (?), 26-Апр-23, 17:37
	Остаётся подвал?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	11. "Релиз набора компиляторов GCC 13"	+4 +/–
	Сообщение от _RORO_ (ok), 26-Апр-23, 17:43
	Всякие int,long размер которых не определён спецификацией это ни рыба ни мясо. Есть смысл или чётко определять размер (uint32,int32,int64,float32,float64...) или выводить тип автоматически
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	57. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (60), 26-Апр-23, 21:28
	Поэтому Си и завоевал популярность. int - наиболее подходящий для аппаратной платформы. long в два раза длиннее int.   разрядность изменяется, а код остается, надо только сравнивать с границами. если нужно точно, то есть простой способ узнать размер.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Релиз набора компиляторов GCC 13"	+8 +/–
	Сообщение от Аноним (64), 26-Апр-23, 21:46
	> long в два раза длиннее int. Садись, два.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (60), 26-Апр-23, 21:52
	однобайтное целое (англ. tiny int) — 8 бит, -128 ÷ 127; короткое целое (англ. short int) — 16 бит, −32 768 ÷ 32 767; длинное целое (англ. long int, также int32) — 32 бита, −2 147 483 648 (−231) ÷ 2 147 483 647 (231−1); двойное длинное целое (англ. long long int, также large int, big int, int64) — 64 бита, -9 223 372 036 854 775 808 (−263) ÷ 9 223 372 036 854 775 807 (263−1); Википедия. Чтобы быстро. для 32 битной шины.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Релиз набора компиляторов GCC 13"	+4 +/–
	Сообщение от Аноним (-), 26-Апр-23, 22:19
	> Википедия. Чтобы быстро. для 32 битной шины. Небось еще и русская, где это какой-то отсебяша накорябал? А надо было читать стандарты. В стандарте регламентируется только минимальная ширина. Реальная в энной реализации может быть и больше. Более того - почти весь код уверен что в int лезет минимум 32 бита. Хотя по стандарту сказано лишь про не менее 16. И попытавшись вон там для AVR заказать вот это вот для скорости (по стандарту же ок!) можно нехило лаптем щей откушать - при том что формально это будут баги в коде. Ни про какие 32-битные или сколько там еще шины в стандартах вообще ничего не сказано. Как впрочем и про допустим стэк и его использование локальными переменными, и прочие типовые допущения которые ниоткуда не следуют.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от FF (?), 26-Апр-23, 23:09
	в Cortex M int и long 32 бита, а long long уже 64
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	95. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от FF (?), 26-Апр-23, 23:10
	и опять же это компиляторы и задефайнено так, это же программная условность
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (60), 26-Апр-23, 21:58
	#include <stdio.h> void main(){         int a;         long b;         printf("%d %d\n",sizeof(a),sizeof(b));         return; } вывод: 4 8 4 байта и 8 байт соответственно
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	75. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (74), 26-Апр-23, 22:01
	Это хреновые способ доказать что-то. Ваша конкретная машина - не все возможности реализации си на той или иной платформе. Ну вон на AVR можно int как 32 бита сделать. А можно и как 16. Оба варианта, кстати, одинаково валидны по стандарту, второй быстрее, толко де-факто много кода non compliant и вести себя будет криво. Хотя формально это баг именно кривого кода удумавшего что int видите ли может быть более 16 битов, чего никто не обещал.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (60), 26-Апр-23, 22:09
	Профессор, когда-то я это знал, а потом основательно забыл. (с) почти )) Потому что на практике не встречался с этими платформами.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (-), 26-Апр-23, 22:21
	> Потому что на практике не встречался с этими платформами. Ну как бы если мы про стандарты и код, при этом не важно с какими платформами кто встречался. Важно как оно в стандарте определено. И вот с этим на самом деле там довольно так себе, много фривольностей и недоопределенных вещей что ведет к UB.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от Аноним (64), 27-Апр-23, 00:54
	> Потому что на практике не встречался с этими платформами Ну, с 64-битными Виндой и Линухом-то все встречались. На первой long 32 бит, на второй -  64.
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	156. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 27-Апр-23, 11:17
	Эпичнее встречи с int a[sizeof WCHAR]; Когда оно работает в Windows с двухбайтным WCHAR, а потом переносят в Linux и оно вроде работает, но в память не всегда помещается.
	Ответить | Правка | Наверх | Cообщить модератору

	214. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от InuYasha (??), 27-Апр-23, 17:28
	> int a[sizeof WCHAR]; rol, ты мне немного мозг подамажил таким примером ) Но это ещё что! Когда у тебя сетевой протокол завязан на sizeof, начинается веселье в степени N! Сдишь ты такой, никого не трогаешь. И тут коннектится клиент с винды или со смака.
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (228), 28-Апр-23, 00:39
	Маршалинг должен быть.
	Ответить | Правка | Наверх | Cообщить модератору

	268. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 07:36
	>> int a[sizeof WCHAR]; > rol, ты мне немного мозг подамажил таким примером ) Да накосячил с арифметикой. Сейчас не найду ту тему на ЛОРе, массив создавался для задачи типа "посчитать количество каждого возможного символа в тексте" и на Линуксе то ли несколько минут уходил в подкачку, то ли дома работал, а на работе падал.
	Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

	233. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (228), 27-Апр-23, 22:41
	Что оно? 1. WCHAR в винде определен, а linux нет? 2. wchar_t имеет платформозависимый размер?
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	267. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 07:28
	> Что оно? В моём сообщении единственная строка с кодом: int a[sizeof WCHAR]; > 1. WCHAR в винде определен, а linux нет? "переносят в Linux" означает, что код запускают в Linux, адаптируя, при необходимости. > 2. wchar_t имеет платформозависимый размер? "работает, но в память не всегда помещается" является ответом на этот вопрос. Я забыл там 1 << но InuYasha почему-то догадался.
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (211), 27-Апр-23, 16:58
	неа, оно так не работает. оно зависит не только от апаратуры но и от ос. например long: OS    Architecture    Size of "long" type Windows    IA-32            4 bytes     Intel® 64    4 bytes Linux    IA-32             4 bytes     Intel® 64    8 bytes mac OS    Intel® 64    8 bytes
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	274. Скрыто модератором	+/–
	Сообщение от Аноним (-), 28-Апр-23, 10:08
	>void main() Чо за дичь? Так пишут старые пердуны учившиеся писать 180-90 гг. на каких-то компиляторах под мастдай.
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	169. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от InuYasha (??), 27-Апр-23, 12:45
	ага, до первого хардкода или ошибки с sizeof()
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	170. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от InuYasha (??), 27-Апр-23, 12:48
	Это был закос под кроссплатформенность и одновременно упрощение, который в итоге вылился в гигантский гемор. Я тоже пишу целый огромный хэдер только для стандартизации типов. Причём, ровно так как ты и написал. Потому что меня бесят _t для примитивов.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	17. "Релиз набора компиляторов GCC 13"	+3 +/–
	Сообщение от Аноним (108), 26-Апр-23, 18:20
	Он нужен чтобы не писать одно и то же и не ошибаться. Когнитивная нагрузка ниже, читается легче, api и abi не меняет, сплошные преимущества.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	28. "Релиз набора компиляторов GCC 13"	+8 +/–
	Сообщение от soomrack (ok), 26-Апр-23, 18:47
	auto это очень хорошее ключевое слово, если им правильно пользоваться. Оно позволяет делать код менее прибитым к типам данных и более простым. Только нужно им праивльно пользоваться. Вот, например, писать     auto idx = 0; не стоит, т.к. это будет int, а не long int, и не unsigned int, и т.д. А писать     auto alice = person; очень даже правильно, т.к. тип alice будет такой же как у person и можно будет спокойно менять тип person при рефакторинге, не затрагивая эту часть кода. Да и ошибиться с именем структуры тоже не получится, т.к. тут просто auto.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	32. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (32), 26-Апр-23, 19:08
	Или тебе нужен был определенный тип alice, а теперь кто-то "порефакторил" код изменив person и у тебя теперь везде потенциальные ошибки, но которые не всплывают на этапе компиляции.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от soomrack (ok), 26-Апр-23, 19:25
	Если нужен прям определенный тип, то там auto ставить, конечно, нельзя. auto это доп возможности, удобные, но как и все в ЯП оно дает много вариантов как выстрелить себе в ногу.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (32), 26-Апр-23, 20:38
	В zig просто выводится тип автоматически, без этих костылей. В принципе auto - это необходимый, к сожалению, костыль в С++.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Релиз набора компиляторов GCC 13"	–2 +/–
	Сообщение от Аноним (60), 26-Апр-23, 21:20
	Если это так, то си перестает быть языком статической типизации.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	158. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 27-Апр-23, 11:24
	> Если это так, то си перестает быть языком статической типизации. Веет башпрограммистами автономных операционных систем. Статическая типизация - это когда тип фиксируется на этапе трансляции.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (-), 26-Апр-23, 22:33
	> А писать >     auto alice = person; > очень даже правильно, т.к. тип alice будет такой же как у person > и можно будет спокойно менять тип person при рефакторинге, А потом мы не узнаем случайно что вооооооон там код не умел на самом деле работать с новым вариантом person, но "как живой" благодаря auto? И нормальные люди для этого делали typedef'ы на какойнибудь person_t который определен как эвона какой struct, например. А при рефакторе ему поля добавить, снести, огрести все матюки компилера на обращение к отсутствюущему полю, например, сразу узнав где баг рефактора. И чего там улучшит auto кто б его знает. > не затрагивая эту часть кода. При рефакторе это отличная заявка на залет. > Да и ошибиться с именем структуры тоже не получится, т.к. тут просто auto. А зачем ошибаться именем структуры? Завести person_t какой и всегда его везде давать (something_t это такой полуофициальный convention практикуемый многими кодерами для показа что вот это словно именно тип данных а не что-то еще). При этом указание типа может быть лаконичным но несущим в себе инфо о намерениях кодера, в отличие от "auto". И на вид это выглядит как шанс прострелить пятку лишний раз, сделав код менее анализируемым и спрятав баги, особенно при рефакторе.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	227. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (228), 27-Апр-23, 21:09
	> auto alica = person; Это издевательство над оператором присвоения. А какое значение у person и нужно ли оно в alisa? Чем typedef не угодил? Си уже определяет типы неявно? Переписывать учебники, справочники, вики?
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	37. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Апр-23, 19:34
	Не пользуйся
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	46. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (60), 26-Апр-23, 20:49
	> На кой auto в С? Тип auto был всегда по умолчанию. int a; это auto int a;
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	51. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (60), 26-Апр-23, 20:56
	Или они ушли от статической типизации и auto может быть чем угодно? у меня gcc v8.3 на auto a; предупредил, что будет считать а целым типом.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 26-Апр-23, 22:36
	> Или они ушли от статической типизации и auto может быть чем угодно? Не ушли но это именно вот тот другой auto, как в новых плюсах. > у меня gcc v8.3 на auto a; предупредил, А он разве умел C23? (C2x)
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (60), 27-Апр-23, 00:52
	> вот тот другой auto, как в новых плюсах. Значит auto это то что может реализовать компилятор, а не то что хочет программист. На вопрос почему, будет ответ я так вижу. Вы же не определили четко.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Релиз набора компиляторов GCC 13"	+3 +/–
	Сообщение от Аноним (146), 27-Апр-23, 09:45
	А что, в Си запретили использование макросов? Вполне может там оказаться удобно пользоваться `auto`: #define SWAP(a,b) do { auto t = a; a = b; b = t; } while(0)
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	242. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (242), 27-Апр-23, 23:38
	> #define SWAP(a,b) do { auto t = a; a = b; b > = t; } while(0) Смотрите дети как себе метко в пятки стрелять, да не просто а в прыжке, с заподвыподвертом, левой рукой в правую. С перезарядкой арбалета на лету. Или отличный пример как делать не надо. Хинт: в этом макро радикально не хватает как минимум скобочек. Вы когда его задефайнили думали лишь про 1 юзкейс но caller может делать дохрена того о чем вы не подумали. Как вам например SWAP(x++, ++y)? А если SWAP(++x, y++)? Это одно и то же или нет? :) А может, там выражение какое? И вон то макро вам такие интересные side effects посчтитает... Более того, а что если у a и b тип разный? У том чудо макросе это не проверяется вообще никак, и есть шансы выпилить варнинг о том что вы толкаете слона в клетку для канарейки. А то что вы хотели на самом деле _Generic называется, и таки начиная с C11 - есть. При том там это можно более культурно оформить. Во первых без залета на непонятки в вон тех случаях, во вторых можно более ограниченно указать какие типы эта штука может стрескать. А с вот таким макро вы соберете сильно больше багов чем могли бы себе представть. И так вполне реально вулн в коде повесить, хотя на вид все ЗБС.
	Ответить | Правка | Наверх | Cообщить модератору

	269. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 08:09
	> Как вам например SWAP(x++, ++y)? А если SWAP(++x, y++)? Не надо так писать. Видно же, что это макрос.
	Ответить | Правка | Наверх | Cообщить модератору

	330. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 30-Апр-23, 23:35
	> Не надо так писать. Видно же, что это макрос. Иногда очень соблазнительно воткнуть туда вот именно некое выражение. Из соображений лаконичного, читаемого, простого в восприятии кода. Потому что если вместо этого сделать костыль из нескольких малоочевидных строк более удачным решением это тоже не станет. Если макрос писал не полный дилетант, макро будет вести себя приличнее, хоть и ценой разбавки макроса скобками. А, да, знаете, чтобы багов в коде было меньше, код должен быть лаконичным, выразительным и простым в понимании. И макросы имеет смысл использовать разве что для этого. В плане допустим оптимизации кода они давно сравнялись с функциями. Можно даже анти-оптимизацию получить - технологии типа LTO легко могут заинлайнить небольшой кусок функции а не ее всю, упростив и ускорив все в цать раз. С макро это получается значительно хуже. Итого: показан пример как испортить жизнь оптимизеру и влепить неочевидных багов.
	Ответить | Правка | Наверх | Cообщить модератору

	339. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 01-Май-23, 10:13
	>> Не надо так писать. Видно же, что это макрос. > Иногда очень соблазнительно воткнуть туда вот именно некое выражение. "Я захотел нарушить конвенцию, но виноват вон тот".
	Ответить | Правка | Наверх | Cообщить модератору

	346. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 02-Май-23, 03:29
	> "Я захотел нарушить конвенцию, но виноват вон тот". В реально требовательных штуках, типа MISRA, насколько я помню, конвенция такова что на использование макро накладываются крайне жесткие ограничения, так что вон то использование (function-like macro) будет под запретом. Во избежание вот этого вот всего вообще крайне радикальным методом. А ваша конвенция - вообще чья и как сформулирована? Она задекларена в каком-то стандарте или устоявшемся гайдлайне? У реально критичных предпочитают совсем не связываться с макро по возможности. Менее радикальные, которые хотят более читаемый код но не баги, обучаются обкладывать козлаW матом^W^W макросы скобками. И таки если вместо 1 строки (т.е. макро с 2 выражениями) станет 3 - код станет более рыхлым и это тоже испортит его восприятие. Может прибавиться ситуаций "функция не умещается на экран", что тоже баги вызовет. А, да, у тех кому критично есть довольно жесткие лимиты на размеры и сложность функций, так что +3 строки тоже так то трабла. Есть еще вызовы функций с side effects но там можно откушать даже в аргументах функции и тут уж програмер должен голову задействовать. С другой стороны для себя я все же позволил некое более широкое использование макросов. Даже для проверок некоторых вещей компилтайм, как это делать можно подсмотреть в линукскернеле. Компилтайм предвычисления и проверки все же прикольны и ничего не стоят в рантайме.
	Ответить | Правка | Наверх | Cообщить модератору

	291. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от Аноним (291), 28-Апр-23, 15:17
	> Хинт: в этом макро радикально не хватает как минимум скобочек это макро было иллюстративным и только. > Как вам например SWAP(x++, ++y)? Никак. Написавший такие аргументы в таком макро -- идиот, лечить бесполезно. Выстрелить себе в любую часть тела на Си не было проблемой вообще никогда. Макросы от того и пишут большими буквами, чтобы те, кто ими пользуются понимали "хрупкость" и осознавали возможности сайд-эффектов. > А то что вы хотели на самом деле _Generic называется, и таки начиная с C11 - есть. Без генерика приведённый вариант обмена значений будет работать даже с любой стркутурой, а как он будет с генериком -- вопрос интересный. Не всё ограничивается только вариантами целых чисел. > Смотрите дети ... Проецирование своих комплексов наружу? Ну-ну
	Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

	331. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 30-Апр-23, 23:53
	> это макро было иллюстративным и только. Зачем подавать пример как делать не надо, особенно если есть куда менее стремные генерики? > Никак. Написавший такие аргументы в таком макро -- идиот, лечить бесполезно. Иногда тем не менее для лаконичности кода удобно выражение воткнуть в аргумент. Отдельные 2 строки для чего-то в этом духе ведет > Выстрелить себе в любую часть тела на Си не было проблемой вообще никогда. Не значит что надо таскать заряженный пистолет снятый с предохранителя в повседневной жизни, пятки не одобряют такой маневр. > Макросы от того и пишут большими буквами, чтобы те, кто ими пользуются > понимали "хрупкость" и осознавали возможности сайд-эффектов. Их можно сделать значительно менее хрупкими воткнув пару скобок. Да и вон то лучше наверное функцией делать. По перфомансу и коду врядли проиграет. >> А то что вы хотели на самом деле _Generic называется, и таки начиная с C11 - есть. > Без генерика приведённый вариант обмена значений будет работать даже с любой стркутурой, Да. Но это тоже некоторые грабли. Структуры могут быть довольно большие (в этом случае, разумеется, место для них может выделяться динамичеси). А то что вы хотели аллоцировать на автомате темпарь вон того размера - это еще вопрос! В стеке же награда за нехватку памяти это сразу крах. Без возможности что-то сделать. Да, в struct можно и массивы вогнать и проч. И это тот случай когда вы таки можете скормить сям массив именно by-value, и вот вообще совсем не факт что вы именно ЭТО хотели. Потому что это конечно сработает но перфоманс всего этого будет хуже чем у жабы с дотнетом если массив большой. В случае struct'ов и желания их свапнуть это тот случай когда возможно вы хотели на самом деле указатели на struct и свапнуть именно их. А у вас это скорее всего нечто типа memcpy будет (да, компилер может сам его или что-то подобное вызвать в случае struct). Это даже по своему удобно когда массивы можно лихо приравнивать, но лучше явно понимать смысл этого действа, особеенно если массив не особо маленький. > а как он будет с генериком -- вопрос интересный. Не всё > ограничивается только вариантами целых чисел. На самом деле интересная тема, в вашем спиче что-то есть. > Проецирование своих комплексов наружу? Ну-ну Это проецирование коллективного разума вон тех мощных кодеров на ваши бренные головы.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от n00by (ok), 27-Апр-23, 11:04
	>> разрешение использования constexpr и auto при определении объектов > На кой auto в C? В C++ он нужен из-за монструозных template'тов. По ссылке: #define dataCondStoreTG(P, E, D)             \   do {                                       \     auto* _pr_p = (P);                       \     auto _pr_expected = (E);                 \     auto _pr_desired = (D);                  \     bool _pr_c;                              \     do {                                     \       mtx_lock(&_pr_p->mtx);                 \       _pr_c = (_pr_p->data == _pr_expected); \       if (_pr_c) _pr_p->data = _pr_desired;  \       mtx_unlock(&_pr_p->mtx);               \     }  while(!_pr_c);                        \   } while (false) Без auto тип аргумента приходится передавать аргументом макроса.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	244. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (228), 27-Апр-23, 23:48
	> В C++ он нужен из-за монструозных template'тов. Говорите прямо - запутались. auto как палочка выручалочка. Что получится не важно, главное скомпилировать.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	262. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (262), 28-Апр-23, 04:26
	> На кой auto в C? В C++ он нужен из-за монструозных template'тов. Трольнул, круасафчег ! Все отписавшиеся выше не знают не то что сей, их к компу мамка подпускать не должна пока к&r на зубок не выучат.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

12. "Релиз набора компиляторов GCC 13"	–1 +/–
Сообщение от Tita_M (ok), 26-Апр-23, 17:44
> bool, false и true Кто лучше знает, это получается, что в новом стандарте Си появился полноценный булевый тип? Что мешало добавить его раньше?
Ответить | Правка | Наверх | Cообщить модератору

	14. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (14), 26-Апр-23, 17:51
	Не особо нужен. char и значений 0, 1 всегда хватало. Си, в отличие от C++ - это не о абстракциях.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Tron is Whistling (?), 26-Апр-23, 22:20
	Конкретно с char(byte) ты бахнешься на процах, которые требуют выравнивания при обращении к памяти. Ну или займёшь 64-битное слово на каждый буль.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (97), 26-Апр-23, 23:12
	Плохому танцору известно что мешает. В 2023 жаловатся на вышеперечисленное просто смешно.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Пользователь чебурнета (?), 27-Апр-23, 05:59
	Можно юнионом укладывать в чар 8 булей. А выравнивание -- это проблема компилятора.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	133. "Релиз набора компиляторов GCC 13"	–2 +/–
	Сообщение от Аноним (133), 27-Апр-23, 08:46
	Чо... хранить логические переменные в одном бите? Ну можно, конечно, но изврат какой-то.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (137), 27-Апр-23, 09:05
	погугли, что такое программирование, а потом про битовые поля
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от InuYasha (??), 27-Апр-23, 18:15
	И тут аноны откроют для себя флаги. )
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (228), 27-Апр-23, 23:47
	они всегда были затратные если только одно битовое поле. Хард программирование исключается из утверждения.
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	177. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Пользователь чебурнета (?), 27-Апр-23, 13:30
	Нет, лучше в 64. Параллельно запивая смузи. Обычный приём, который преподаётся в старших классах при изучении страктов и юнионов.
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	275. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Срыватель покровов (?), 28-Апр-23, 10:23
	Мало в каких школах дают Сишечку. В основном дают Питон сейчас. Си скорее на первом курсе изучают.
	Ответить | Правка | Наверх | Cообщить модератору

	314. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Пользователь чебурнета (?), 29-Апр-23, 17:20
	Верно, но это уже неустранимые проблемы нынешней системы образования, обсуждать которые -- значит скатиться в политоту. Так-то по-нормальному в младших классах должны быть основы информатики -- алгоритмизация, простейшая формальная логика с соответствующими задачами. В средних классах -- Питон, в старших -- Джава/Си/Го/Хруст на выбор и основы системного администрирования.
	Ответить | Правка | Наверх | Cообщить модератору

	317. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (317), 30-Апр-23, 01:18
	В младших - Assembler, в средней школе - Brainfuck, в старших - Rust! По выпуску устраивать в M$ архитекторами ядра.
	Ответить | Правка | Наверх | Cообщить модератору

	318. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Пользователь чебурнета (?), 30-Апр-23, 01:36
	Молодец, теперь попробуй осуществить свой педагогический эксперимент, начав с собственных детей. Если, конечно, успел настрогать.
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (245), 27-Апр-23, 23:59
	> Можно юнионом укладывать в чар 8 булей. Лучше struct'ом. Проблема однако в том что это хотя и сэкономит RAM под були, сгенерит лишний код на RMW этого счастья. Результат как правило медленнее работает и жирнее по коду, так что особого профита с этого лайфхака не наступает.
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	305. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Пользователь чебурнета (?), 28-Апр-23, 20:36
	Код будет жирнее -- ну может быть, от компилятора и опций зависит. Что будет медленнее -- не верю. В крайнем случае можнно просто создать переменную типа int8_t, и для манипуляций с конкретным битом использовать операции по маске. И в /** камментах **/ не забыть написать, для чего используется каждый бит :)
	Ответить | Правка | Наверх | Cообщить модератору

	332. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 01-Май-23, 00:13
	> Код будет жирнее -- ну может быть, от компилятора и опций зависит. Чтобы хранить 8 булей в 1 байте... внезапно, выставить бит в 1 более не немедленное присвоение переменной значения, типа mov r0, #1, а уже вполне себе RMW байта (или что там) - надо прочитать текущее значение, пропатчить, выставив в 1 нужный бит и сохранить назад. И обращений в память 2. Если неаккуратно делать можно еще и на гонки нарваться, если не байт а что-то крупнее и доступ не атомарный был. > Что будет медленнее -- не верю. А таки - может. И бывает. > В крайнем случае можнно просто создать переменную типа int8_t, > и для манипуляций с конкретным битом использовать операции по маске. Так вы и тут на RMW пролетаете, вы ж не можете просто заассайнить ему нужное, еще и предыдущее сохранять надо! Иначе упакованые флаги отправятся нафиг. > **/ не забыть написать, для чего используется каждый бит :) Я пробовал и так и сяк. В 1м случае компилер врезает RMW, автоматически, в 2м случае еще и самому мануально надо, совсем уж хрень, возни больше, результат тот же (правда, u8 проще портабельно слать в IO/file/etc vs struct). А если bool как инт оформлен, RMW не надо, ведь там 1 бит, он сразу известен. Не надо чтение старого значения и маски, внезапно. Классический разгон скорости выполнения за счет большего потребления RAM.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от oficsu (ok), 26-Апр-23, 23:58
	Серьёзно, char в качестве bool? Чтобы strict aliasing многого о себе не возомнил? Типичный такой эффективный Си
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	238. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (228), 27-Апр-23, 23:13
	Поэтому в добром Си, на котором писали ОС, и не было этого типа. Была логика: 0 и всё остальное. И можно выбирать для хранения выровненный тип. Но пришло другое поколение и появился bool и auto (
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Релиз набора компиляторов GCC 13"	+3 +/–
	Сообщение от Аноним (137), 27-Апр-23, 09:00
	то чувство, когда маленькие дети не знают про stdbool.h, но рассказывают всем о том, как всегда было
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	15. "Релиз набора компиляторов GCC 13"	+7 +/–
	Сообщение от Жироватт (ok), 26-Апр-23, 17:57
	[ ] Деды (Ритчи и Керниган) не пользовались, и тебе не надо. [ ] Не писали с валио-трулио, неча и начинать. [ ] Нуля и единицы хватит всем. [ ] Зачем тебе тип, который всего 1 бит, если быстрее юзать выровненные по размеру регистра целые? [ ] А для поля таких флажков тем более выровненные по регистру слово/полуслово, да в десятичном виде! [ ] Так быстрее же! [ ] Зачем терять 7 бит на мусор, когда нужен всего 1? [ ] Читаемый код должен быть тому, кто сидит около регистров, а не мимо-пацану с тремя классами алгола церковно-фортановой школы! ----- Выбирай любой набор причин.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	18. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от xsignal (ok), 26-Апр-23, 18:20
	А зачем он нужен? По-моему 0/1, проще чем false/true.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	40. "Релиз набора компиляторов GCC 13"	+3 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Апр-23, 20:11
	Разная смысловая нагрузка (типы они для людей): получается ты своим болевым типом можешь делать тоже что с целым числом (складывать, умножать и и.п.) - зачем это нужно? Ты можешь возразить, что можно просто так не делать, но тогда мы перекладываем дополнительные поверки на погромите, а ему и так есть над чем думать.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (60), 26-Апр-23, 21:15
	0/что_угодно_целое for(int i=10;i;i--){ //тело } Лучше так не писать
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	67. "Релиз набора компиляторов GCC 13"	+3 +/–
	Сообщение от Аноним (74), 26-Апр-23, 21:51
	> А зачем он нужен? По-моему 0/1, проще чем false/true. Например: uint8_t var1 = 256; if (var1) do_something(); // Хоть var1 не ноль на вид, там 0 и сюда не попадем! bool var1 = 256; if (var1) do_something(); // А вот тут будет вызвано (var1 == true) Секрет в том false залекларен как 0, true как 1, а все что больше обрубается при матеметике до 1. И в принципе можно при статическом анализе варнинги кидать если там более 1. Меньше места для прострела пяток в целом. Просто более специфицированный под задачу begavior, более уместный.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	106. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от _kp (ok), 27-Апр-23, 01:03
	>>uint8_t var1 = 256 На подобное заведомое переполнение gcc ругается. И когда из большего типа в меньше без приведения типа присваивают, тоже ругается. Про bool - верно.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (123), 27-Апр-23, 05:58
	> На подобное заведомое переполнение gcc ругается И это если повезёт. Недавно искал проблему в коде, где > printf("%d == %d (%d)\n", a, b, a == b); выводило то ли "9 == 11 (1)", то ли "11 == 11 (0)" просто из-за такого вот неопределённого поведения где-то рядом в коде, после которого компиятор получил карт-бланш на любые извращения в целях копеечной оптимизации.
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 28-Апр-23, 00:08
	> На подобное заведомое переполнение gcc ругается. Это был простейший пример. В реальном коде будет нечто ближе к: uint8_t var1 = 255; ... var1++; if (var1) ... // Ну и вот кто тут про ноль из-за mod(2^8) math подумает? :) ...и на это ругаться уже не будет в общем случае. > И когда из большего типа в меньше без приведения типа присваивают, тоже ругается. Если кто храбрый -Wconversion ему в руки, узнаете много нового о своем коде и его (без)глючности и (без)опасности в плане работы с целыми числами. > Про bool - верно. Его все же специально сделали для логических выражовываний, с inеeger'ами это не сколько более стремное занятие.
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	276. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от _kp (ok), 28-Апр-23, 10:23
	> Если кто храбрый -Wconversion ему в руки, Да, 90% бестолковых предупреждений, но для своего кода, так использую, иногда помогает же. Но оно не отлавливает опечатки с присвоеним разных типов, и если типы совпадают по размеру, то по мнению компилятора сойдёт и так.
	Ответить | Правка | Наверх | Cообщить модератору

	333. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (237), 01-Май-23, 00:30
	> Да, 90% бестолковых предупреждений, Вообще-то вполне толковых, а то что часто прокатывает и так - на самом деле без гарантий и благодаря вот этой штуке дурных багов математики отловлено немеряно. А где ну вот очень надо что-то странное - явно кастовать, не халявить. Хотя система типов в си все же весьма специфичная, и вон то лишь хайлайтит это дело, не более. > но для своего кода, так использую, иногда помогает же. Сильно повышает качество кода. И я про него узнал от Ian Colett - автора LZ4, в его бложике о том как писать код качественнее и надежнее. > и если типы совпадают по размеру, то по мнению компилятора сойдёт и так. Это какой-то совсем нишевой случай. Для pointer vs integer вопли есть, struct'ы логично юзать через typedef'ы и так чужой структ совсем скормить без явного желания нереально.
	Ответить | Правка | Наверх | Cообщить модератору

	342. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от _kp (ok), 01-Май-23, 10:33
	>> Да, 90% бестолковых предупреждений, > Вообще-то вполне толковых, Вообще то, в первую очередь интересует отлов ошибочного присваивания не тому типу, хоть и того размера, а не приведения типов. Хотя в коде предназначенном для сборки для 32 и 64 битных систем, грабли найдутся и там. Но, поскольку лучше по максимуму отловить проблемы на стадии компиляции, а не из багрепортов, то мне более приемлимы  "бестолковые" предупреждения. И исходник считается вменяемым, если нет предупреждений при включении практически всех опций, кроме Wpedantic.
	Ответить | Правка | Наверх | Cообщить модератору

	347. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (-), 02-Май-23, 03:43
	> Вообще то, в первую очередь интересует отлов ошибочного присваивания не тому типу, > хоть и того размера, а не приведения типов. А что это за ситуации вообще? Мной это не распознается как какая-то типовая проблема, чтобы "в первую очередь" волновало. Нельзя ли конкретных примеров как, где и почему это является заметной проблемой? > Хотя в коде предназначенном для сборки для 32 и 64 битных систем, > грабли найдутся и там. В нормально написаном портабельном коде там вообще грабель не должно быть. Для себя я предпочитаю C99 и конкретные размеры типов, для точно определенного диапазона значений, так что платформа либо предоставляет мне ЭТО либо "out of luck" (с 99го года почти четверть века прошла). > Но, поскольку лучше по максимуму отловить проблемы на стадии компиляции, а не > из багрепортов, то мне более приемлимы  "бестолковые" предупреждения. Я даже false alarm статических анализаторов затыкаю. Потому что не прочь поразвлечься всяким микроконтроллерным и управляющим и последнее что я хочу это баги в таких применениях. В этом месте параноидальные варнинги и статический анализ очень хорошая идея. > И исходник считается вменяемым, если нет предупреждений при включении > практически всех опций, кроме Wpedantic. Я переживаю как минимум Wall, Wpedaitic, Wconverson и как минимум cppcheck еще. Если кто-то из них недоволен, это еще не релизное качество.
	Ответить | Правка | Наверх | Cообщить модератору

	349. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от _kp (ok), 02-Май-23, 12:35
	>> Вообще то, в первую очередь интересует отлов ошибочного присваивания не тому типу, Это считай руко%опство в проектах которые пишут несколько человек, и особенно в разное время, и оно плохо плохо обнаружимо, и может даже вполне работать.. пока не тронешь. > В нормально написаном портабельном коде там вообще грабель не должно быть. Чужой код в принципе не бывает нормальным, и особенно тот в котором попросили исправить "мелочи" или доработать. Шутка, но с долей правды.
	Ответить | Правка | Наверх | Cообщить модератору

	352. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (58), 07-Май-23, 07:39
	> Это считай руко%опство в проектах которые пишут несколько человек, и особенно в > разное время, и оно плохо плохо обнаружимо, и может даже вполне > работать.. пока не тронешь. Мне пример этого интересен, как бы это могло выглядеть. Потому что сходу баг такого типа не припоминается особо. И хотелось бы понять как и почему это образуется и (если это выглядит правдоподобно) как этого можно было бы избегать. > Чужой код в принципе не бывает нормальным, и особенно тот в котором > попросили исправить "мелочи" или доработать. Шутка, но с долей правды. На самом деле чужой код бывает очень разным. От г-на до мегарулеза. При том иногда все и сразу, за некоторый код хочется наградить кодера медалью и расстрелять.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Ванёк (?), 27-Апр-23, 02:14
	Если использовать uint8_t как bool, то производительность упадёт. Лучше использовать uint32_t - производительность выше.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	122. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (123), 27-Апр-23, 05:55
	> Лучше использовать uint32_t - производительность выше А если использовать 64 байта и выравнивать на 64 байта, то автоматом избавимся ещё и от проблем с мультипроцессорностью из-за доступа нескольких ядер к одной строке кеша.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от n00by (ok), 27-Апр-23, 11:46
	А что там такое может храниться может на практике, что разные ядра лезут в смежные ячейки?
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от _kp (ok), 27-Апр-23, 11:17
	> Если использовать uint8_t как bool, то производительность упадёт. Лучше использовать uint32_t > - производительность выше. Для intel 32bit - да. А других архитектурах может быть быстрее.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	190. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Ванёк (?), 27-Апр-23, 14:59
	На x86_64 операции с uint32_t будут быстрее, чем с uint8_t и uint16_t.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от фф (?), 27-Апр-23, 16:25
	а на AVR?
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от _kp (ok), 27-Апр-23, 17:12
	> а на AVR? Вы сами догадываетсь. На Cortex и Risc-v 32bit 8/16 битный bool быстрее 32х битного.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 27-Апр-23, 18:15
	> На x86_64 операции с uint32_t будут быстрее, чем с uint8_t и uint16_t. Когда будут и кто обещал? Пока операции с регистрами занимают одинаковое количество тактов (uint16_t не беру в расчёт, это почти не используют), а чтение из памяти в сумме быстрее для компактных данных.
	Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

	231. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Ванёк (?), 27-Апр-23, 22:04
	> Когда будут и кто обещал? См. документацию по ассемблеру x86_64.
	Ответить | Правка | Наверх | Cообщить модератору

	271. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 08:40
	>> Когда будут и кто обещал? > См. документацию по ассемблеру x86_64. Зачем я буду смотреть всякую чепуху, какую Вы и процитировать стесняетесь? Я смотрю 64-ia-32-architectures-optimization-manual.pdf (см. цитату в №222), AMD_Athlon_Processor_x86_Code_Optimization_Guide.pdf и Software Optimization Guide for AMD Family 17h Processors-55723_3_01_0.zip
	Ответить | Правка | Наверх | Cообщить модератору

	222. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от n00by (ok), 27-Апр-23, 18:21
	>> Если использовать uint8_t как bool, то производительность упадёт. Лучше использовать uint32_t >> - производительность выше. > Для intel 32bit - да. А других архитектурах может быть быстрее. Из относительно современных нашёл такое только для Atom (не путать с Silvermont и более новыми - 45 nm Intel Atom processors introduced Intel Atom microarchitecture. The same microarchitecture also used in 32 nm Intel Atom processor) D.3.3.5 Parameter Passing Due to the limited situations of load-to-store forwarding support in Intel Atom microarchitecture, param- eter passing via the stack places restrictions on optimal usage by the callee function. For example, “bool” and “char” data usually are pushed onto the stack as 32-bit data, a callee function that reads “bool” or “char” data off the stack will face store-forwarding delay and causing the memory operation to be re- issued. Compiler should recognize this limitation and generate prolog for callee function to read 32-bit data instead of smaller sizes. Assembly/Compiler Coding Rule 18. (MH impact, M generality) For Intel Atom processors, “bool” and “char” value should be passed onto and read off the stack as 32-bit data.
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

	247. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 28-Апр-23, 00:12
	> Если использовать uint8_t как bool, то производительность упадёт. Лучше использовать uint32_t > - производительность выше. Вот прям так универсально? Ну попробуйте свой совет на AVR. И получите пролет по скорости в разы. Компилеру виднее как bool оформить потребно на его платформе в вон тех гарантиях. Переумничать компилер? Вы скорее пятки себе прострелите с таким уровнем знаний.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	151. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от fidoman (ok), 27-Апр-23, 10:24
	"uint8_t var1 = 256;" И в этом весь C. Сделать для быстрого косособачинга кривую функцию компилятора (обрезание типов молча) и гору ad-hoc библиотечных функций. Заявить этот набор "стандартом". 30 лет со всем этим мяснить, порождая горы прог и утилит, дырявых в самых неожиданных местах. Через 30 лет начать пытаться сделать из этого Паскаль с C-синтаксисом.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	184. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Пользователь чебурнета (?), 27-Апр-23, 14:22
	> И в этом весь C. Сделать для быстрого косособачинга кривую функцию компилятора > (обрезание типов молча) и гору ad-hoc библиотечных функций. Заявить этот набор > "стандартом". 30 лет со всем этим мяснить, порождая горы прог и > утилит, дырявых в самых неожиданных местах. Через 30 лет начать пытаться > сделать из этого Паскаль с C-синтаксисом. А теперь ещё раз и по-русски.
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от _ (??), 28-Апр-23, 05:23
	дитё порвало ( | )  :-D сию конструкцию засунуть в компилятор и понять что не собеётся, ума (предсказуемо) - не хватило :)
	Ответить | Правка | Наверх | Cообщить модератору

	272. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 08:50
	И соберётся и запустится. Эффект окажется для некоторых неожиданным. Особенно для перепутавших компилятор с линкером.
	Ответить | Правка | Наверх | Cообщить модератору

	334. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (237), 01-Май-23, 00:31
	> сию конструкцию засунуть в компилятор и понять что не собеётся, ума (предсказуемо) > - не хватило :) Соберется, но в современных компилерах warning выдаст.
	Ответить | Правка | К родителю #264 | Наверх | Cообщить модератору

	249. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 28-Апр-23, 00:14
	> И в этом весь C. Сделать для быстрого косособачинга кривую функцию компилятора > (обрезание типов молча) Не угадал, де факто там варнинг в современных компилерах будет. Но как утрированый пример сойдет, влом было кодить обман варнинга в утрированом примере, извини. > утилит, дырявых в самых неожиданных местах. Через 30 лет начать пытаться > сделать из этого Паскаль с C-синтаксисом. Где там и чего от паскаля вообще? Это я как прогавший на паскале спрашиваю.
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	23. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (23), 26-Апр-23, 18:35
	Он уже был в С11 как _Bool, сейчас stdbool.h решили деприкейтнуть. Сам bool вообще штука так себе, например в структурах DoP лучше не добавлять его. Он по-сути нужен только при касте, т.к каст у int другой.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	69. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (74), 26-Апр-23, 21:53
	Он и вон тем stdbool'ом был как bool вывешен (как typedef вроде). То что для нормального була вместо левоватого _Bool надо добавочный хидер вообще смотрелось странновато как по мне.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (74), 26-Апр-23, 21:56
	Целочисленные типы сей как булеан довольно опасная штука, они врапаются по основанию 2, как минимум unsigned - и можно внезапно получить инверсную логику. Для signed превыщение min/max это по сути UB, хотя в 23 и последних плюсах вроде собирались регламентировать только 1 формат представления (twos complement) и тогда это уже "defined behavior" будет. Но в более ранних не указано как знак и знаковые хранить и там возможно нескллько вариантов. Формально валидных и - с разным поведением при переполнении, потому и UB.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	102. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от oficsu (ok), 27-Апр-23, 00:04
	> Для signed превыщение min/max это по сути UB, хотя в 23 и последних плюсах вроде собирались регламентировать только 1 формат представления Ну да, оставили только two's complement > и тогда это уже "defined behavior" будет Нет, не будет. Поскольку возможность переполнения мешает ещё и оптимизатору
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 28-Апр-23, 00:17
	> Ну да, оставили только two's complement Видимо дотумкало что столько UB сколько там есть - не рулит совершенно. >> и тогда это уже "defined behavior" будет > Нет, не будет. Поскольку возможность переполнения мешает ещё и оптимизатору Если остался только 1 формат хранения - по идее его wrap конкретно определен уже. А оптимизатор не имеет права нарушать иллюзии прописаные в стандарте. Хотя я и не смотрел этот кусок на тему гарантий, стандарт еще не вышел даже вроде?!
	Ответить | Правка | Наверх | Cообщить модератору

	315. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от oficsu (ok), 29-Апр-23, 20:14
	> по идее его wrap конкретно определен уже Ну, допустим. Дело же не в нём. Проблема в том, что оптимизатор может заложиться на тот факт, что число не переполняется, а значит и можно выпилить явные/неявные ветки кода, ожидающие переполнения Оптимизатор видит, что x == 10 и x только инкрементится — всё, ветку if (x == 9) {} можно просто выкинуть У нас не механизм переполнения оказывает влияние на производительность, а само наличие такой гарантии >  А оптимизатор не имеет права нарушать иллюзии прописаные в стандарте Так стандарт не позволяет переполнения, а значит и оптимизатор, выкидывающий лишние ветки, тоже ничего не нарушает — он заложился на отсутствие гарантий. Из-за этого, например, код с беззнаковыми может быть местами медленнее > стандарт еще не вышел даже вроде?! Стандарт — нет, но его черновик можно посмотреть или на гитхабе комитета в виде исходников, или собранный на eel.is/c++draft
	Ответить | Правка | Наверх | Cообщить модератору

	335. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 01-Май-23, 00:40
	> Ну, допустим. Дело же не в нём. Компилер обязан поддерживать заявленную абстракцию. В том числе и в оптимизере, в виде как если бы его не было. Если оптимизированный код отличается в поведении и он не уповал на UB, это уже будет баг оптимизатора тогда. На самом деле конечно больше баг стандартов абы как писаных, но, вот, хоть немного выправлять начинают это безобразие. > Проблема в том, что оптимизатор может заложиться на тот факт, что число > не переполняется, а значит и можно выпилить явные/неявные ветки кода, > ожидающие переполнения Для unsigned это вообще оптимизация - заложиться в коде на размер чтобы mod 2^N вообще нахаляву получить. Актуально криптоалгоритмам всяким и тому подобному. Для signed это не практиковалось из-за UB. > Оптимизатор видит, что x == 10 и x только инкрементится — всё, > ветку if (x == 9) {} можно просто выкинуть Это катит только если он может _доказать_ это. И даже так он может лопухнуться, потому что видит он все-таки не все. Скажем IRQ - оптимизер не видит, однако его вышибают в пользу другого кода. Для подобных случаев есть volatile. В чем то похожие проблемы есть в многопоточных конструкциях. >  У нас не механизм переполнения оказывает влияние на производительность, а само > наличие такой гарантии А вот это большой вопрос. Оптимизер может в дофига случаев пруфнуть те или иные граничные условия и вообще например обрубить функцию с кучей switch ... case до пары команд, доказав что оно получает только 1, 5 и 7 на вход по вообще всей программе. LTO в этом очень крут. > Так стандарт не позволяет переполнения, а значит и оптимизатор, выкидывающий лишние ветки, > тоже ничего не нарушает — он заложился на отсутствие гарантий. Из-за > этого, например, код с беззнаковыми может быть местами медленнее Это было актуально ДО C23 но актуально ли для него - а вот это интересно. > Стандарт — нет, но его черновик можно посмотреть или на гитхабе комитета > в виде исходников, или собранный на eel.is/c++draft Зачем мне драфт на C++ если мы про си?
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Релиз набора компиляторов GCC 13"	+5 +/–
	Сообщение от Совершенно другой аноним (?), 26-Апр-23, 18:43
	Тип и раньше был, как минимум с C99, только надо было включать stdbool.h. А если без включения, то был _Bool.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	96. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от FF (?), 26-Апр-23, 23:12
	макаки написали, макаки убежали, им бесполезно доказывать, они не программисты
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от n00by (ok), 27-Апр-23, 11:33
	>> bool, false и true > Кто лучше знает, это получается, что в новом стандарте Си появился полноценный > булевый тип? Что мешало добавить его раньше? Когда язык проектировали как замену ассемблеру, тогда булевый тип хранился во флагах процессора. Тогда идея заставить компилятор тратить под один бит целый байт выглядела дикой - это оставляли на совесть программисту.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

19. "Релиз набора компиляторов GCC 13"	+1 +/–
Сообщение от Аноним (19), 26-Апр-23, 18:24
несчастливый номер, пожалуй пропущу эту версию анбора конпиляторов
Ответить | Правка | Наверх | Cообщить модератору

	24. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от xsignal (ok), 26-Апр-23, 18:35
	А в Китае число 4 боятся, как огня, хотя ничего такого в нём нет.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Релиз набора компиляторов GCC 13"	–4 +/–
	Сообщение от Аноним (7), 26-Апр-23, 18:41
	> А в Китае число 4 боятся, как огня, хотя ничего такого в > нём нет. Почему нет, если читается как "смерть"? Но, я думаю, в целом,  в китае большой прогресс в истреблении мракобесия, особенно, по сравнению религиозным фанатизмом соседей. Вот что трудовые лагеря животворящие делают!
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от Tita_M (ok), 26-Апр-23, 18:52
	>в китае большой прогресс в истреблении мракобесия Уничтожение древних текстов и старых храмов, которые могли бы правдиво рассказать о древней истории и заместо старинных зданий клепать новоделы это не истребление мракобесия.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от name (??), 26-Апр-23, 18:44
	Дану, стремное какое-то. Тоже начну бояться.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	134. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (134), 27-Апр-23, 08:53
	Пятёрка конечно лучше четвёрки, но тройка еще хуже. Самое счастливое число это 5.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	218. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от InuYasha (??), 27-Апр-23, 18:11
	13. 1 + 3 = 4. Вуаля! (тут чинацйы собрали кирпичей на новую Стену)
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	41. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Апр-23, 20:13
	> несчастливый номер Бэкхенд на расте как раз добавили, плохой знак
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	164. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 27-Апр-23, 12:22
	> несчастливый номер, пожалуй пропущу эту версию анбора конпиляторов Повеяло мракобесием автономной ОС, у которой уже пять штук 12-х версий. Если понимать, откуда оно пошло и что такое дюжина - так как раз 12-й Дом - Дом Смерти.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	205. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от фф (?), 27-Апр-23, 16:29
	дюжина - это 12 костяшек на 4 пальцах одной руки, которые считали пятым(большим)
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 27-Апр-23, 18:30
	Только костяшками считали не сами костяшки, а что-то из жизни. Например, 4 времени года по 3 месяца.
	Ответить | Правка | Наверх | Cообщить модератору

	279. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (279), 28-Апр-23, 11:22
	у Cisco IOS'a не было 13 версии,была 12 а потом 15. Циско - молодцы.
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	283. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 13:04
	У них и этажей нет 13-х, что с них взять, если это давняя традиция. Вон те в автономной ОС умело устроили карго-культ своему господину.
	Ответить | Правка | Наверх | Cообщить модератору

	287. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от name (??), 28-Апр-23, 14:22
	Хм. А я всегда думал, что это про Иисуса -- если вместе соберутся 13 человек, то 1 в течении года умрет. Что даже чисто теоретически вполне вероятно.
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	288. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 14:56
	Наша Эра началась с т.н. Великого соединения Юпитера и Сатурна в знаке Рыб в момент зимнего солнцестояния. И кстати в 2020-м она таким же соединением в Козероге закончилась. Наберите в поисковике "Эра Водолея" - вот примеры, как астролухи путают знаки Зодиака и созвездия, строя из себя знатоков и паря мозг охлосу.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от InuYasha (??), 27-Апр-23, 18:10
	> несчастливый номер, пожалуй пропущу эту версию анбора конпиляторов нормально. 2.6 было топовое ядро. 26 = 13*2.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

33. "Релиз набора компиляторов GCC 13"	+/–
Сообщение от AKTEON (?), 26-Апр-23, 19:11
Как там netcdf - компилируется ??
Ответить | Правка | Наверх | Cообщить модератору

	307. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Михаил (??), 29-Апр-23, 07:29
	А не должен, что ли?
	Ответить | Правка | Наверх | Cообщить модератору

44. "Релиз набора компиляторов GCC 13"	+2 +/–
Сообщение от Alexey Torgashin (?), 26-Апр-23, 20:42
Даааа, такие популярные языки добавлены (не только в 13), Модула и Фортран…. И не видно что кто-то ненавидит эти старенькие плохонькие языки . А вот Паскаль ненавидят, и там и тут лезут уроды с критикой . Хотя Паскаль мощнее и лучше и проще и изящнее Модулы и Фортрана. Я на нем CudaText пишу. Гислер ТоталКомандер пишет.
Ответить | Правка | Наверх | Cообщить модератору

	47. "Релиз набора компиляторов GCC 13"	+3 +/–
	Сообщение от Аноним (39), 26-Апр-23, 20:54
	Fortran там сто лет как.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от xsignal (ok), 26-Апр-23, 20:54
	Паскаль - отличный язык. По сути, это тот же Си, только с более понятным новичкам синтаксисом - типа, begin/end вместо фигурных скобок. Я когда-то с Паскаля без особых усилий на Си перешёл - там всё точно так же, только запись короче)
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	66. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от _kp (ok), 26-Апр-23, 21:49
	Ну да, с удобным ср@чем из всех всех всех переменных функции в её начале. По мне, так подобные анахронизмы даже хуже чем излишняя многословность, ибо плодит трудно обнаружимые ошибки использования переменных. Не знаю как сейчас, но когда то в Делфи были коварные проблемы с многопоточным кодом на многоядерных процессорах, что у нас и стало одним из гвоздей в крышку его гроба. Может быть, сейчас и исправили, не знаю, но поезд ушёл. А из хорошего помню, по сравнению с Си, более удобная проверка типов, простые var параметры функций, оператор with. По сравнению с C++, был существенно ПРОЩЕ для НАЧАЛЬНОГО обучения программирования, то есть как одного из первых языков.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от AKTEON (?), 26-Апр-23, 22:19
	>Ну да, с удобным ср@чем из всех всех всех переменных функции в её начале. 1)Однопроходный компилятор - наше все. 2) А как чудно решается эта проблема в фортране ...
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от _kp (ok), 27-Апр-23, 01:15
	Переменные в начале логического блока тоже перевариваются однопроходным компилятором, и практически без усложнения компилятора. Это просто древний архаизм, который по недосмотру и стечению обстоятельств не исправили вовремя. Сейчас в embarcadero это и подобные деревянности исправлены, но уже не актуально.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 27-Апр-23, 12:01
	>>Ну да, с удобным ср@чем из всех всех всех переменных функции в её начале. > 1)Однопроходный компилятор - наше все. В любом случае переменная объявляется до использования.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	180. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (180), 27-Апр-23, 14:00
	Вам изобрели компьютеры чтобы не быть ограниченными одним проходом - нет, хотят г-но жрать.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	135. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (134), 27-Апр-23, 08:57
	> плодит трудно обнаружимые ошибки использования переменных Наоборот уменьшает. И все знают где в тексте статически определены все переменные.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	152. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от _kp (ok), 27-Апр-23, 10:34
	>> плодит трудно обнаружимые ошибки использования переменных > Наоборот уменьшает. И все знают где в тексте статически определены все переменные. Знают, что определены где то там, вдалеке, но не где используются. А вот их использование, и особенно неправильное, очень плохо обнаружимо, в чём и проблема. И компилятор тут и пол-warning'a не выдаст. А вобще, это "дурной стиль" ;)
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 28-Апр-23, 00:22
	> Наоборот уменьшает. И все знают где в тексте статически определены все переменные. С другой стороны, переменные для циклов типа for (uint8_t i = 0; i < 10; i++) и элегантно и прозрачно хинтит оптимизеру область использования переменной, и позволяет не захламлять сюжетно важный блок с описанием переменных aux сущностями нужными на 1 этот цикл и более - нигде.
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	91. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (-), 26-Апр-23, 22:42
	> Паскаль - отличный язык. По сути, это тот же Си, только с > более понятным новичкам синтаксисом - Ну вот для обучения он отличный. Для программирования реальных проектов мерзость занудная. > типа, begin/end вместо фигурных скобок. И всего в 3 и 5 раз больше букв набирать для одного результата. И не надо про автокомплит, он с 1 буквы или не сработает или будет дико глюкать, разве что хоткеи какие но визуальное загромождение и раздувание файлов никуда не денется. А в большом проекта даже и чтение файлов и их парсинг может стать аргументом. > Я когда-то с Паскаля без особых усилий на Си перешёл - там > всё точно так же, только запись короче) Ну да. И не пытается постоянно охранять от прострела пяток. По поводу чего код быстрее и эффективнее и можно сделать что задумал а не бороться с компилером. Но это как с мощным инструментом - при криворукости и глупости можно покалечиться.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	114. "Релиз набора компиляторов GCC 13"	–4 +/–
	Сообщение от DEF (?), 27-Апр-23, 02:56
	Днищенский язык. Вы только вдумайтесь, в Паскале длина массива и интервал индексов - это составные части типа. Невозможно в одну функцию или процедуру передавать массивы разной длины, так как они имеют разные типы. type vector1 = array [1..25] of real; type vector2 = array [2..26] of real; var   vec1: vector1;   vec2: vector2;
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	117. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от Аноним (64), 27-Апр-23, 03:58
	> Днищенский язык. Вы только вдумайтесь, в Паскале длина массива и интервал индексов - это составные части типа Это отличная вещь под названием строгая типизация. Ты еще Аду не видел. Проблема в том, что ты привык к убогим языкам. > Невозможно в одну функцию или процедуру передавать массивы разной длины, так как они имеют разные типы. Ну вообще-то можно: https://www.freepascal.org/docs-html/ref/refsu68.html
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (180), 27-Апр-23, 14:07
	> Днищенский язык. Вы только вдумайтесь, в Паскале длина массива и интервал индексов - это составные части типа. Невозможно в одну функцию или процедуру передавать массивы разной длины, так как они имеют разные типы. А где нет? А C++, например, `array<T, 10>` и `array<T, 11>` тоже разные типы. В паскале есть и динамические массивы - `array of real`. Днищенский он совсем не поэтому.
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	235. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (228), 27-Апр-23, 22:59
	Убогие какие-то функции получаются. И всё из-за одного формального параметра размера массива? поэтому удобно передать информацию: указатель на массив определенных элементов и количество элементов. Для меня это естественно.   Не забывайте Си разрабатывался как язык для написания операционной системы.
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 28-Апр-23, 00:26
	Да даже на си так можно. Если нужно. typedef struct array10_t { arr[10] }; vs typedef struct array11_t { uint8_t arr[11] }; И далее вы это by value или by pointer уже не сможете перепутать. Что так то хорошо - спасет от случая когда вы 11-й элемент в массиве на 10 дереференсить пытались. Не то чтоб это совсем не получится, но это будет минимум баг, максимум вулн.
	Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

	255. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 28-Апр-23, 00:28
	Упс, название типа потеряно. Примерно так: typedef struct array10_t { arr[10] } array10_t;
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от InuYasha (??), 27-Апр-23, 15:08
	Там точно не ":=" ? А днищенство языка там начинается с 1. Потому что.
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	210. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (210), 27-Апр-23, 16:57
	Все нормальные люди считают с 1, в нормальных языках типа Фортрана, Паскаля тоже с 1, в Ада - используются range, в математике нумерация с 1. И только отбитые сишники решили, что делать индексом сдвиг указателя на голову массива это офигенная идея. К сожалению этого овнокод победил, и остальные начали делать также.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Пользователь чебурнета (?), 27-Апр-23, 17:08
	> Все нормальные люди считают с 1, в нормальных языках типа Фортрана, Паскаля > тоже с 1, в Ада - используются range, в математике нумерация > с 1. Ни один истинный шотландец...
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от InuYasha (??), 27-Апр-23, 17:48
	А вы по утрам не приходите в канцтовары покричать на линейки и рулетки? ) Вот, такие же "нормальные" люди, наверно, изобретают лифты с кнопками "4 3 2 1 -1 -2" )
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	234. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (228), 27-Апр-23, 22:47
	Докажите, что для написания ОС такая нумерация было бы лучше?
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	294. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 28-Апр-23, 16:23
	> в математике нумерация с 1. Нет, в математике нумерация оттуда, откуда удобно. Твоё математическое образование видимо упустило такую тему матана как ряды, где используется исключительно нумерация с нуля, потому что индекс 0 очень удобно порождает показатель степени 0, который даёт нам член ряда без x (c x в нулевой степени). Без него пришлось бы писать конструкции типа x^{i-1}, что увеличивает количество писанины.
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	56. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от Аноним (56), 26-Апр-23, 21:21
	Так переписывай на Модулу скорее. Модула-2 это же продвинутый Паскаль. Считай это для тебя будет рывок вперед. Это как с Перла перейти сразу на Раку.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	72. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от _kp (ok), 26-Апр-23, 21:57
	Вряд ли будут переписывать. Вот, если б был delphi диалект object pascal, то можно было бы и готовые наработки использовать, а если в одном проекте на gcc без бубнов можно было бы совмещать код на разных языках, так что то уместне было б и на objeсt pascal писать. А Модула.. это после деревянных древних Паскалей шаг вперёд, а после Делфи скачок назад.
	Ответить | Правка | Наверх | Cообщить модератору

	311. Скрыто модератором	+/–
	Сообщение от Аноним (-), 29-Апр-23, 12:45
	Ну так бы и сказал сразу, что мол без ООП Дельфи как программист ты никто.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (-), 26-Апр-23, 22:42
	> Это как с Перла перейти сразу на Раку. Т.е. очередное нафиг нужное хзчто? На этому раке никто как раз и не прогает, во всяком случае, перловка попадается а раки нет :)
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	98. "Релиз набора компиляторов GCC 13"	+4 +/–
	Сообщение от Аноним (180), 26-Апр-23, 23:28
	> эти старенькие плохонькие языки Это просто феерия какая-то - любитель одного старенького плохонького языка опускает другие старенькие плохонькие языки. Во-первых, не стыдно? Во-вторых, какое после этого право ты имеешь называть уродами тех кто критикует твой выбор паскаля? > Хотя Паскаль мощнее и лучше и проще и изящнее Модулы и Фортрана Во-первых, нет. Во-вторых, даже если бы и был, это чести не делало бы ни ему, ни тому кто на нём пишет. Лучший среди худших, то ещё достижение. > И не видно что кто-то ненавидит ... А вот Паскаль ненавидят, и там и тут лезут уроды с критикой Давай я объясню почему. Во-первых, на модуле и фортране была написана (и всё ещё написаны кое-где) куча высокоответсвтенного и научного софта. А паскаль никогда не был ничем серьёзнее языка для обучения детей. Во-вторых, на модуле и фортране ничего нового не пишут, потому что уровень тех кто на них может писать позволяет осознать их неприменимость в современном мире. А на паскале пишут, как раз потому что это школьный уровень которого даже на осознание того что для серьёзных задач он не подходит не хватает. Пик глупости из эффекта Даннинга-Крюгера, наипоказательнейший пример. И пишут они, надо сказать, соответственно, и вообще этот уровень торчит отовсюду вплоть до организации репозитория, коммитлогов (да-да, вот эти коммиты с мессаджами "fix" и "continue") и стиля общения. И это только половина проблемы. Ладно дети, ладно не умеют программировать - какая разница если на выходе что-то есть и этим можно пользоваться. Но чтобы этим пользоваться надо притащить целую экосистему маргинального языка со своими правилами, своими кривыми модулями, своей кривой сборкой, своими багами и кучей проблем с переносимостью и совместимостью, причём всё это не исправляется потому что паскаль уже никому не нужен, и дальше будет только хуже. Поэтому даже мантейнеров (которые, вообще, по природе своей любят ковыряться в сложных вещах) заниматься этим не находится. Поэтому cudatext и опакечен в полутора дистрибутивах за свои, сколько там, 6-7-8 лет истории, а использовать блобы, по крайней мере под linux, дураков нет, и собирать самим тоже нет, потому что это не `cmake && make && make install` или, упаси господи, `cargo build` как в современных экосистемах, а адовый квест. А вот среди виндузятников наверное у вас основная аудитория и есть, как и у total commander. Эти всё в рот тащат, к тому что всё ломается на ровном месте привыкли, благодарная аудитория.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	103. "Релиз набора компиляторов GCC 13"	+4 +/–
	Сообщение от AHOHNM (?), 27-Апр-23, 00:43
	>Лучший среди худших, то ещё достижение. А вот несогласен с такой оценкой Паскаля. Вполне успешный язык, с хорошей системой типов, и использовался для вполне нужного софта. Да и простота его (см. обвинение в "школьности") привела к тому, что какой нибудь КМС^w КТН для проверки рабочих гипотез ваял на паскале как мог. А мог обычно почти никак (ой видел я этот поток учёного сознания), он же не профессиональный программистъ (Сейчас так же херово ваяют на питоне, хороший язык, да? да на матлабе ещё. пофиг, главное, гипотезу посчитать) Другое дело, что вышедший через два года C предложил несколько интересных вещей (например, функции с переменным количеством аргументов) явно с учётом особенностей других языков (а кто там был массовый? Фортран, Алоголы ); и синтаксически чётко разделял язык и библиотеку, чем лучше подходил как для системного программирования, так и для кросс-платформенного. И вот "профессионалы" уже хают дедушку, который им всё это богатство на блюдечке принёс, научил, грабельки показал где лежат... ладно, Остапа понесло... Да и время было такое, по сути, они все были первопроходцы в этом сложном деле.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (180), 27-Апр-23, 15:21
	> А вот несогласен с такой оценкой Паскаля. Вы не написали с чем именно вы не согласны. Написанное вами написанному мной нигде не противоречит. > Вполне успешный язык Согласен. Так, весь ныне забытый старый хлам был когда-то успешным. > с хорошей системой типов, и использовался для вполне нужного софта. Чем именно хороша его система типов? Не к её плохости, а к тому что она ничем не выделяется из массы всех паскале- и си-подобных языков. > Да и простота его (см. обвинение в "школьности") привела к тому, что какой нибудь КМС^w КТН для проверки рабочих гипотез ваял на паскале как мог. А мог обычно почти никак (ой видел я этот поток учёного сознания), он же не профессиональный программистъ (Сейчас так же херово ваяют на питоне, хороший язык, да? да на матлабе ещё. пофиг, главное, гипотезу посчитать) В школьности было не обвинение, а констатация факта, и описанный кейс с КТН никакого негатива не вызывает. Однако одно дело что кто-то что-то там делает для себя на коленке как умеет и как его полностью устраивает - это его личное дело. А другое - когда делается продукт для внешнего потребителя, которому неизбежно приходится брать на себя риски. А их и сам паскаль, и его экосистема, и квалификация автора который считает что на нём можно писать прикладуху, несут немерянно.
	Ответить | Правка | Наверх | Cообщить модератору

	296. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Alexey Torgashin (?), 28-Апр-23, 16:28
	Большое спасибо. Что просветили насчет Модулы и Фортрана, буду знать что на них сделано много научных библиотек.
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	300. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (180), 28-Апр-23, 17:26
	А не надо ёрничать. Действительно, просвещайтесь: https://en.wikipedia.org/wiki/List_of_numerical_libraries#Fo...
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (7), 27-Апр-23, 09:38
	За что их ненавидеть? Про модула не знаю ничего, а на фортране сегодня все наиболее производительные вычисления, в том числе на больших компах. Это стандарт. И зря что ли все проприетарщики пилят всё новые и новые компиляторы фортрана? И ни одного для других языков. Это, к слову, возможно, не в последнюю очередь, из-за того, что в том же гцц весьма убогий компилятор фортрана, и нормальную поддержку железа добавить проще в поделки поверх llvm. А из доступного любому обывателю прямо сегодня и сейчас есть mkl -- это наиболее производительная либа из альтернатив лапаку (а их полно) с SIMD и всем остальным. Только вот практически фортран не годится ни для чего кроме перемножения матриц. Исторически так сложилось, что его компиляторы генерировали код лучше сишных, но вот написать на фортане приложуху? Тут лучше взять что-нибудь более человеческое. А фортрану оставить математические вычисления. К слову, такой язык как ада тоже никто не ненавидит. У него есть свои применения, в отличие от того же раста. Что до паскаля, то это просто мусор, для тех, кто не осилил никаких других языков, никакого хейта тут нет. Разве что сломал мозги некоторым, все у них уроды. Ты же не будешь хейтить кувасик или тех, кто на нём сегодня кодит? Вот и паскаль там же.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	165. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Бывалый смузихлёб (?), 27-Апр-23, 12:29
	может оказаться что дело совсем не в производительности, а в огромных горах старых наработок, которые с нуля не так чтобы сильно хотят переписывать. Ведь зачастую проще что-то что уже есть допилить, чем что-то полностью с нуля создавать
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (7), 27-Апр-23, 13:36
	Этот аргумент работает с коболом. Но где ты его помимо банкоматов увидишь сегодня? Фортран выбирают именно из-за того, что он хорош для вычислений.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от InuYasha (??), 27-Апр-23, 13:05
	Вот за это ТоталКомандер, АИМП и прочие школоподелки из 90ых презренны.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	187. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (187), 27-Апр-23, 14:42
	А, ну да, Паскаль не старенький ;)
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	206. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от _hide_ (ok), 27-Апр-23, 16:38
	Классический Паскаль старше C. Это на заметку так. Но да, современные диалекты современны в меру умений разработчика. В гибкости отстают от языков с непрямой работой с памятью, а в производительности от языков а-ля ассемблер (как классический C). Весь антихайп из-за того, что этот язык программирования требует слишком серьёзной подготовки для написания адекватного кода.
	Ответить | Правка | Наверх | Cообщить модератору

	290. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Alexey Torgashin (?), 28-Апр-23, 15:15
	Паскаль старенький. Но он вбирает в себя новые веяния. Дженерики, анонимные функции, for-in, КОРБА-интерфейсы, атрибуты в [], поддержка разных CPU + OS, и т.д. Все это появляется.
	Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

	252. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от AKTEON (?), 28-Апр-23, 00:25
	Ну и как там в паскале с параллелизмом в гетерогенных вычислительных системах ??
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	351. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от BeLord (ok), 05-Май-23, 17:03
	Пакет под Альт Линукс есть или самому собирать, я про CudaText?
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

50. "Релиз набора компиляторов GCC 13"	+1 +/–
Сообщение от Аноним (39), 26-Апр-23, 20:55
Как там дела у Iain Buclaw?
Ответить | Правка | Наверх | Cообщить модератору

	107. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Hck3r (?), 27-Апр-23, 01:08
	Всё отлично :) D живее всех живых
	Ответить | Правка | Наверх | Cообщить модератору

54. "Релиз набора компиляторов GCC 13"	+/–
Сообщение от Аноним (54), 26-Апр-23, 21:19
Не ну модула-2 топчик, кто бы спорил.
Ответить | Правка | Наверх | Cообщить модератору

70. "Релиз набора компиляторов GCC 13"	+1 +/–
Сообщение от Аноним (64), 26-Апр-23, 21:55
> В соответствии с новой схемой нумерации выпусков, версия 13.0 использовалась в процессе разработки Как же достало, что каждый проект придумывает свою невиданную ранее систему версионирования. Были же семантические версии десятками лет, Но нет: надо, чтобы люди при каждом релизе вспоминали, что том разработчики имели в виду - для каждого доброй дюжины проектов.
Ответить | Правка | Наверх | Cообщить модератору

	99. "Релиз набора компиляторов GCC 13"	–3 +/–
	Сообщение от Аноним (180), 26-Апр-23, 23:32
	> Как же достало, что каждый проект придумывает свою невиданную ранее систему версионирования. Были же семантические версии десятками лет, Но нет: надо, чтобы люди при каждом релизе вспоминали, что том разработчики имели в виду - для каждого доброй дюжины проектов. Нормальным людям (включая мантейнеров пакетов и разработчиков) это нахрен не нужно, вообще всё равно какая там циферка где меняется. И это правильно, потому что ничего через циферки не выразить, и semver доказал свою полною несостоятельность.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (64), 27-Апр-23, 04:08
	> И это правильно, потому что ничего через циферки не выразить Можно выразить масштаб изменений. > semver доказал свою полною несостоятельность Разве что как раз этим уникумам, которые изобретают свой велосипед.
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (180), 27-Апр-23, 15:56
	> Можно выразить масштаб изменений. Нет, можно выразить только наличие очередного релиза и упорядочить релизы (и то только в рамках одной релизной ветки), масштаб изменений выразить нельзя от слова вообще, потому что он для каждого потрелибеля значит разное и для большинства применений неизмерим вовсе. А если бы даже масштаб и можно было как-то выразить, то использовать его всё равно никаким осмысленным образом не получилось бы. Напомню что semver, одна из немногих схем _осмысленного_ версионирования, отталкивается не от непонятного масштаба, а от конкретного (на первый взгляд) свойства - изменений в API (patch = нет изменений, minor = есть совместимые, major = есть несовместимые). Однако эта схема не работает потому что, с одной стороны, на практике оказывается что любое наблюдаемое изменение является несовместимым (поэтому исправление бага в minor ломает тех кто на этот баг заложился), с другой - не все несовместимые изменения API аффектят всех (поэтому major изменение может вообще ничего не затронуть в потребителе). При этом а) API имеет смысл только для библиотек, при том что не все проекты библиотеки б) почти половина проектов не заявляют стабильного API (версия 0.*). Поэтому нет, версии ничего ни количественно, не качественно не выражают, никогда не выражали и не будут, а требовать этого могут только не разбирающиеся в разработке дурачки.
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от Аноним (64), 27-Апр-23, 19:47
	> Поэтому нет, версии ничего ни количественно, не качественно не выражают, никогда не выражали и не будут, а требовать этого могут только не разбирающиеся в разработке дурачки. Ох уж эти опеннетные умники, разбирающиеся в разработке. Ты сам себе противоречишь, утверждая, что семантика есть, но при этом она ничего не выражает. Семантика есть и у нового способа версионирования GCC, но она нестандартная, и в этом как бы вся претензия. > свойства - изменений в API Не только изменений в API, но и любого функционала софта в целом (не обязательно библиотек). А еще у библиотек есть ABI. При этом ты же сам написал, что patch - это багофиксы, minor - новый совместимый функционал, а major - огромные несовместимые изменения. Это как бы и есть масштаб и тип изменений, не? > любое наблюдаемое изменение является несовместимым (поэтому исправление бага в minor ломает тех кто на этот баг заложился) Во-первых, баги фиксят в path. Во-вторых, если у кого-то хватило ума заложился на баги - это их личные проблемы. Какое отношение это имеет к системе версий и ее семантике? > не все несовместимые изменения API аффектят всех Опят же, какое отношение это имеет к системе версий? Какое мне дело, аффектит ли оно "всех", если я работаю над конкретным проектом или с конкретным софтом? > поэтому major изменение может вообще ничего не затронуть в потребителе Нет, не может, ибо это уже не изменения уровня major, а как раз какая-то новая нескучная семантика. > почти половина проектов не заявляют стабильного API (версия 0.*). Ну вот ты сам упомянул о еще одной семантике - пре-релизе. И тут же утверждаешь, что версия не говорит ни о чем.
	Ответить | Правка | Наверх | Cообщить модератору

	299. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (180), 28-Апр-23, 17:21
	> Ты сам себе противоречишь, утверждая, что семантика есть, но при этом она ничего не выражает Я такого не утверждал, научись читать - я привёл semver как пример _попытки_ сделать вид что семантика есть, и показал почему это не работает. > Не только изменений в API, но и любого функционала софта в целом (не обязательно библиотек) Нет, только изменений в API, потому что API это контракт, а только при наличии контракта можно говорить нарушается он или нет. Про изменение "любого функционала" ничего нельзя сказать. Может ты опечатку поправил в выводе программы, и для тебя это patch, а для того кто этот вывод решил парсить и у него сломалась регулярка это breaking change. Собственно, то же возможно и при обработке того что вернула библиотека, поэтому semver и не работает. >> не все несовместимые изменения API аффектят всех > Опят же, какое отношение это имеет к системе версий? Какое мне дело, аффектит ли оно "всех", если я работаю над конкретным проектом или с конкретным софтом? Автор, по semver, должен бампать major при любом несовместимом изменении в API. При этом клиент может эту часть API вообще не использовать. В итоге даже забыть что semver не работает, и завязаться на его гипотетическую семантику, которая позволила бы нам, например, описать диапазон версий зависимости нашего проекта как `>=17 <18`, надеясь получать обновления в рамках 17 мажорной версии и при этом не сломаться, мы получим хрена лысого.
	Ответить | Правка | Наверх | Cообщить модератору

	343. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от warlock66613 (ok), 01-Май-23, 10:51
	То, что вы хотите от semver чего-то, что он не может — не проблема semver, это ваша проблема.
	Ответить | Правка | Наверх | Cообщить модератору

	280. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (280), 28-Апр-23, 12:06
	>И это правильно, потому что ничего через циферки не выразить, и semver доказал свою полною несостоятельность. Ты когда-нибудь зависимости руками собирал?
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	148. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (148), 27-Апр-23, 09:55
	> Были же семантические версии десятками лет $ less --version less 629 (PCRE2 regular expressions) Copyright (C) 1984-2023  Mark Nudelman
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	155. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (155), 27-Апр-23, 11:15
	И чем тебя не устраивает: GCC 13.1 released [2023-04-26] GCC 12.2 released [2022-08-19] GCC 10.4 released [2022-06-28] GCC 9.5 released [2022-05-27] GCC 12.1 released [2022-05-06] GCC 11.3 released [2022-04-21] GCC 11.2 released [2021-07-28] GCC 9.4 released [2021-06-01] GCC 8.5 released [2021-05-14] GCC 11.1 released [2021-04-27] GCC 10.3 released [2021-04-08] GCC 10.2 released [2020-07-23] GCC 10.1 released [2020-05-07] GCC 9.3 released [2020-03-12] GCC 8.4 released [2020-03-04] GCC 7.5 released [2019-11-14] GCC 9.2 released [2019-08-12] GCC 9.1 released [2019-05-03]
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	166. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (166), 27-Апр-23, 12:32
	Тем, что половины номеров тут нет. Например, 10.0.0 или 12.1.1. То есть вы предлагаете мне просто запомнить, какие версии есть, а каких нет.
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Ванёк (?), 27-Апр-23, 15:02
	10.0.0 или 12.1.1 - это не релизные версии, это текущие версии, над которыми ведётся работа, по завершении которой эти версии получают другие номера - в данном случае 10.1 и 12.2.
	Ответить | Правка | Наверх | Cообщить модератору

87. "Релиз набора компиляторов GCC 13"	+3 +/–
Сообщение от nc (ok), 26-Апр-23, 22:21
Мне интересно, почему в языковые расширения (https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html , https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Extensions.html) до сих пор не добавили свойства (properties), реализованные во многих языках, в том числе и во многих расширениях С++ (как минимум в MSVC и C++Builder). Реально полезная штука как минимум для изучения огромных унаследованных кодовых баз, когда нужно перехватить обращение к тому или иному объекту/полю. Причем полная эмуляция этой фичи перегрузками операторов невозможна. Куда можно написать предложение разработчикам компилятора?
Ответить | Правка | Наверх | Cообщить модератору

	100. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Ананоним (?), 26-Апр-23, 23:37
	Потому что свойства это только для тех, кто очень полюбил визуальное "программирование" мышкой. А для тех кто текстом программирует, свойства это как собаке пятая лапа. get-теры set-теры тебе в помощь.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от _kp (ok), 27-Апр-23, 01:38
	Вы считаете, что без GUI дизайнера интерфейса писать гораздо быстрее, чисто в тексте, не видя в процессе того что получается? ;) То то чистый C++ для GUI не очень удобен. А get-теры и set-теры, это почти как begin и end и пятая нога. С одной стороны, работает - не трогай, но и если не развиваться, "засахарится" и морально устареет.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (116), 27-Апр-23, 03:23
	> Отправлено _kp, 27-Апр-23 01:38 Вы считаете, что без GUI дизайнера интерфейса писать гораздо быстрее, чисто в тексте, не видя в процессе того что получается? ;) Можно и без дизайнера видеть что получается, в тч в реалтайме. Так например используют vim для написания статей latex в pdf. Или тестировщики так тестируют gui. Дизайнеры это по сути комбайн, но все то же самое может и отдельно работать. Ну а в идеале не должно быть необходимости постоянно смотреть что получается. Результат итак должен быть очевиден (так например было с html в конце 90ых).
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (56), 27-Апр-23, 07:40
	Программист совсем ничего не должен знать про GUI. GUI должен делать дизайнер. Возможно в Фигме, а программист должен брать оттуда циферки и вставлять в своё приложение. Возможно это даже промежуточный программист, которого можно назвать верстальщиком. Никаких других способов получить красивый дизайн не существует.
	Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

	175. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от InuYasha (??), 27-Апр-23, 13:02
	Программисту надо иметь права на отламыванию пальцев дизайнеру, если что.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (56), 27-Апр-23, 15:19
	Даже с таким правом и даже с визуальным программированием у программиста дизайн будет полный ... отстой. Обычно даже UX отстой чего уж там.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (187), 27-Апр-23, 14:32
	У многих проектов 2 - 3 разработчика, а то и всего один. Вот теперь если они ещё и десигнеров для проектов искать начнут, то на собственно разработку времени не останется. Полезного кода больше не увидим.
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	196. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (56), 27-Апр-23, 15:17
	Значит дизайн будет фи ка лия. С этим ничего нельзя поделать это данность. Это надо принять.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от nc (ok), 27-Апр-23, 08:15
	Свойства как концепция вообще никакого отношения к визуальному программированию не имеют. Это особая трансформация синтаксического дерева, позволяющая прозрачно заменить обращения на чтение и на запись к некоторому полю данных на вызовы функций. Здесь существенна именно прозрачная замена - то есть при замене свойства на поле и обратно остальной код менять не требуется.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	182. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от _kp (ok), 27-Апр-23, 14:14
	> Свойства как концепция вообще никакого отношения к визуальному программированию не имеют. Ну в чистом виде не имеют, но значительно упрощают графический дизайнер интерфейса, и не только его. В общем, было бы полезно добавить.
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (64), 28-Апр-23, 19:17
	> А для тех кто текстом программирует, свойства это как собаке пятая лапа. get-теры set-теры тебе в помощь. Отличная логика. Добавили operator[], перегрузку, пользователськие операторы, RTTI, но свойства - "собаке пятая лапа".
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	162. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от n00by (ok), 27-Апр-23, 12:11
	Пишите на Vala, там есть свойства и в довесок GObject.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	172. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от InuYasha (??), 27-Апр-23, 12:54
	лол, заставил меня вспомнить те годы. Да не, проперти - это костыль какой-то. Если что и было нужного в быдлере - это _кложуре для коллбэков.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	248. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от nc (ok), 28-Апр-23, 00:14
	Это целиком и полностью покрывается возможностями std::function
	Ответить | Правка | Наверх | Cообщить модератору

	281. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (280), 28-Апр-23, 12:10
	В спортлото напиши, Си сделан не для скрытой сложности, в противном случае там давно была бы перегрузка операторов уже давно.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

112. "Релиз набора компиляторов GCC 13"	+1 +/–
Сообщение от zog (??), 27-Апр-23, 01:43
Сборка toolchain с GCC всё так же является чёрной магией с кучей заклинаний?
Ответить | Правка | Наверх | Cообщить модератору

127. "Релиз набора компиляторов GCC 13"	+2 +/–
Сообщение от жявамэн (ok), 27-Апр-23, 07:02
бекенды для го и хруста.... этим вообще кто то пользуется лол
Ответить | Правка | Наверх | Cообщить модератору

	128. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (56), 27-Апр-23, 07:36
	Те кто не хотят борова чекать.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (134), 27-Апр-23, 09:13
	В сборочных дистрах (Gentoo, LFS) не пользуются ржавым из-за необходимости тащить его компилятор. После добавления ржавого в gcc популярность программ на нем теоретически должна вырасти. У меня в системе, например тяжелая математика на foltran и наличие этого компилятора не особо мешает. Go не пошел у меня из-за его "менеджера пакетов" после попытки установить ipfs выкинул. Ржавый тоже может не пойти по этой причине.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	145. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (145), 27-Апр-23, 09:43
	Не со всем согласен: https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag.../ слишком большая "дроблённость" rust & go способствует внедрению закладок в используемые либы. Однако обязательное внедрение подписей PGP может помочь решить проблему.
	Ответить | Правка | Наверх | Cообщить модератору

	232. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (232), 27-Апр-23, 22:28
	Некогда, когда ещё программировал и занимался наукой, переписал критическую часть рассчётной программы (МКЭ) на Си, и скорость выросла в разы. Фортран - это хорошо, но очень уж не оптимизированно.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	270. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Дед Ананий (?), 28-Апр-23, 08:17
	Современный Fortran - вполне себе годный инструмент. Для realtime, может, и не подойдет, но для расчета эмуляций процессов при ядерном взрыве с распаралеливанием вычислений - вполне себе. Многое зависит также и от квалификации программиста.
	Ответить | Правка | Наверх | Cообщить модератору

	348. Скрыто модератором	+/–
	Сообщение от Аноним (-), 02-Май-23, 03:49
	Ну так напиши майнер на фортране, посмотрим сделает ли он по мегахешам сишный.
	Ответить | Правка | Наверх | Cообщить модератору

	316. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от soomrack (ok), 29-Апр-23, 20:33
	К сожалению, для firefox уже нужно ставить Rust. Но с ним есть одна дикая вещь в gentoo: https://bugs.gentoo.org/735154#c3 # Enable all LLVM targets unconditionally.  Unfortunately, disabling # targets tend to break reverse dependencies (e.g. Rust) and we are yet # to find a clean way of resolving that.  Compared to the damage # potential, the increase of build time is a minor problem.  Users who # really insist of building a smaller system can un-force the flags # at their own responsibility. >[оверквотинг удален] >=sys-devel/clang-14 llvm_targets_VE >=sys-devel/llvm-13.0.1_rc llvm_targets_AArch64 llvm_targets_AMDGPU >=sys-devel/llvm-13.0.1_rc llvm_targets_ARM llvm_targets_AVR llvm_targets_BPF >=sys-devel/llvm-13.0.1_rc llvm_targets_Hexagon llvm_targets_Lanai >=sys-devel/llvm-13.0.1_rc llvm_targets_MSP430 llvm_targets_Mips >=sys-devel/llvm-13.0.1_rc llvm_targets_NVPTX llvm_targets_PowerPC >=sys-devel/llvm-13.0.1_rc llvm_targets_RISCV llvm_targets_Sparc >=sys-devel/llvm-13.0.1_rc llvm_targets_SystemZ llvm_targets_WebAssembly >=sys-devel/llvm-13.0.1_rc llvm_targets_X86 llvm_targets_XCore >=sys-devel/llvm-14 llvm_targets_VE и это при том, что rust тащит свою собственную llvm. Как так то?!!
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	174. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от InuYasha (??), 27-Апр-23, 13:00
	Пьющие кровавые смузи хипстеры.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	201. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (56), 27-Апр-23, 15:48
	Свободные и независимые хипстеры, которые за чистоту кода против корповых компиляторов.
	Ответить | Правка | Наверх | Cообщить модератору

153. "Релиз набора компиляторов GCC 13"	+/–
Сообщение от Штыбель (?), 27-Апр-23, 10:40
>Объявлена устаревшей поддержка Solaris 11.3 Хотя бы 11.4 поддерживается.
Ответить | Правка | Наверх | Cообщить модератору

167. "Релиз набора компиляторов GCC 13"	+/–
Сообщение от Аноним (167), 27-Апр-23, 12:35
Решил тут попробовать G++. И что? 1) Возможности явно указать точку входа прямо в коде нет, хотя она была в любом древнем компиляторе. Отрубаешь stdlib и приходится указывать точку входа через командную строку. 2) Отрубить .edata если она пустая возможности нет, даже при использовании gc-sections 3) Отрубить hintы в импорте возможности нет 4) 64х битный и 32х битный компиляторы ведут себя по разному, так что везде приходится тыкать условную компиляцию.
Ответить | Правка | Наверх | Cообщить модератору

	188. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (187), 27-Апр-23, 14:44
	Разве манипуляции с секциями ELF не задача линкера?
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (7), 27-Апр-23, 14:54
	Просто тут другой под к вопросу. Один ламеровендузятский, где всё пихают в кучу, и другой нормальный, где инструменты занимаются своими вещами и дают контроль программисту. Я так понимаю, в этом суть проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 27-Апр-23, 18:46
	В Виндосе в MSVC точка входа задавалась ключём линкеру /ENTRY:function. В ассемблерах можно в исходном тексте указывать. Может он так троллит?
	Ответить | Правка | Наверх | Cообщить модератору

	260. "Релиз набора компиляторов GCC 13"	+2 +/–
	Сообщение от Аноним (245), 28-Апр-23, 00:43
	> 1) Возможности явно указать точку входа прямо в коде нет, Си это не ассемблер. Но если сильно хочется, линкерскрипт или командлайн к вашим услугам. > хотя она была в любом древнем компиляторе. Не есть стандартный си и никак не регламентировано. По факту в gcc можно что угодно сделать, как микроконтроллерщик говорю. > Отрубаешь stdlib и приходится указывать точку входа через командную строку. Можно в линкерскрипте указать. Да и хотели вы наверное что-то типа: -fno-common -fno-builtin -nostdlib -ffreestanding или около того... А может еще и это, если про gc sections в курсе: -fdata-sections -ffunction-sections Лучше всего оно в паре с LTO, если тот выносит лишнее (умеет!) есть __attribute__(used). > 2) Отрубить .edata если она пустая возможности нет, даже при использовании gc-sections Можете отрубить все что угодно - добро пожаловать в чуднй мир линкер скриптов. Как хотите так и компонуйте свой бинарь. Все гибко и настраиваемо. Есть даже директива DISCARD для неугодных вам секций. Если они были нужны и не стало работать кто ж вам виноват? :) > 3) Отрубить hintы в импорте возможности нет А что такое "импорт" в вон том flat binary фирмвари например? :) > 4) 64х битный и 32х битный компиляторы ведут себя по разному, так > что везде приходится тыкать условную компиляцию. А они и не обязаны себя одинаково вести. Они обязаны имплементить стандарт сей (ну или плюсов).
	Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

173. "Релиз набора компиляторов GCC 13"	+/–
Сообщение от Ilya Indigo (ok), 27-Апр-23, 12:59
GCC 13 и не слова про #include <cstdio>.
Ответить | Правка | Наверх | Cообщить модератору

	313. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (245), 29-Апр-23, 17:17
	>cstdio А это ещё что?
	Ответить | Правка | Наверх | Cообщить модератору

	323. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (133), 30-Апр-23, 15:38
	stdio.h
	Ответить | Правка | Наверх | Cообщить модератору

	327. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Ilya Indigo (ok), 30-Апр-23, 19:03
	>>cstdio > А это ещё что? https://runebook.dev/ru/docs/cpp/header/cstdio Почти в каждом 1-ом патче для C++ пакетов в имени которого присутствует gcc13.
	Ответить | Правка | К родителю #313 | Наверх | Cообщить модератору

273. "Релиз набора компиляторов GCC 13"	+/–
Сообщение от Ананий (?), 28-Апр-23, 09:31
Можно оффтоп ради саморазвития, раз уж тут околосистемные погромисты собрались. В линукс/бсд/солярисах такой же идиотизм с исполняемыми файлами как и в шиндовом EXE, когда в заголовке прописываются смещения в коде, которые нужно обновлять для выделенного блока памяти каждый раз при запуске?
Ответить | Правка | Наверх | Cообщить модератору

	278. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Пидор Пэн (?), 28-Апр-23, 10:50
	В виндовых x64 exe этого уже нет, так как код стал PIC-подобным
	Ответить | Правка | Наверх | Cообщить модератору

	321. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (133), 30-Апр-23, 15:31
	А если какой-нибудь кульхацкер на ASM'е наваяет с прямой адресацией?
	Ответить | Правка | Наверх | Cообщить модератору

	340. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 01-Май-23, 10:24
	Кульхацкер если что наваяет, то потом обязательно проверит. Тем он и отличается от анонимного эксперта.
	Ответить | Правка | Наверх | Cообщить модератору

	284. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 28-Апр-23, 13:22
	Точнее, не в заголовке, а в таблице релокаций. Релоки не обязательны для запуска, раньше по умолчанию в exe их не было. Нужны они для загрузки по любым адресам. Можно писать код так, что релоки не понадобятся. Компиляторы-линкеры генерировали релоки, поскольку код получался более компактным. Зависит это от процессора, а не от ОС. В gcc ищите в справке position-independent code. И кстати "шиндовый EXE" грамотно называется PE/COFF. А "COFF was introduced in 1983, in AT&T's UNIX System V". ;)
	Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

	310. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (-), 29-Апр-23, 12:39
	>И кстати "шиндовый EXE" грамотно называется PE/COFF. А "COFF was introduced in 1983, in AT&T's UNIX System V". ;) Открою тебе срашную тайну! Тс-сc! Тока никому не говори: "DOS/Windows - это изуродованный Xenix". Ублюдок Билли специально путь в файловой системе обозначил обратным слешем (\), чтобы все его продукт приняли за оригинальную, с чистого листа написанную ОС!
	Ответить | Правка | Наверх | Cообщить модератору

	312. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 29-Апр-23, 15:06
	Это для меня не тайна, что тороидального Анонима (-) лучше не читать. 86-DOS Билли купил у Тима Патерсона, а NT у DEC вместе с командой разработчиков VMS.
	Ответить | Правка | Наверх | Cообщить модератору

	322. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (133), 30-Апр-23, 15:37
	Только UNIX System V COFF был без всяких там PE - M$ улучшайзингов.
	Ответить | Правка | К родителю #284 | Наверх | Cообщить модератору

	341. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от n00by (ok), 01-Май-23, 10:25
	> Только UNIX System V COFF был без всяких там PE - M$ > улучшайзингов. Разверните мысль, приведите парочку для примера.
	Ответить | Правка | Наверх | Cообщить модератору

	336. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (237), 01-Май-23, 00:47
	> такой же идиотизм с исполняемыми файлами как и в шиндовом EXE, > когда в заголовке прописываются смещения в коде, которые нужно обновлять для > выделенного блока памяти каждый раз при запуске? В 32 bit x86 - а куда вы денетесь? У x86 код не является position independent и его нельзя перенести в другие адреса без сильного патчинга программы, потому что проц режимами адресации не вышел - не умеет относительно PC (IP) референситься, например. Это вообще от ОС не зависит, только от архитектуры проца. Можно еще грузить все в фиксированые адреса но это не гибко и может быть неудачно для секурити. Если хакер знает все адреса функций, ему так сильно удобнее атаку развивать. В x86-64 все заметно приличнее, но там тоже смотреть нюансы надо.
	Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

285. "Релиз набора компиляторов GCC 13"	+1 +/–
Сообщение от Коми (?), 28-Апр-23, 14:03
Серверы, сервисы и прочая мутата в компиляторах...докатились.
Ответить | Правка | Наверх | Cообщить модератору

293. "Релиз набора компиляторов GCC 13"	–1 +/–
Сообщение от Аноним (-), 28-Апр-23, 16:21
>В состав GCC принят фронтэнд для сборки программ на языке программирования Modula-2. Его используют только в российской оборонке! ИМХО, в наборе компиляторов GCC он не нужен.
Ответить | Правка | Наверх | Cообщить модератору

295. "Релиз набора компиляторов GCC 13"	+/–
Сообщение от Аноним (-), 28-Апр-23, 16:24
>После доведения фронтэнда до готовности (ожидается в следующем выпуске), штатный инструментарий GCC сможет использоваться для компиляции программ на языке Rust без необходимости установки компилятора rustc, построенного с использованием наработок LLVM. Проблема не в том, что есть он в наборе компилятор или нет. Должно произойти 2 вещи. 1. Язык Rust должен одобрить Столлман. 2. Язык Rust должен иметь копилефтную лицензию (в том числе и все библиотеки в Cargo).
Ответить | Правка | Наверх | Cообщить модератору

	298. "Релиз набора компиляторов GCC 13"	–4 +/–
	Сообщение от Анонин (?), 28-Апр-23, 17:12
	1. Всем по... на деда 2. Раковый копилефт оставьте себе. Тут свободная лицензия.
	Ответить | Правка | Наверх | Cообщить модератору

	309. "Релиз набора компиляторов GCC 13"	+1 +/–
	Сообщение от Аноним (-), 29-Апр-23, 12:32
	Свободной считается только лицензия типа копилефта. Это отражено на сайте GNU и FSF и много раз отмечено в научных трудах и СМИ. Лицензии типа Mozilla_PL, БЗД (всех 4-х клаусов), МИТ-щина, Апаче, "Общественное достояние" считаются пермиссивщиной, их ещё называют "Открытый код (Open Source)".
	Ответить | Правка | Наверх | Cообщить модератору

	326. "Релиз набора компиляторов GCC 13"	–2 +/–
	Сообщение от Анонин (?), 30-Апр-23, 17:54
	Свободной по чьему мнение? По мнению гнутеллы и фсф? Ахаха, ну разумеется это рачье будет кричать что только их лицухи по настоящему свободные. BSD, MPL, MIT, PublicDomain - вот где  настоящая свобода, а не швaбoдka® гплнутых фанатиков.
	Ответить | Правка | Наверх | Cообщить модератору

	324. "Релиз набора компиляторов GCC 13"	–1 +/–
	Сообщение от Аноним (133), 30-Апр-23, 15:40
	Люто плюсую твои слова, брат Аноним.
	Ответить | Правка | К родителю #295 | Наверх | Cообщить модератору

297. "Релиз набора компиляторов GCC 13"	+/–
Сообщение от Аноним0 (?), 28-Апр-23, 16:45
Главное, чтобы swap не рос
Ответить | Правка | Наверх | Cообщить модератору

	325. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (133), 30-Апр-23, 15:43
	Rust же защищает от Use after free ;)
	Ответить | Правка | Наверх | Cообщить модератору

	337. "Релиз набора компиляторов GCC 13"	+/–
	Сообщение от Аноним (237), 01-Май-23, 00:48
	> Rust же защищает от Use after free ;) Вон тот список CVE готов поспорить с этим храбрым утверждением.
	Ответить | Правка | Наверх | Cообщить модератору

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

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