LINUX.ORG.RU

Новый стандарт языка C: C18

 , , ,


6

7

Международная Организация по Стандартизации (ISO) опубликовала новый международный стандарт языка программирования C: ISO/IEC 9899:2018, его также называют C17 и C18.

Новый стандарт не вносит никаких новых возможностей, а лишь исправляет дефекты, сообщенные для C11. Значение макроса __STDC_VERSION__ увеличено до 201710L.

Поддержка C18 у GCC появилась, начиная с 8 версии, а у LLVM Clang — с 6.0. Чтобы указать во время компиляции использование стандарта C18 у GCC и LLVM Clang используются флаги -std=c17 и -std=gnu17. В GCC можно также указать новый стандарт флагами -std=c18 и -std=gnu18.

Последний черновик стандарта

Статья на en.wikipedia.org

>>> Подробности

★★

Проверено: jollheef ()
Ответ на: комментарий от WatchCat

Что-то не видно этого самого развития.

Ну так для этого надо смотреть.

он совершенный макроассемблер.

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

tailgunner ★★★★★ ()
Ответ на: комментарий от ArkaDOSik

По факту реализовано почти всё, но это «почти» уже наложение ограничения что в одном месте заведётся, а в другом нет. Условиться же давайте писать на с99 но на ms компиляторах не будем использовать это это и это,а потом давайте перейдём на с11 но не будем использовать нативные треды потому что они только в musl только под linux и работают поверх pthread. Вот что бы не было всяких этих, а если и но и вот тут вот так, а тут эдак выл выбран c89 как проверенный временем и железно надёжный.

И да с89 не сильно отличается от вот вот принятого c18 так что не шибко и нужно.

А с C++ та же песня?

Не знаю

linux-org-ru ()
Последнее исправление: linux-org-ru (всего исправлений: 2)
Ответ на: комментарий от dimgel

C++ является по сути надмножеством C

Вывод не верный. Тот, кто это сказал (вроде это был Кнут) в один котёл кинул самодостаточный приём структурного программирования и концепцию ООП. Ещё Кнут говорил, что «Си язык среднего уровня», хотя согласно строгому разделению языков не существует т.н. «среднего уровня». Кнут пишет свои книжки для умных, а не для дураков. Потому-что умные всё поймут как надо, с полуслова, а дураки поймут неправильно.

Дуракам поясняю: процедурный стиль программирования - это самодостаточное явление, ему не нужно ООП. В строгом смысле в ООП не может быть, например «присваивания», чисто концептуально. Для чистого структурного языка ООП - это ненужный костыль.

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

anonymous ()
Ответ на: комментарий от invy

Хм, а я думал к 2018 всё уже осознали вред наследования. Интерфейсы + делегация (например выражаемая с помощью ключевого слова by в Kotlin, или в Golang элегантно с помощью анонимных полей) решают задачу прекрасно. Наследование не нужно.

anonymous ()
Ответ на: комментарий от tailgunner

Тылгунеру

C++ или C# - это юнцам по вкусу.
За решёткой есть жизнь, и на кладбище есть плюсы,
Но мой папа не любит эти модные приколы,
Только чистый Си, по заветам старой школы.

(Let me speak from my heart, C will never die, перепрошивай, пере-перепрошивай.
Си не умрёт никогда, так и знай. На нас работы хватит, не переживай.
Let me speak from my heart! C will never die! Перепрошивай! Пере-перепрошивай!
Си не умрёт никогда, так и знай!! Перепро-перепро-перепрошивай!!!)

anonymous ()

Новый стандарт не вносит никаких новых возможностей, а лишь исправляет дефекты

лол, без багов не могут написать даже стандарт, видимо писали его за границами массива данных

rust_afari ()
Ответ на: комментарий от invy

А сишники велосипедят свои системы типов а-ля плюсы,только глючнве и опасные.

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

rust_afari ()
Ответ на: комментарий от invy

опасные

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

anonymous ()
Ответ на: комментарий от rust_afari

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

anonymous ()
Ответ на: комментарий от rust_afari

наследование вредно также как холестерин

Вреден не холестерин, а его количество в купе с видом переносчика . Горе ты луковое ))) Уж не суйся из программирования в биологию и биохимию там всё слишком сложно ))

linux-org-ru ()
Ответ на: комментарий от anonymous

К слову, в C++ динамический полиморфизм реализован крайне негибко. Поправьте если чего не знаю, но я так и не смог реализовать всю мощь посылки сообщений (как в Smalltalk или Objective-C) с помощью плюсового RTTI. Например, имеем объект реализующий несколько интерфейсов, и допустим, мы его кастанули в универсальный объект (Object в терминах Java, или interface{} в терминах Golang) чтобы поместить в список вместе с другими, произвольными объектами. Теперь нам нужно обойти этот список и вызвать методы этих интерфейсов на тех объектах которые их (интерфейсы) реализуют, а те объекты которые не реализуют — молча проигнорировать. В Java это сделать несложно, оно будет выглядить подобно следующему:

for (var object : objects) {
    if (object instanceof Mover)
        ((Mover)object).move();
    if (object instanceof Renderer)
        ((Renderer)object).render();
}
В Golang'е это тоже вполне легко:
for _, object := range objects {
    if mover, ok := object.(Mover); ok { mover.move() }
    if renderer , ok := object.(Renderer); ok { renderer.render() }
}
А в C++ как? Если наш список будет хранить void*, то тогда мы не сможем делать динамические касты. Чтобы они работали, нам нужно создать вспомогательный «универсальный» объект имеющий по крайней мере один виртуальный метод. И сделать чтобы список хранил эти объекты. А чтобы динамические касты работали для каждого интефейса, они должны наследовать от того универсального объекта. Но тогда, при реализации нескольких интерфейсов объект получит конфликт множественного наследования. И в пользу какого интерфейса тогда он должен разрешать конфликт? //И вот такое в плюсах всю дорогу...
В пользу какого бы не разрешил, динамо-кастовать объект в остальные интерфейсы уже не получится.

anonymous ()
Ответ на: комментарий от tailgunner

в интернетах хвалят http://icube-icps.unistra.fr/img_auth.php/d/db/ModernC.pdf

Думаю, справедливо хвалят. По крайней мере, там определяют арифметику указателей как переход от одного элемента массива к другому, а не «к значению указателя прибавляется N*sizeof(T)...» и прочий подобный бред.

anonymous ()
Ответ на: комментарий от linux-org-ru

Полной поддержки c99 нет ни в одном компиляторе, не говоря уже про c11 и выше.

Да и не может быть. Стандарт противоречив в некоторых местах или содержит в принципе нереализуемые вещи. Как можно «полностью» поддерживать несамосогласованную спецификацию? Это как добиться неукоснительного выполнения взаимоисключающих параграфов.

anonymous ()
Ответ на: комментарий от tailgunner

Тебе вечно всякая ерунда кажется.

Макро (macro, от др.-греч. μακρός — длинный, большой) Первая часть составных слов в значении «длинный», «больших размеров» (цы)

WatchCat ★★★★ ()
Последнее исправление: WatchCat (всего исправлений: 1)
Ответ на: комментарий от WatchCat

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

Тебе вечно всякая ерунда кажется.

Макро (macro, от др.-греч. μακρός — длинный, большой)

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Ну так для этого надо смотреть.

Ну так покажи в чём развитие C18.
В багфиксах?

Выше вон показательный пример как развивается сишечка, что досихпор сидят на C89.

WatchCat ★★★★ ()
Последнее исправление: WatchCat (всего исправлений: 1)
Ответ на: комментарий от anonymous

К слову, в C++ динамический полиморфизм реализован крайне негибко.

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

dimgel ()
Ответ на: комментарий от WatchCat

Ну так покажи в чём рпзвитие C18. В багфиксах?

Да.

Выше вон показательный пример как развивается сишечка, что досихпор сидят на C89.

Если ты считаешь стиль кодирования Gtk «примером как развивается сишечка» , это твоя проблема.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

1.Ага, развитие. За семь лет только на багфиксы и сподобились.

2.Нет, это проблема реализаций стандартов сишечки.
И соотвественно разработчиков на сишечке.

WatchCat ★★★★ ()
Ответ на: комментарий от WatchCat

1.Ага, развитие. За семь лет только на багфиксы и сподобились.

А если брать последние семь часов, то развития и вообще нет.

Нет, это проблема реализаций стандартов сишечки.

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

tailgunner ★★★★★ ()
Ответ на: комментарий от WatchCat

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

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

это ты про мелкомягких так? ну-ну.

Я понимаю твою боль, но да, я и про них тоже.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от anonymous

Для унификации же. Например, Вы знакомы с задачей паттерна entity-component-system? Есть сцена, в ней куча объектов. Одни объекты имеют скорость, так что им нужно инкрементировать положение. Вторые имеют видимую форму, так что их нужно отрисовать на экране. Третьи имеют плотность, так что они должны прогоняться через collision detector. И так далее. Естественно, объекты могут совмещать эти роли/интерфейсы. Если не хранить их все в одном списке, то тогда как? Несколько списков для каждой отдельной комбинации ролей? Но тогда при добавлении очередной комбинации, нам нужно создавать новый список специально для таких объектов, писать его обход и в иных отношениях интегрировать в систему. Другая, более удачная альтернатива — сделать несколько списков для каждой отдельной роли/интерфейса. Но и тогда, опять же, при добавлении/удалении интерфейса нам нужно заботиться о его списке отдельно.
А тут всё унифицировано: при добавлении очередной роли просто добавляем её обработку в общий цикл (юзая динамический кастинг). И всё само работает.

anonymous ()
Ответ на: комментарий от tailgunner

да, я и про них тоже.

А что с ними?

C:\>cl.exe c99.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26726 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

c99.c
Microsoft (R) Incremental Linker Version 14.15.26726.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:c99.exe
c99.obj

C:\>c99.exe
Number of tests failed: 0.

Последний пример из http://www.cplusplus.com/articles/iz3hAqkS/

LamerOk ★★★★★ ()
Ответ на: комментарий от tailgunner

Что это вообще такое?

Одна из самых распространённых реализаций С/С++.

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

Топик вроде бы о C18.

Ну, как скажешь.

LamerOk ★★★★★ ()
Ответ на: комментарий от anonymous

По-моему в ECS не применяется наследование.

Это его отличие от развесистых иерархий Скелетов-с-Мечом, которые наследники Скелетов и Мечников.

anonymous ()