The OpenNET Project / Index page

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



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

Оглавление

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

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


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ообщить модератору

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

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




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

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