LINUX.ORG.RU

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

 , c18, ,


6

8

Международная Организация по Стандартизации (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 ()
Последнее исправление: tailgunner (всего исправлений: 3)

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

Какой же это Эдик? Много умных слов, ни одной истеричной нотки.

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

И эти люди ещё гнобят плюсы

for (var object : objects) {
    if (auto mover = dynamic_cast<Mover*>(object))
         mover->move();
    if (auto renderer = dynamic_cast<Renderer*>(object))
        renderer->render();
}

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

В жабе также, там нельзя не от Object наследоваться

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

не получит

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

ещё как получится

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

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

Проблема (вроде бы) решилась использованием виртуального наследования:

#include <stdio.h>

struct Object {
    virtual void dummy() {};
};

struct Mover : virtual Object {
    virtual void move() = 0;
};
struct Moveable : Mover {
    int *position, *velocity;
    void move() {
        printf("{position:%d, velocity:%d}.move()\n", *position, *velocity);
        *position += *velocity;
    }
};

struct Renderer : virtual Object {
    virtual void render() = 0;
};
struct Renderable : Renderer {
    int *position, *color;
    void render() {
        printf("{position:%d, color:0x%x}.render()\n", *position, *color);
    }
};

int main() {
    Object *objects[1];
    {
        auto position=0, velocity=3, color=0xff0000;
        Renderable renderable;
        renderable.position = &position;
        renderable.color = &color;
        Moveable moveable;
        moveable.position = &position;
        moveable.velocity = &velocity;

        struct : Renderer, Mover {
            Moveable moveable;
            void move() {moveable.move();}
            Renderable renderable;
            void render() {renderable.render();}
        } entity;
        entity.moveable = moveable;
        entity.renderable = renderable;
        objects[0] = dynamic_cast<Object*>(&entity);
    }
    for (auto object : objects) {
        if (auto mover = dynamic_cast<Mover*>(object)) {
            mover->move();
        }
        if (auto renderer = dynamic_cast<Renderer*>(object)) {
            renderer->render();
        }
    }
    return 0;
}
Хотя пихать в Object виртуальный метод dummy() только для того чтобы сделать тип полиморфным — это всё равно уродливо. Но вроде работает.

anonymous
()
Ответ на: комментарий от anonymous
 
   {
        auto position=0, velocity=3, color=0xff0000;
        ...
    }

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

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

Использует неполиморфный struct вместо class, смесь C и C++...

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

Хм, может и нет тогда причины избегать множественного наследования реализаций, раз уж C++ так здорово его поддерживает:

#include <stdio.h>

struct Object {
    virtual void dummy() {};
};

struct Moveable : virtual Object {
    int *position, *velocity;
    void move() {
        printf("{position:%d, velocity:%d}.move()\n", *position, *velocity);
        *position += *velocity;
    }
};

struct Renderable : virtual Object {
    int *position, *color;
    void render() {
        printf("{position:%d, color:0x%x}.render()\n", *position, *color);
    }
};

int main() {
    Object *objects[1];

    auto position=0, velocity=3, color=0xff0000;
    struct : Renderable, Moveable {} entity;
    entity.Renderable::position = &position;
    entity.Renderable::color = &color;
    entity.Moveable::position = &position;
    entity.Moveable::velocity = &velocity;
    objects[0] = dynamic_cast<Object*>(&entity);

    for (auto object : objects) {
        if (auto moveable = dynamic_cast<Moveable*>(object)) {
            moveable->move();
        }
        if (auto renderable = dynamic_cast<Renderable*>(object)) {
            renderable->render();
        }
    }
}

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

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

ты не знаешь биологию, потому что в твоем ДНК не решена turing bus stop problem, а как известно ДНК - простейший turing car. живи с этим.

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

Есть же std::any (boost::any). Их и храните в массиве. Проверяйте elem.type(), безопасно кастуйте с std::any_cast<T>().

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

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

Да, в С++ не идут в сторону динамического полиморфизма. Вообще.

Теперь нам нужно обойти этот список и вызвать методы этих интерфейсов на тех объектах которые их (интерфейсы) реализуют, а те объекты которые не реализуют — молча проигнорировать.
А в C++ как? Если наш список будет хранить void*,

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

Если наш список будет хранить void*

Кстати, в современном С++ void* — моветон. Наиболее похожие альтернативы — std::any и std::variant<T...>.

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

ты не знаешь биологию

Да я не биолог и?

потому что в твоем ДНК не решена

Я то ладно не знаю, но не фанатазирую, или это твоя жалкая попытка унизить меня шуткой про ДНК, ну, ты опозорился сам поздравляю.

uring bus stop problem

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

а как известно ДНК - простейший turing car.

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

простейший turing car.

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

Давай не будем сраться на ровном месте? Тут и так нездоровая атмосфера.

Deleted
()

Ядрен батон! Я только книжку по С11 скачал и начал офигевать с рандомной инициализации элементов массива, а тут еще...

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

всё стало в разы яснее

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

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

Зато можно так

Можно и сяк, а можно бензопилу заводить зажимая цепь в коленях.... но никто так делать не будет.

Можно и return писать после первой скобки в main и кричать ойййй как язык такое позволяет!нинужнааа ничиго ни работаит ))))))))))

Deleted
()
Ответ на: комментарий от kostyarin_

Так тоже нельзя по стандарту.

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

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

Когда начнёт эрроры выдавать, основываясь на стандарте, тогда и поговорим.

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

Можно и сяк, а можно бензопилу заводить зажимая цепь в коленях.... но никто так делать не будет.

Я не про undefined behavior или что там, а про читаемость кода в 100% случаев у Си с этим конкретные проблемы. Я не знаю, чем должен руководствоваться человек в наше время, чтобы выбирать Си, как язык программирования. Хотя язык сам по себе весьма не плох. Если выкинуть из него половину возможностей. Или больше.

Dixi.

P.S.: там чувак говорил про то, что компилер всё это решает выбрасывая варнинги. Есть какой-то смысл делать страшную буку, чтобы потом компилер-мэйкеры пытались её исправить? Вопрос риторический.

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

Есть какой-то смысл делать страшную буку, чтобы потом компилер-мэйкеры пытались её исправить?

Спроси тех, кто так пишет. Взять, к примеру, darktable - сомневаюсь, что там есть подобного рода конструкции, затрудняющие чтение.

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)

Тред заполен плюсовиками. А ну кыш отсюда! Это зона чистых Сишников.

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

Ядрен батон! Я только книжку по С11 скачал и начал офигевать с рандомной инициализации элементов массива, а тут еще...

Стандарт 18 года фиксирует недочёты и ошибки стандарта 11 года. Разница в одной строке.

Стандарт C11 вводит нативную поддержку Юникода (не путать с многобайтными символами). А также в духе времени даёт описание многопоточности. Хотя, Си и без многопоточности сам по себе офигенно быстр.

С11 делает некоторые положения C99 необязательными (не получилось не срослось). Стандарт диктует программисткая практика, а не комитет. Комитет лишь фиксирует реальное положение дел.

И д,а растаманы и плюсовики (думающие что это подмножество) пошли отсюда вон!

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

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

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

:D Вот и славно, тогда я тоже.

Deleted
()
Ответ на: комментарий от kostyarin_

а про читаемость кода в 100% случаев у Си с этим конкретные проблемы.

Ой ли? ))))) Это в любом языке всё зависит от конкретного случая и того кто писал, ну и почему именно так писал, а не иначе. Скажи только в других языках есть сахара что сглаживают вещи, да но и то не проблема берёшь макрос и делаешь из него сахар, оверхеда нуль и выглядит хорошо. Проблемы есть порой, да, ну так они везде есть с каждым рабочим инструментом. Фломастеры на вкус и цвет разные.

Deleted
()

а лишь исправляет дефекты

Сишка сама по себе один сплошной дефект, ее только на свалку истории.

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

Именно поэтому в Rust был выбран иной синтаксис, более пониманиемый чем ваш C, Java и JS.

Аахахахахах

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

Тебе - нечего. Ты рабочую программу-то на си написал? Другие языки знаешь? Судя по твоим комментам (хотя бы в этой теме) - нет.

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

Тут было, логинься и в удалённых смотри, то был троллинг и пару фейлов, но ещё было в треде про xml. Читай, развлекайся и продолжай вопросом на вопрос отвечать. Покедава, жди профессионалов для беседы.

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

А как значение указателя может стать неопределённым («The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime.»), если любой объект сохраняет своё последнее записанное состояние («An object retains its last-stored value throughout its lifetime»)? Эти два утверждения можно согласовать только если предположить, что окончание времени жизни объекта приводит к store в любой указатель, указывающий на него. В т.ч. в volatile-указатели (что является наблюдаемым поведением) и atomic-указатели (и непонятно, как этот store взаимодействует с happens-before и проч.)

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

последнее записанное состояние

последнее записанное значение, конечно же.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.