Дискуссия об использовании языка C++ для разработки ядра Linux

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

Дяденька, Вы вот сейчас на полном серьезе заявляете что видели ВСЕ серьезные проекты? И что нет областей где подобные идентификаторы являются не то что допустимыми - строго обязательными?!

Ваше самомнение просто зашкаливает, вкупе с неуклюжими попытками поставить диагноз по интернету… над Вами можно или смеяцца или глумиться.

Можно. std::stacktrace/boost::stacktrace в помощь.

А как-нибудь без костылей, которыми надо подпирать исключения, обойтись нельзя?

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

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

Ну а вы контекст разговора не видите? Всё ведь написано. Одни хотя обрабатывать исключениями восстановимые ошибки, другие называют их глупцами и утверждают, что в реальности это практически нереально следить за консистентностью данных (сложно, грязно, потеря лаконичности, многословно из-за обилия try catch) и основная годная тактика - оставить для исключений лишь критические ошибки и грохнать модуль пославший что-то.

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

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

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

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

Я-то другое вижу. А именно, что вы втираете людям, что можете, без бейсик сейфти, сделать то, для чего бейсик сейфти и нужен («грохнуть модуль» в вашей терминологии).

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

Убедились? Отлично! А теперь, прочитайте про бейсик сейфти, и поймите, что с вами никто даже и не спорил. По тому, что всё, что вы «предлагаете» - это совершенно очевидные юз-кейсы для бейсик сейфти (который, по-вашему, вам не нужен, ага).

Одним словом, разберитесь с мат частью, а потом уж спорьте. :) Хоть будете понимать, о чём именно спор.

Нет. Это можно сделать только в самом примитивном случае за счёт кучи умолчаний (не писали Вы сложных контейнеров с разными вариантами итераторов, хехе). Странно что это неочевидно.

И, заметьте - в новых стандартах указание типа не требуется. Т.е. думай-не думай, но новый стандарт таки позволяет писать лучший код.

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

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

Да мне достаточно было вот этого и аналогичных перлов:

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

чтобы понять, что вы с мат частью не в ладах. Разумеется, ваш контекст я «удосужусь» понять не раньше, чем вы мат часть осилите и начнёте корректно формулировать утверждения.

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

Шутка

Ждём C+++.

А как-нибудь без костылей, которыми надо подпирать исключения, обойтись нельзя?

А в чём собственно разница? Если бы в плюсах это же решение (std::stacktrace) выводило бы stacktrace для необработанных исключений ты бы уже не считал это костылями? Или в каком-нибудь расте оно по-твоему технически как-то по другому сделано?

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

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

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

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

Я намекнул, что это бейсик сейфти и есть.

Да затем, что если ты пытаешься использовать данные в модуле
после возникновения в нем исключения, то тебе необходимо
соблюдать strong_exception_safety

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

Да, если хочет восстановимые исключения, то нужны стронг гарантии от кидающей стороны.

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

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

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

Опять получается путаница в терминологии, и никакого реального повода для спора?

Вот тут и начнется оборачивание всего на свете в try catch на всякий случай.

Опять нет. Это только если он хочет наверх выдать nothrow гарантию, которая ещё сильнее, чем стронг. А если ему достаточно стронг, то он просто сделает, за счёт RAII, чтобы состояние откатывалось, если кто-то изнутри стреляет.

https://en.cppreference.com/w/cpp/language/exceptions Ознакомьтесь уже! Сколько можно в 3 соснах путаться (ну, в 4х).

Чего вы мне этой портянкой тычите? Я просил помощи? У меня все гуд, я знаю как использовать исключения на практике и делаю это.

Я рассказал как я использую исключения, чего вы все со сомной спорите то? Пришли какие-то крутые, продвинутые ребята, сказали, что они используют исключения для восстановимых ошибок, ну что же, желаю им всего хорошего. Делать правильные RAII обертки на все на свете, делать копии, свопать. И какая нахрен разница с try catch для всего подряд? Это доп нагрузка и епля своего мозга. Коль вы так любите меня цитировать, то ещё одна цитата из меня: «обеспечение стронг гарантий в своем коде - это адский ад».

Чего вы мне этой портянкой тычите? Я просил помощи? У меня все гуд, я знаю как использовать исключения на практике

А «в теории» - постоянно путаете типы гарантий, а их всего-то 4… Соответственно, и приходится вас носом в ртфм тыкать.

Я рассказал как я использую исключения, чего вы все со сомной спорите то?

А как вы могли это рассказать, если вы не можете общепринятую терминологию использовать? Плохо рассказали, стало быть. :)

Делать правильные RAII обертки на все на свете, делать копии, свопать. И какая нахрен разница с try catch для всего подряд?

Да, в общем то, большая. RAII - общепризнанный инструмент, используется чуть менее чем везде, и вполне позволяет давать стронг гарантии. А всё обвязывать в трай-кетч, не понимая, что это - другой уровень гарантий, который никто не просил - зачем это делать? Или, может, где-то это надо делать. Но точно не там, где вы предлагаете, тк вы говорите про один тип гарантий, а расписываете другой (и это происходит постоянно).

«обеспечение стронг гарантий в своем коде - это адский ад».

… пишите вы, описывая, при этом, nothrow гарантии… Может, для начала, приведёте в соответствие свои описания и свои же примеры? А потом и посмотрим, что получится?

… пишите вы, описывая, при этом, nothrow гарантии… Может, для начала, приведёте в соответствие свои описания и свои же примеры? А потом и посмотрим, что получится?

Может для начала сами букварь полистаете? Если что, можно throw текущее исключение из catch блока.

В общем разговор ни о чем.

Может для начала сами букварь полистаете? Если что, можно throw текущее исключение из catch блока.

И что? Для чего вы предлагаете сначала обернуть всё подряд в трай-кетч, повысив гарантии, а потом обратно их понизить через throw? Чтобы показать, как сложно реализовать стронг гарантии? Ну, можно ещё и не так упороться. При этом, мой прозрачный намёк, что и RAII вполне достаточно, почему-то остался без внятного ответа…

Слушай, до свидания, зануда.

т.е. нужен глобальный реестр кодов возврата (предполагаю, что как правило он есть) Ну и он особо ничего не упрощает.

А мне нравится:

enum class AllResultCodes {
	AAA,
	BBB,
	CCC,
};
enum class FResult {
	AAA = (int)AllResultCodes::AAA,
	BBB = (int)AllResultCodes::BBB,
};
enum class GResult {
	CCC = (int)AllResultCodes::CCC,
};

FResult f() { return FResult::AAA; }
GResult g() { return GResult::CCC; }

Правда задачу безопасного приведения FResult к GResult (если g() вызывает f()) эта фигня не решает. Чую, что решение есть, но думать лень.

UPD2: Например, можно нарисовать анализатор на clang libtooling, чтобы проверял, что если f() делает return g(), то элементы GResult были бы подмножеством элементов FResult. Гибко и не требует усложнения сорцов. И к слову, для работы такой проверки даже общий реестр кодов не нужен (хотя он нужен в самих сорцах, чтобы не получилось пересортицы).

UPD3: «если f() делает return g()» Точнее, натравливать libtooling на любые касты одного enum к другому.

Почитал дискуссию - ну его нафиг этот С++ в ядре.

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

обязательными они не являются примерно нигде. Допустимыми - разве что внутри функций, осуществляющих внутри себя матан по заданным формулам, в которых эти вот все v/u/f/μ/A имеют смысл.

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

#include <iostream>
#include <magic_enum_utility.hpp>


enum class Err1: int {
    E1 = 1,
    E2 = 2,
#ifdef WITH_ERROR
    E7 = 7,
#endif
};

enum class Err2: int {
    E1 = 1,
    E2 = 2,
    E3 = 3,
    E4 = 4,
};

template <class T> concept Enum = std::is_enum_v<T>;

template <Enum DST, Enum SRC>
constexpr DST err_cast(SRC src) noexcept {
    magic_enum::enum_for_each<SRC>([](auto val) {
        constexpr SRC choice = val;
        static_assert(magic_enum::enum_contains<DST>(static_cast<std::underlying_type_t<SRC>>(choice)));
    });
    return static_cast<DST>(src);
}



int main() {
    Err1 err1 = Err1::E2;
    std::cout << magic_enum::enum_name(err1) << std::endl;
    Err2 err2 = err_cast<Err2>(err1);
    std::cout << magic_enum::enum_name(err2) << std::endl;
}

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

Но это всё по-прежнему требует того, чтобы все разработчики делали именно так и не лепили где-то static_cast или ещё какие-то свои хотелки.

magic_enum::enum_contains

Гы, а я ведь когда-то это нагугливал. Но видимо не фштырило, раз забил и забыл.

// Меня вообще от шаблонной магии корёжит. В т.ч. как по мне, для задачи «проконтролировать то-то» решение «пишем тулзу, контролирующую то-то» – куда более прямолинейное и естественное, чем «нах@#вертим в сорцах гору нечитабельной дичи, чтобы компилятор, прожевав её, проконтролировал то-то ‘стандартными средствами’». Код пишется один раз, а читается тыщу.

Но это всё по-прежнему требует того, чтобы все разработчики делали именно так и не лепили где-то static_cast или ещё какие-то свои хотелки.

А внешний tidy-like анализатор не требует. :) Т.е. наоборот как раз требует, причём так, что его не обойдёшь – достаточно встроить его обязательным шагом в билд-скрипт.

В принципе, если упарываться ещё дальше, то эти enum’ы можно в структуры завернуть и сделать им конструкторы, которые будут автоматом преобразовывать значения с необходимыми проверками:

#include <iostream>
#include <magic_enum_utility.hpp>



template <class T> concept Enum = std::is_enum_v<T>;

template <Enum DST, Enum SRC>
consteval bool check_contains_all() noexcept {
    bool contains_all = true;
    magic_enum::enum_for_each<SRC>([&contains_all](auto val) {
        constexpr SRC choice = val;
        contains_all &= magic_enum::enum_contains<DST>(static_cast<std::underlying_type_t<SRC>>(choice));
    });
    return contains_all;
}

template <Enum DST, Enum SRC>
constexpr DST err_cast(SRC src) noexcept {
    static_assert(check_contains_all<DST, SRC>());
    return static_cast<DST>(src);
}



struct Err1 {
    enum class Error: int {
        Success = 0,
        E1 = 1,
        E2 = 2,
#ifdef WITH_ERROR
        E7 = 7,
#endif
    };

    const Error error;

    constexpr Err1(Error err) noexcept: error{err} {}
    constexpr Err1(std::underlying_type_t<Error> ec) noexcept: error{ec} {}

    constexpr operator bool() const noexcept { return error != Error::Success; } 
};



Err1 foo() { return Err1::Error::E2; }



struct Err2 {
    enum class Error: int {
        Success = 0,
        E1 = 1,
        E2 = 2,
        E3 = 3,
        E4 = 4,
    };

    const Error error;

    constexpr Err2(Error err) noexcept: error{err} {}
    constexpr Err2(std::underlying_type_t<Error> ec) noexcept: error{ec} {}

    constexpr Err2(Err1 err) noexcept: error{err_cast<Error>(err.error)} {}

    constexpr operator bool() const noexcept { return error != Error::Success; } 
};


Err2 bar() {
    Err2 err = foo();
    if (err) {
        return err;
    }
    // ...
    return Err2::Error::Success;
}



int main() {
    Err1 err1 = foo();
    std::cout << magic_enum::enum_name(err1.error) << std::endl;
    Err2 err2 = bar();
    std::cout << magic_enum::enum_name(err2.error) << std::endl;
}

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

А внешний tidy-like анализатор не требует.

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

чем «нах@#вертим в сорцах гору нечитабельной дичи, чтобы компилятор, прожевав её, проконтролировал то-то ‘стандартными средствами’». Код пишется один раз, а читается тыщу.

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

Ну я никогда так делать не пробовал и даже не представляю себе как к этому подступаться и какая там сложность.

https://www.youtube.com/watch?v=yuIOGfcOH0k

У меня помечено, что AST Matchers @15:18.

Синтаксис с тех пор чуток поменялся (матчеры начинаются с lowerCase), но идея и даже ЕМНИП bootstrap-код – в точности те же.

Вообще парни шикарную хрень запилили: полноценный удобный pattern matching над AST – на языке, в котором этот самый pattern matching в принципе отсутствует.

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

Ну дык сам tidy на libtooling и написан, об этом ЕМНИП есть в видео. Т.е. если ты можешь формализовать свои хотелки, то значит и на код их можно положить.

Ещё немного поупарывался:

#include <iostream>
#include <magic_enum_utility.hpp>



enum class AllError: int {
    Success = 0,
    E1 = 1,
    E2 = 2,
    E3 = 3,
    E4 = 4,
    E7 = 7,
};


template <class T> concept Enum = std::is_enum_v<T>;

template <Enum DST, Enum SRC>
consteval bool check_contains_all() noexcept {
    bool contains_all = true;
    magic_enum::enum_for_each<SRC>([&contains_all](auto val) {
        constexpr SRC choice = val;
        contains_all &= magic_enum::enum_contains<DST>(static_cast<std::underlying_type_t<SRC>>(choice));
    });
    return contains_all;
}

template <Enum DST, Enum SRC>
constexpr DST err_cast(SRC src) noexcept {
    static_assert(check_contains_all<DST, SRC>());
    return static_cast<DST>(src);
}



template <Enum T>
struct [[nodiscard]] Error {
    using ErrorEnum = T;
    static_assert(check_contains_all<AllError, ErrorEnum>());

    const ErrorEnum error;

    constexpr Error(ErrorEnum err) noexcept: error{err} {}
    constexpr Error(std::underlying_type_t<ErrorEnum> ec) noexcept: error{ec} {}

    template <Enum E>
    constexpr Error(E err) noexcept: error{err_cast<ErrorEnum>(err)} {}
    template <Enum E>
    constexpr Error(Error<E> err) noexcept: error{err_cast<ErrorEnum>(err.error)} {}

    constexpr operator bool() const noexcept { return error != ErrorEnum::Success; } 
};



enum class FooError: int {
    Success = 0,
    E1 = 1,
    E2 = 2,
#ifdef WITH_ERROR
    E7 = 7,
#endif
};

Error<FooError> foo() { return FooError::E2; }



enum class BarError: int {
    Success = 0,
    E1 = 1,
    E2 = 2,
    E3 = 3,
    E4 = 4,
#ifdef WITH_ERROR2
    E9 = 9,
#endif
};


Error<BarError> bar() {
    Error<BarError> err = foo();
    if (err) {
        return err;
    }
    // ...
    return BarError::Success;
}



int main() {
    auto err1 = foo();
    std::cout << magic_enum::enum_name(err1.error) << std::endl;
    auto err2 = bar();
    std::cout << magic_enum::enum_name(err2.error) << std::endl;
}

Чего вы мне этой портянкой тычите?

Там, кстати, именно про Error handling & Exception safety, а не вообще. Прям по пунктам все уровни сейфти разобраны.

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

нормально.

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

А покажите-ка, где эти «продвинутые ребята» говорили, что вы должны так делать? Может, они вам просто объясняли, что хочешь такой-то уровень гарантий - делай так. Хочешь только «модуль перезапустить» - делай этак. Покажите, где они вам хоть что-то навязывали. Ведь это именно вы пытаетесь своё мнение навязать. А вам-то просто объясняли, в каких случаях как действовать.

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

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

Не писали Вы сложных контейнеров с разными вариантами итераторов, хехе

Интересно даже, что это за АТД такой.

Ваше самомнение просто зашкаливает, вкупе с неуклюжими попытками поставить диагноз по интернету
AntonI

herra loistaa taas...

В таких вещах код должен абсолютно точно соответствовать бумажке, иначе потом фиг ошибку найдёшь.

Ну это уже просто неосиляторство. :)

AMR например

Напишите полностью, пожалуйста.

Сто пудов трёхэтажные template появятся ...

Если стандарты C++ не будут использоваться, а также STL, std,
метапрограммирование, ООП, ... , то в чём тогда профит от использования C++?

Тогда разработчики будут не ядро развивать, а «выгребать».

Теоретически, конечно можно использовать C++ для разработки ядра ...

Посмотрел по ссылке серенити. Я правильно понимаю, что это юай без ядра, который запускается как приложение внутри других ОС? Когда там в планах хотя бы внутри виртуалки запускаться?

https://en.wikipedia.org/wiki/Adaptive_mesh_refinement

(сорри, катался на лыжах и не увидел Ваш коммент).

утратил всякие надежды относительно будущего нашей страны

Учитывая скорое слитие персам, потом римлянам, и что сейчас в итоге на том месте Турция, в чём он был неправ?

Эээ чо? Нет, это целая ОС.

То есть персидская, римская и турецкая молодежь окахалась лучше греческой? Ну ок