The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Релиз набора компиляторов GCC 13, opennews (??), 26-Апр-23, (0) [смотреть все]

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


2. "Релиз набора компиляторов GCC 13"  –8 +/–
Сообщение от asdasd (?), 26-Апр-23, 17:09 
> разрешение использования constexpr и auto при определении объектов

На кой auto в C? В C++ он нужен из-за монструозных template'тов.

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

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

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

76. "Релиз набора компиляторов GCC 13"  +3 +/–
Сообщение от warlock66613email (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"  +/–
Сообщение от warlock66613email (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 +/–
Сообщение от warlock66613email (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"  +/–
Сообщение от warlock66613email (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"  +/–
Сообщение от warlock66613email (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"  +/–
Сообщение от warlock66613email (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"  +/–
Сообщение от warlock66613email (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 +/–
Сообщение от Анонимemail (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 
Ответить | Правка | К родителю #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ообщить модератору

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

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




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

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