defer в C быть!

По поведению - как бы хочет «погасить звёзды». Новый тренд растоманов?

Но в данном контексте это скорее не благодаря языку, а вопреки.

В си можно писать или использовать функции (интрсики, либы), заточенные под gpu. Или хочется чтобы именно языковые примитивы (int, for, массивы и тп) удобно ложились на gpu? Такого нет ни в одном неспециализированном ЯП, везде приходится использовать надстройки над языком: спецсинтаксис (dsl), внешние библиотеки, трансляторы, компиляторы и тд.

«проще» может не совпадать из это style guide cледуют

одна из фишек питона двух-трёхбуквие псевдонимов длиноимённых общепопулярных либ.

как диды завещали - вон в план9 namespace сети обычно /n

венгерка обусловлена не интерактивностью носителя текста

как тут вокруг упоминали вполне мнима ситуация текстового фильтра овенгеривающего дерево сырцов

и фильтра развенгеривающего овенгериванный(кем угодно)

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

Каждый крупняк выпускает свои стандарты си и думает, что они стандартнее других стандартов. FSF с gcc и лоббированием стандартов как раз один из таких крупняков. Но им тоже аукается, т.к. многие просто игнорируют расширения, придерживаясь функциональности, близкой к тому, что описано в стандартике C99.

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

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

Если бы в других областях были такие инженеры, как те что придумали Си, первый же дятел развалил бы всю цивилизацию к чертям. Абсолютная неспособность сишников предсказать поведение собственного кода и гадания на кофейной гуще (см выше про переполнение) – отличный пример тотального отсутствия какого-либо инженерного подхода в принципе.

Этим далеко не только сишники страдают, если что.

hateyoufeel, аватарка отвратная, какой смысл такую иметь?

Отличная аватарка для обсуждения говнокода! Тут бывали и хуже. Вот эта, например.

А кто сказал, что венгерскую нотацию надо использовать там, где она не принята? Речь идёт о проектах, принявших её как кодстайл.

Интересно кстати, есть ли какой-нибудь линтер, проверяющий соответствие венгерки реальным типам?

вторая посылка ставит под сомнение первую и с этим надо то-то делать.

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

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

Отличная аватарка для обсуждения говнокода!

ты свой говнокод зажал, чтобы чужие обсуждать. тебе своего не хватает что-ли?

Отличная аватарка для обсуждения говнокода!

ты свой говнокод зажал, чтобы чужие обсуждать. тебе своего не хватает что-ли?

Я всего лишь следую моде местных сишников. Чем круче ЛОРовский сишник, тем меньше его кода мы видим. Ты вот видел код нашей программистки с 30-летним опытом в Си, которая тут плавает в знаковом переполнении и только сегодня узнала про -fwrapv, с которым, на секунду, половина софта в лялехе собирается? Я ни строчки не видел.

Ой…

https://godbolt.org/z/5d1ozc4c9

-O0

ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 0
a = 0, b = 0, test = 31337
a = 0, b = -1, test = 0
a = 2147483647, b = 1, test = 1111

-O2

ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 0
a = 0, b = 0, test = 31337
a = 0, b = -1, test = 0
a = 2147483647, b = 1, test = 31337

Да-да, знаю ответ «это другое, это переполнение разрядной сетки, это UB, а значит говнокод»…

А я наоборот, сторонник camel case, т.к. переменные получаются короче, чем с подчеркиваниями.

struct timeval CurrentTimeUNIX;

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

Короче, я применяю именно подчеркивание.

добавь -fwrapv в опции

Благодарю, с этим флагом всё понятно и к нему вопросов нет.

Просто тут базар идет за сомнительный «эталон» и «стандарт», и что всё остальное г…, а все остальные идиоты и не программисты.

Я вот против этого, против крайностей. За нормальное и качественное понимание происходящего под капотом. А флагов в компиляторе/линкере тьма тьмущая, практически на любое требуемое поведение скомпилированной программы. Т.е. программист сначала придумывает, как в итоге должен работать бинарный код на процессоре, а потом пользуется теми инструментами, которые есть, включая флаги компиляции и линковки.

Для нативных программ, программу исполняет процессор, он и есть верховный судья.

PS. Думаю достаточно пофлудили, а то все уже и забыли, что тема про defer…

Я вот против этого, против крайностей.

Ты, кажется, против всего подряд тут. Против defer, против этого.

За нормальное и качественное понимание происходящего под капотом.

Под капотом происходит следующее: компилятор следует гарантиям, описанным в стандарте языка. Других гарантий компилятор не даёт.

А флагов в компиляторе/линкере тьма тьмущая, практически на любое требуемое поведение скомпилированной программы.

Поведение этих флагов может измениться в следующей же версии, и ты будешь переписывать свой говнокод. Сходи в багзиллу GCC и почитай вопли вот таких же говнокодеров, у которых новая версия компилятора сломала их код.

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

Программист должен подумать, как будет работать его код согласно абстрактной машине языка. Семантика абстрактной машины языка – это единственная гарантия, которую даёт язык. Потому что иначе процессор завтра будет другой (x86_64 -> ARM), и тогда код придётся переписывать.

Для нативных программ, программу исполняет процессор, он и есть верховный судья.

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

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

Вот этот вопрос интересно обсудить.
К примеру API Windows иногда меняется.
Как же в Windows работают программы с устаревшим API?
А вот как.
У них имеется подсистема, которая использует заплатки для наиболее популярных старых программ.

переполнение - это, по идее, тоже ошибка

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

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

А я наоборот, сторонник camel case, т.к. переменные получаются короче, чем с подчеркиваниями.

ИЧтоХорошегоВКороткихПеременных? Я_вот_предпочитаю_текст_максимально_близкий_к_естественному. Кажется, будто читать его легче.

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

Ой…

Что «ой»? Зачем повторять мои слова? И на какой вопрос этот вымышленный ответ?

Так и для беззнаковых я могу/не могу его проверять. Это, кстати, ещё одна проблема C - почему возможности, которые доступны в ассемблере, сделали недоступными в C? Почему я не могу писать c, overflow = a + b и потом проверять флажок overflow, а компилятор бы это всё скомпилировал оптимальным образом. Неудобно.

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

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

Официально в стандарте языка записано, если я не путаю, что переполнение знаковых целочисленных типов зависит от реализации (может генерироваться исключение, может игнорироваться), а беззнаковых игнорируется - значение приводится в представимый диапазон.
Т.е. получается примерно так - сам C/C++ встроенныхпереносимых средств обнаружения переполнения не имеет.
Но всегда можно использовать дополнительные методы, которые позволят по данным операндам выяснить, будет ли переполнение при выполнении операции. Масса таких вещей описана в книге Г. Уоррена Алгоритмические трюки для программистов.
Ну и как иллюстрация, насколько легко пропустить это переполнение - у Страуструпа в Программирование.
Принципы и практика… есть одна программка, в которой вычислялся ряд для ex, что ли - и она у него в разнос шла.
Он честно написал, что раньше, мол, я думал, что это связано с потерей точности в double, и вроде даже так и написал в первом издании книги, а потом ко второму изданию дошло, что на самом деле это переполнение целочисленных значений при вычислении факториала. Если уж даже Страуструп… :)

почему возможности, которые доступны в ассемблере, сделали недоступными в C?

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

Можешь! stdckdint.h правда это С23

Прикольно, но всё же это уже прикручено сверху. Всё же С оставляет желать лучшего. Надо делать свой язык.

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

Почти уверен, что путаешь. Там записано просто Undefined Behaviour, что и позволяет компилятору тупо выкидывать код. Конечно в этих оттенках коричневого разбираться стоит ли, не знаю, но написано так.

Экспромтом.

А если флаг переполнения процессора проверять?

без С23 это встроенные функции компилятора. для gcc: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html

ну и у других компиляторов они тоже есть.

Да если надо, понятно, что проверить не сложно. Можно просто обычными сравнениями, нынешние оптимизаторы умней меня, скорей всего сообразят, что реально надо проверять. Просто некрасиво это. Лучше бы доступ к битам сделали по индексу.

Ой нет, не надо, раст уже есть

Раст это замена для С++. Да и даже не вполне замена, а скорей альтернативный подход… С это другой язык. Опасный и близкий к железу. Ну по задумке так… По факту не всегда.

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

Опасный и близкий к железу.

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

с чего это близость к железу стала опасной?

Так говорят. Safe/Unsafe languages. Если можешь грохнуть программу через *((char*)0) = 0, значит опасная. Главная опасность, конечно, от простоты появления багов в таком коде.

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

Я и говорю, с С они немного в разных категориях.

Лучше бы доступ к битам сделали по индексу.

какой ещё «доступ к битам по индексу»? в Си никто не мешает тебе работать с битами, есть все битовые операции, есть битовые структуры. но работа напрямую с процессором и его регистрами в современных системах - это вещь нетривиальная.

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

Вообщем см. https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html

какой ещё «доступ к битам по индексу»?

Вот такой простой и понятный код:

GPIOB->CRH[10] = 0;

Вместо такого уродского кода:

GPIOB->CRH &= ~(1 << 10);

Так говорят. Safe/Unsafe languages.

это бредятина. так говорят люди, которые ниасилили какие-то языки. таким и нож в руки давать опасно: они себя и других порежут. но остальные все прекрасно пользуются ножом и ничего. Си даёт возможности. а уж как эти возможности использовать - это зависит от человека. и если человек утверждает, что «Си опасен», то это не Си, это он сам опасен для себя и окружающих. дураки могут быть опасны.

Имеется много хороших библиотек для работы с битами …

Это тот случай, когда библиотеками невозможно заменить встроенные возможности языка. Разве что на C++ можно сделать подобное всякими перегрузками. Но C++ это отдельная история…

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

Меняется поведение вокруг этих флагов в случае с UB. Потому что – и я удивлён, что это приходится вновь повторять – никаких гарантий относительно неопределённого поведения нет и быть не может.

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

что может быть более «компиляторозависимым», чем результат сборки кода с UB, которым тут некоторые кичатся?

массивов битовых полей в Си нет. но если очень хочется, можно написать функцию-обёртку и сделать её инлайновой. или даже написать макрос.

Мне вполне хватает union для работы с битами …

ИЧтоХорошегоВКороткихПеременных?

Даешь си-программы на эмодзи, ой, на китайском, стандарт не запрещает идентификаторы в юникоде (implementation-defined).

Rust кстати отлично заменяет сишечку. Я тут недавно опять попробовал для одного низкоуровневого проекта (no_std) и выходит крайне норм.

Меняется поведение вокруг этих флагов в случае с UB.

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