Терпеть это больше невозможно, мне надо где-то делиться всем счастьем, которое я встречаю в плюсах
(А также, в частности, в шланге)

В ast представлении шланга объявление класса выглядит как CXXRecordDecl нода
У неё есть дети-объявления (всякие using'и, методы и прочие friend'ы)
Первый деть-объявление — сама нода
Зачем? Затем

Мне тут @dedlocc скинул смешной мем
https://godbolt.org/z/5Gq9eKTeE

Когда-то очень давно хотел навалять пост про noexcept, потом он заглох, в итоге ничего сюда не писал

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

Когда вводили эту фичу, видимо понимали, что никто никогда не вспомнит вовремя навесить noexcept, потому есть офигенские правила вывода, бросающая ли функция

~Всегда да, ну кроме случаев, когда
* есть noexcept(true)
* это деструктор, ну кроме случаев, когда
* * деструктор кого-то из баз или полей не бросает
* это задефолтившиеся конструкторы copy/move/default, ну кроме случаев, когда
* * у кого-то из баз/полей этот конструктор бросает
* * задефолченный аргумент бросает при конструировании
дефолтно инициализирующиеся поля бросают
* это задефолтившиеся операторы присовения, нУ кРоМеСлУчАеВ, кОгДа
* * какой-нибудь вызов в них потенциально бросает

Сами компиляторы могут вывести, бросает ли ваша функция, если видят её полностью. И помните!
* noexcept, когда из вашей функции может что-то вылететь, провоцирует неявную вставку try-catch и`std::terminate`, если исключение всё же прилетит (я так делал вместо assert(false), чтобы в перф сборке уронить процесс, очень удобно)
* отсутствие noexcept сковывает оптимизации вашего кода (std::vector загрустит на resize, если ваши мув-конструкторы могут бросить)

Эх, надо было этот пост добить, когда горело ярче

Чёт я сам себя напрягаю тем, что мне иногда сложно думать в терминах плюсов

Пытаюсь сделать коротенькую функцию, которая разруливает мне владение штуками. Буквально один ифчик. Но складывалось либо так, что мне надо мувать this из константного метода, либо я выдаю ссылку на тухлый объект. Поделился дилеммой с товарищем, который не очень понимает кресты, но понимает раст. Решил для него накидать перевод на ржавом.... тут мне стало явственно до жути, в каком месте я хочу невозможного, после недолгих размышлений над своими желаниями всё легко разрешилось

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


P.S. а потом я понял, что этот метод мне вообще не нужен, всё иначе надо делать 🙂

Кек с поведения такой себе очевидности

struct Base 
{ 
protected: 
    int a; 
}; 
 
struct Derived : public Base 
{ 
    Base & as_base() { return *this; } 
    int get_a() { return as_base().a; } 
}; 

Это ошибка компиляции, потому что к

protected

вы можете обращаться только через свой класс

Почему так? В частности из-за того, что дети могут менять спецификаторы доступа

struct Base  
{  
protected:  
    int a;  
};  
  
struct Derived : public Base  
{  
    Base & as_base() { return *this; } 
private: 
    using Base::a; // превращаем 'a' в приватное поле 
};  
 
struct GrandDerived : public Derived 
{ 
    bool is_zero() 
    { 
        int parent_a = a; // нельзя доступиться, поле приватное 
        int grandparent_a = as_base().a; // компилятор наебать не выйдет (а хотелось!) 
    } 
};

Общение с почитателями Сей породило во мне внутреннего маленького Си-шника, который угарает над подобными штуками в 23-м стандарте