defer в C быть!

не надо использовать UB. вообще никак, вне зависимости от флагов и поведения отдельных компиляторов.

lol расскажи это местным икспердам типа alysnix и Vic

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

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

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

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

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

напороться на переполнение в обычном софте практически невозможно

охлол https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=integer+overflow

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

зато короткие названия-«символы», почти как у математиков.

Просто используем текстовый файо с требуемой кодовой страницей.
В многих случаев этого достаточно.
Например в компиляторе C++ от Microsoft могу код писать как в а-ля 1С.

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

Мне сложно выразить свою мысль, но под заменой C я понимаю замену для человека, который умеет и любит пользоваться C

Если человек именно любит пользоваться Си, ему ничего не поможет.

Не согласен. В C я могу в одну строчку (ну в две, если не говнокодить) читать/писать по любому адресу. На каком ещё языке я так могу? Приведи мне аналог этого кода на Rust.

static void enable_port_clock(void)
{
    // enable I/O port C clock
    uint32_t rcc_base_address = 0x40021000;
    uint32_t rcc_apb2enr_address = rcc_base_address + 0x18;
    uint32_t rcc_apb2enr_iopcen = 1 << 4;

    volatile uint32_t *rcc_apb2enr_pointer = (uint32_t *)rcc_apb2enr_address;
    uint32_t rcc_apb2enr_value = *rcc_apb2enr_pointer;
    rcc_apb2enr_value |= rcc_apb2enr_iopcen;
    *rcc_apb2enr_pointer = rcc_apb2enr_value;
}

А мы для чего?
«Мы должны прям-таки нешадно бороться с теми кто используеи Си для разработки».

Ну, условно говоря, делается конфиг с префиксами и соответствующими типами. Если префикс типу не соответствует - линтер выдаёт предупреждение. Я же не говорю про овенгеривание абсолютно всего кода, в при использовании его во внутренних структурах, например. Именно случай с неправильным префиксом детектится автоматически очень легко.

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

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

Они на самом деле сами отмирают. Лойнус жаловался, что молодёжь этот ваш Си в рот имела, так что всё норм. Будет как с Коболом каким-нибудь.

В 1С все просто.
Любое число это VT_R8.
Всё!

Пошучу.

Для того и начал разработку подсистемы управления знаниям.
Но она все ЯП обнулит …

ну, есть и процессоры, у которых любой тип 32 бита. но мы о другом.

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

Это сделано, чтобы не подстраиваться под определённое поведение в случае переполнения. Иначе компилятору пришлось бы использовать другие, возможно более медленные инструкции чтобы обеспечить ж5лаемое поведение в пограничных случаях. UB даёт свободу компилятору при оптимизации

Проще говоря - Си не для дураков.

Я люблю пользоваться C, но к нему у меня накопился достаточно обширный список претензий. Я их не документирую, но вот некоторые, которые мне сразу в голову приходят:

1. Нельзя объявить глобальную неинициализированную переменную.
2. Нет удобного синтаксиса для доступа к битам.
3. Ушибленная на голову стандартная библиотека, ещё и прибитая гвоздями к языку в некоторых, не всегда очевидных местах.
4. Идиотский препроцессор, приводящий к макросам, которые порой без поллитра не разберёшь.
5. Куча ненужных фич. Идиотский цикл for, ненужный цикл do-while. Цикла while хватит каждой домохозяйке, а вот break/continue на два уровня выше до сих пор не придумали. switch пофиксить надо было ещё сто лет назад. И такого много на самом деле.
6. Вот в этой теме обсосали уже всё, что касается переполнения, это всё неправильно. Как надо: любое переполнение вызывает ошибку, но есть синтаксис, который игнорирует ошибку или позволяет проверить переполнение.
7. Нет множественных возвращаемых значений, приходится извращаться со всякими указателями или структурами, это всё неудобно.
8. Упоротые оптимизации, которые порой вызывают WTF. Такого не должно быть. Оптимизации должны помогать, а не мешать. Если я пишу пустой цикл из 1000 итераций, значит его надо компилировать, а не выпендриваться. Хочешь выпендриться - выдай warning. То же про выкидывание кода из-за UB при переполнении - такого не должно быть, я написал код, значит я его хочу, есть вопросы - выдавай warning, но компилируй как я написал.

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

Даже в 64битном msvc?

ЭЭЭ… да в смысле? с точностью до минимальных синтаксических переобозначений то же самое:

let p = 0x244124123 as *mut u32;

и вперёд, и арифметика указательная на месте и volatile какой-нибудь, и плюс, в отличие от сишечки(на сколько помню), api для провенанса

Цикла while хватит каждой домохозяйке

Не хватит. Простой цикл «от a до b включительно» не представим в сишке без чудовищных костылей.

А я ровно дышу.
Своё crt, подситема управления динамическими переменными и объектами любой сложности для run-time, … Публиковать не буду, так подсистема управления знаниям обнулит
все мои труды.
Это будет поначалу не а-ля ИИ, а что-то типа ТЗ …

int i = a;
while (i <= b) {
  body;
  i = i + 1;
}

И читается на порядок проще, чем аналог с for.

Сторонние библиотеки для проверок вроде is_even()? Ну это уже верх неосиляторства...

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

«Запад нам поможет» …
Быстренько сбросились мне по сто рублей на развитие проекта …

я msvc (да и сам маздай) не видела уже оооочень давно. почти 20 лет уже. но думаю, что ассемблер там никуда не делся. битность вряд ли влияет.

Ещё нужно уметь мыслить не по «понятиям компиляторов» …

Окей, a = INT_MAX-5, b = INT_MAX, вперёд.

эй, алё, какие «костыли»? обычный for:

for(i=a;i<=b;i++)

Чудовищный костыль

for(i = a; i <= b; i++);

https://learn.microsoft.com/en-us/cpp/assembler/inline/inline-assembler?view=...

Inline assembly is not supported on the ARM and x64 processors. The following topics explain how to use the Visual C/C++ inline assembler with x86 processors:

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

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

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

PS. Простите, не удержался…

Суждение о другом было …

ну, насчёт ARM: ты вообще видел ассемблер для ARM-ов? это довольно страшное извращение. я про него только почитала когда-то, но трогать руками не стала. писать на этом, может, и можно, но очень грустно.

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

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

И чем тебе тут for поможет?

Шутка: a=1;;;;;;;;;;;;;;;;; и всё ok.

Если ты про то, что в C нет цикла по диапазонам, то я тут только соглашусь. Если for и делать, то полезный. for (i: a ..= b) { ... } например, для твоего случая. Но не тот for, который в C сейчас.

Да ничем, в том-то и дело. Си ужасен.

a = INT_MAX-5, b = INT_MAX

Видел и даже пользовался немного. И он даже удобнее интеловского во многих случаях, пусть и не имеет такого огромного количества инструкций.
Но факт остаётся фактом - inline assembly в msvc на современных архитектурах отсутствует, да и синтаксис там был несовместимый со всем остальным (частично его умел старый icc).
Конечно, зачем msvc вообще существует, мало понятно - ведь даже если нужна ABI совместимость с windows/msvc кодом - обычно с этим справляется clang, но раньше его не было и испрльзование msvc на windows для некоторых проектов - просто дело привычки

В отдельных файлах ассемблер то можно использовать, они убрали только инлайновый

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

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

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

• Глобальную переменную объявить можно (просто напиши ее вне функций). Можно даже поработать с той переменной, которой нет в твоем коде (используя адрес переменной в адресном пространстве). Если что, у процессора нет переменных, он всегда пользуется адресом в адресном пространстве, а количество изменяемых байт определяется кодом команды. По той же самой причине, в синтаксисе си-функций нет возврата множества переменных, поэтому нам, как и процессору, надо использовать адреса переменных.

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

• За break/continue скрываются команды перехода (jump) на автоматически сгенерированные метки, defer продолжает эту традицию, но еще более извращенным образом. Они (стандартописатели) могли бы сделать defer оператором блока кода и тела функции, как else у if, чтобы было явно видно, где это кусок кода встанет, но нет, им подавай неявность (синтаксический сахар с солью и какао).

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

PS. Ни на что не претендую, спорить ни с кем не буду, просто перечислил то, что есть.

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