Грокаем C++

Новый год Вот и подходит к своему завершению 2025 год. Самое время подвести его итоги. Но я не буду перечислять список полезных или популярных постов. Кто захочет, то найдет. Я хочу поделиться состоянием(вайбом для зумеров) от завершающего свой последний аккорд года. ⚡️ Меня радует, что качество постов наконец-то меня удовлетворяет. Не по обертке(всегда бывают косяки), а по сути, структурированности и целостности. Можете ради интереса вернуться к первым постам и проследить эволюцию стиля. Количество юморесок и степень свободы изложения заметно сократились в угоду системности. Это логичная проф деформация, когда каждый раз при написании постов делаешь инъекцию 3-х кубиков стандарта внутривенно. Это несомненно позитивные изменения. Но теперь хочется, чтобы маятник вновь качнулся в сторону развлекательного аспекта. Все-таки мы здесь покекать пришли, а не плюсы учить. Или у вас не так?) ⚡️ Канал свел меня с прекрасными людьми, с которыми у нас началось сотрудничество по части плюсов и не только. Я очень вырос благодаря этим связям и не могу наудивляться, насколько у нас здесь клевые ребята собрались. ⚡️ Очень радует, что подписчики все чаще предлагают какие-то идеи для постов, особенно лично. Благодаря некоторым появились даже целые рубрики. Видно, что наше коммьюнити живое и активно развивается. У нас можно и поболтать за жизнь, и похоливарить на тему языков, и узнать что-то новенькое от крутых спецов. Есть более профессиональные чаты для гурманов и заядлых сомелье С++, но мне кажется, что определенную нишу мы заняли. У меня это был эпический год по всем направлениям в жизни. Накопилась большая усталось, но при этом на лице улыбка. И хочу вам сказать большое спасибо. Всем и каждому. Именно благодаря вам я расту и развиваюсь. Благодаря вам куча людей в принципе может регулярно получать небольшую порцию любимого С++ к обеду. Надеюсь, что канал вам нравится и вы находите его полезным. Без вас ничего этого не было бы. Желаю вам в будущем году плотно и потно трудиться. Легко не будет, особенно начинающим, но у вас все получится. Идите к своим целям на всех парах. Верю в вас всех и каждого. С Новым годом, друзья! С новым счастьем!☃️🎊🎉🎄

​​Наследие Cfront. Манглирование #новичкам В С нет перегрузки функций, поэтому там люди вынуждены каким-то образом руками разделять имена функций. Вместо

    
        void print(int x);
void print(float x);{}
    

Там пишут:

    
        void print_int(int x);
void print_float(float x);{}
    

Плюс линкеры работают с именами символов. А имя функции в С не включает в себя параметры. Поэтому во всей программе не может быть двух функций с одинаковыми именами. Линкер их банально не различит и выдаст ошибку множественного определения. А в С++ была перегрузка и надо было каким-то образом плюсовые перегруженные функции превращать в неперегруженные сишные при трансляции кода. Для этого было придумано декорирование имен или name mangling. Самый простой способ - добавлять к конце функции ее параметры в закодированном виде: ИмяФункции_ТипыПараметров:

    
        void draw(int x, int y);
void draw(double x, double y);

// Cfront mangling:
draw_i_i          // draw(int, int)
draw_d_d          // draw(double, double)  {}
    

Так как у нас не может быть двух перегрузок с разными возвращаемыми значениями, то кодирование типа возврата не нужно. Но это самое базовое представление о декорировании имен. Давайте посмотрим, что еще может влиять на итоговое имя функции: 👉🏿 2 разных класса могут иметь методы с одинаковым названием. Так как при трансляции в С это были просто свободные функции, манглинг должен учитывать и имя класса:

    
        void Circle::paint(Color c);
void Square::paint();
Rectangle::~Rectangle();
Shape::~Shape();

// transform into

void Circle_paint_Color(struct Circle* this, Color c);
void Square_paint(struct Square* this);
void Rectangle_dtor(struct Rectangle* this);
void Shape_dtor(struct Shape* this);{}
    

👉🏿 Есть же еще и пространства имен. Они помогают разграничить скоуп существования имен. И названия пространства имен тоже манглировались в имена функций:

    
        namespace Graphics {
    class Canvas {
        void clear();
    };
}

// transform into

void Graphics_Canvas_clear(struct Canvas* this){}
    

👉🏿 В С++ когда-то появились шаблоны. Шаблон всегда инстанцируется с каким-то типом. И чтобы различать эти инстанциации, Cfront манглировал типы шаблонных параметров в полное имя типа:

    
        template<typename T>
class Stack {
    void push(T value);
};

Stack<int> stack;

// transforms into

Stack_int_push_i(int value);{}
    

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

    
        
void Circle::rotate(int);

// transforms into 

_ZN6Circle6rotateEi

// Разбор:
_Z                   - префикс C++
N                    - вложенное имя
6Circle              - длина=6, "Circle"  
6rotate              - длина=6, "rotate"
E                    - конец аргументов
i                    - тип int{}
    

Шаблоны, неймспейсы, noexcept и const квалификаторы - все вшивается в имя символа. Вы также можете вручную управлять манглингом: включать и выключать его:

    
        extern "C" void c_function();   // Без манглинга: _c_function
extern "C++" void cpp_function(); // С манглингом: _Z10cpp_functionv{}
    

Это нужно для совместимости ABI интерфейсов, предоставляемых библиотеками. Поэтому декорирование имен живее всех живых и повсеместно используется в современных компиляторах. Have a legacy. Stay cool #cppcore #goodoldc #compiler

​​Компилятору достаточно лишь правильно положить аргументы функции в правильные регистры, согласно calling conventions. Какие аргументы нужно подготовить компилятор знает заранее, так как сигнатура виртуальных методов одинакова для всех переопределенных вариантов. Остается лишь call'ьнуть нужный указатель и происходит виртуальный вызов. Подкапотоное устройство полиморфизма часто спрашивают на собесах. Теперь вы знаете, как отвечать почти на полный спектр вопросов по этой теме. Know whats under the hood. Stay cool. #compiler #cppcore

Современные таблицы виртуальных функций #опытным С++ давно ушел от компиляции в С. Но таблицы виртуальных функций, как средство реализации динамического полиморфизма, остались в компиляторах. Как устроены vtables сейчас, когда С++ напрямую компилируется в ассемблер? Идея все та же: 👉🏿 На каждый полиморфный класс создается своя vtable 👉🏿 Она представляет собой просто массив адресов. В ассемблере адреса нетипизированные, поэтому они просто лежат там чиселками. 👉🏿 В каждом объекте хранится vptr - указатель на эту таблицу. 👉🏿 vtpr инициализируется в самом базовом классе его адресом его vtable и затем каждый конструктор наследника присваивает в него адрес своей таблицы Реализации вносят свои особенности, но это ядро остается неизменным. Вот примерчик(можете смотреть на годболте):

    
        class Person {
protected:
    std::string name;
    int age;
public:
    Person(const std::string &n, int a) : name(n), age(a) {}
    virtual std::string getRole() const { return "Person"; }
    virtual std::string getName() const { return name; }
    virtual void describe() const {
        std::cout << name << " (" << age << " years)";
    }
    virtual ~Person() = default;
};

class Employee : public Person {
    std::string position;
public:
    Employee(const std::string &n, int a, const std::string &pos)
        : Person(n, a), position(pos) {}
    std::string getRole() const override { return "Employee"; }
    void describe() const override {
        std::cout << name << " (" << age << " years) - " << position;
    }
};

int main() {
    Person * p = new Employee("Steven", 42, "CEO");
    p->describe();
    std::cout << p->getName() << std::endl;
}{}
    

Будем сейчас разбирать gcc-шный асм. Вот так выглядят таблицы для обоих классов:

    
        vtable for Person:
.quad 0
.quad typeinfo for Person
.quad Person::getRoleabi:cxx11 const
.quad Person::getNameabi:cxx11 const
.quad Person::describe() const
.quad Person::~Person()

vtable for Employee:
.quad 0
.quad typeinfo for Employee
.quad Employee::getRoleabi:cxx11 const
.quad Person::getNameabi:cxx11 const
.quad Employee::describe() const
.quad Employee::~Employee(){}
    

quad - это 64-битное число. Видно, что таблицы - это статические массивы. Первым числом у них является offset to top, это число нужно для корректной работы множественного наследования, не будем вдаваться в детали. Второй число - адрес расположения информации о динамическом типе(RTTI) объекта. Эта информация нужна, например, для dynamic_cast'а. Дальше расположены адреса виртуальных функций нужных классов. Заметьте, что адреса расположены в порядке объявления виртуального метода в классе. Если в дочернем классе переопределяется метод, то в его vtable указатель родительского метода заменяется на переопределенный(методы getRole и describe). Если наследник не переопределяет метод, то в таблице остается указатель на родительский метод(getName). В конструкторе Employee происходит такое:

    
        ; Сначала вызывается конструктор Person (устанавливает vptr Person)
call    Person::Person(...) [base object constructor]

; Затем перезаписывается vptr на таблицу Employee
mov     edx, OFFSET FLAT:vtable for Employee+16
mov     rax, QWORD PTR [rbp-24]
mov     QWORD PTR [rax], rdx{}
    

Вызывается конструктор базового класса и сразу же после этого переприсваивается vptr на таблицу класса Employee. Ну а виртуальный вызов выглядит просто как call нужного адреса:

    
        mov     rax, QWORD PTR [rbp-40]    ; Загружаем указатель p
mov     rax, QWORD PTR [rax]       ; Загружаем vptr (указывает на vtable+16)
add     rax, 16                    ; Смещаемся к 4-му слоту (describe)
mov     rdx, QWORD PTR [rax]       ; Загружаем адрес функции describe
mov     rax, QWORD PTR [rbp-40]    ; Загружаем this (указатель p)
mov     rdi, rax                   ; Передаем this как первый параметр
call    rdx                        ; Виртуальный вызов describe{}
    

🧑‍💻Если вы давно смотрите в сторону разработки, но не нашли язык, который даст реальную глубину, масштаб и перспективы — C++ остаётся одним из немногих способов «вкатиться в IT» так, чтобы фундамент работал на вас долгие годы. Мы создали путь от полного нуля до уровня Middle — через проектную работу, живые разборы и практику, которая показывает, что происходит под капотом. Вы научитесь работать с типами, памятью, потоками выполнения и экосистемой C++. Освоите современные стандарты 11–23, корутины, Boost, STL, сетевое взаимодействие и т.д. 🎄Новогодние подарки от OTUS для вас! Приобретайте 3 курса с выгодой до 30%! Покупая 1 курс вы получаете 15%, 2 курса - 25% скидки, 3 курса - максимальную скидку в 30%. Заморозьте цены на обучение! Предложение действует до 26 декабря 2025 года. 💫Старт совсем скоро! Оставьте заявку: https://otus.pw/kT1a/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Наследие Cfront. Полиморфизм #новичкам Часто мы говорим о каких-то вещах в С++ и можем сказать, как они работают под капотом. Но стандарт языка не говорит о том, как компиляторы должны реализовывать те или иные фичи. Он только задает требование. Тем не менее подходы к реализации некоторых фичей повторяются в разных компиляторах. И отчасти это так из-за влияния Cfront. В С++ классический динамический полиморфизм подтипов синтаксически реализуется через виртуальные функции.

    
        class Person {
protected:
    std::string name;
    int age;

public:
    Person(const std::string &n, int a) : name(n), age(a) {}

    virtual void describe() const {
        std::cout << name << " (" << age << " years)";
    }

    virtual ~Person() = default;
};

class Employee : public Person {
    std::string position;

public:
    Employee(const std::string &n, int a, const std::string &pos)
        : Person(n, a), position(pos) {}

    void describe() const override {
        std::cout << name << " (" << age << " years) - " << position;
    }
    ~Employee() override = default;
};{}
    

Мы более подробно разбирали полиморфизм в одном из предыдущих постов. Сейчас мы поговорим, как примерно Cfront преобразовывал этот С++ код в С код. Основные идеи: 1️⃣ Для каждого полиморфного класса формируется статическая таблица виртуальных функций. Это по сути массив указателей на виртуальные "методы" класса, которые Cfront представлял в виде обычных функций. Порядок методов в таблице определялся порядком их объявления в классе. 2️⃣ Нужно каким-то образом связать таблицу для класса с объектом этого класса. Для этого использовалось неявное дополнительное поле класса - указатель на таблицу виртуальных функций или vptr. Вот как Cfront преобразовывал код выше(примерно, детали могут отличаться):

    
        struct Person {
    // pointer to vtable
    void (**vptr)();
    struct string name;
    int age;
};

struct Employee {
    struct Person base;
    struct string position;
};{}
    

В самом первом базовом классе появлялся указатель vptr, который в конструкторе инициализируется правильным адресом нужной таблицы. void (**vptr)() - это тип указателя на указатель на функцию, возвращающую void и не принимающую аргументов. Но погодите, виртуальные методы как минимум принимают один неявный аргумент this, а как максимум могут самые разнообразные сигнатуры иметь. Почему указатель имеет такой тип? Ну а как вы еще засунете в один массив разные функции? Их кастили к одному общему типу void(*)(), только так это было возможно:

    
        void (*Person_vtable[])() = {
    (void(*)())Person_describe_impl,
    (void(*)())Person_dtor
};

void (*Employee_vtable[])() = {
    (void(*)())Employee_describe_impl,
    (void(*)())Employee_dtor
};

void Person_describe_impl(const struct Person* this) {
    printf("%s (%d years)", this->name, this->age);
}

void Person_dtor(struct Person* this) {
    String_dtor(this->name);
}

void Employee_describe_impl(const struct Person* this) {
    // cast to proper type
    const struct Employee* emp = (const struct Employee*)this;
    printf("%s (%d years) - %s", emp->base.name, emp->base.age, emp->position);
}

void Person_dtor(struct Person* this) {
    String_dtor(this->position);
    Person_dtor(this->base);
}
{}
    

Cfront генерировал Сишные реализации методов и клал их в массив, попутно приводя к типу void(*)(). Ну а в месте вызова метода компилятору ничего не мешает сделать каст к нужному типу, так как он знает сигнатуру вызываемого метода:

    
        void print_info(const Person* person) {
    person->describe();
}{}
    

    
        void print_info(const struct Person* person) {
    void (*describe_func)(const struct Person*) = 
        (void (*)(const struct Person*))person->vptr[0];
    describe_func(person);
}{}
    

В те времена С не был стандартизирован и правила преобразования типов были несколько мягче, поэтому такая магия с приведениями работала. В наше время не нужна трансляция С++ в С, но тем не менее концепция таблиц виртуальных функций и указателей на них осталась. Have a legacy. Stay cool #cppcore #goodoldc #compiler

​​Наследие Cfront. Наследование #новичкам Сорри за тавталогию, но мимо этой темы мы не можем пройти(хотя я бы прошел, если бы не @shumilkinad, спасибо ему) В раннем С++ уже были классы и наследование, но в С этого не было. Как же можно транслировать наследование классов в С'шный код? Простая агрегация и никакого мошенничества. Все классы в С++ - это простые С-структуры с отдельным набором функций, принимающих cv-специфицированный указатель на инстанс структуры(это мы выяснили в прошлом посте). Наследники же в начале объекта хранят все поля базового класса. Так давайте просто первым полем наследника сделаем инстанс базовой структуры. Таким образом мы обеспечим вложенность объектов с любым количеством наследований. Вот есть пара родитель-наследник:

    
        class Base {
public:
    int x;
    Base(int a) : x(a) {}
};

class Derived : public Base {
public:
    int y;
    int z;
    Derived(int a, int b) : Base(a), y(b) {
    z = x + y;
  }
};{}
    

Примерно в такой код они транслировались:

    
        struct Base {
    int x;
};

struct Derived {
    struct Base _base;  // embedded base object
    int y;
    int z;
};

void Base_constructor(struct Base* this, int a) {
    this->x = a;
    
    // Constructor body (if presented)
}

void Derived_constructor(struct Derived* this, int a, int b) {
    // Init base object
    Base_constructor(&this->_base, a);
    
    // Init fields of derived object
    this->y = b;
    
    // Constructor body
    this->z = this->_base.x + this->y;
}{}
    

Первым полем структуры Derived - структура Base. Конструкторы же - это отдельные функции. Но в С++ очень важен порядок вызовов конструкторов и деструкторов. Поэтому конструктор самого базового класса только инициализирует свои поля и дальше выполняет инструкции из тела конструктора. При создании же наследников в начале вызывается конструктор базового класса и лишь потом инициализация полей и выполнение тела. Разрушение же объекта выполняется в обратном порядке. Трусы снимаются только после штанов, раньше не получится.

    
        class Base {
public:
    ~Base() { 
        // Destructor Base body
    }
};

class Derived : public Base {
public:
    ~Derived() {
        // Destructor Derived body
    }
}{}
    

Превращается в:

    
        struct Base {
};

struct Derived {
    struct Base _base;

};

void Base_destructor(struct Base* this) {
    // Destructor Base body
}

void Derived_destructor(struct Derived* this) {
    // Destructors execute in reverse order
  
    // Destructor Derived body
    
    Base_destructor(&this->_base);
}{}
    

Новичкам особенно будет полезно понимать, как простой код С++ может быть написан на С, чтобы досканально понимать все абстракции языка и какие действия скрыты от наших глаз. Have a legacy. Stay cool. #cppcore #goodoldc #compiler

🚀Ваш код работает — но мог бы быть быстрее. Проблема не всегда в алгоритме: зачастую узкое место в том, как процессор работает с памятью. Кэш, страницы, выравнивание — всё это влияет на скорость сильнее, чем кажется на первый взгляд. На открытом вебинаре вы разберётесь, что такое cache friendly код и почему грамотная работа с памятью может ускорить вашу программу в разы. На примерах покажем, как устроено взаимодействие с кэшами, где теряется производительность и как это исправить. Вы узнаете, как анализировать поведение памяти и превращать идеи в эффективный, предсказуемый C++-код. ⚡️23 декабря в 20:00 МСК. Открытый урок проходит в преддверии старта курса «C++ Developer. Professional». Регистрация открыта: https://otus.pw/9Fz7/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

​​Наследие Cfront. this #новичкам Cfront был первым компилятором С++. И это оказало большое влияние на то, какие подходы к компиляции C++ используют другие компиляторы. В следующих нескольких постах мы обсудим наследие, которое после себя оставил Cfront. Главное, о чем надо помнить в этой серии - Cfront компилировал С++ код в С. То есть все концепции языка С++, которыми Cfront оперировал, можно было представить в С коде. Некоторые такие представления перетекли в стандарт, некоторые остались на уровне реализации. Сегодня поговорим про такую привычную и базовую вещь, как this или неявный указатель на объект класса в методах. Мы уже написали несколько постов о том, как можно вызывать методы классов с помощью указателя на функцию и объекта класса(или указателя на него). Тык, тык и тык. Но здесь повторим более наглядно чтоли. Вот у Cfront на входе есть С++ код:

    
        class Point {
    int x, y;
public:
    Point(int x, int y) : x(x), y(y) {}
    int get_x() const { return x; }
    int get_y() const { return y; }
    void move(int dx, int dy) { x += dx; y += dy; }
};{}
    

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

    
        struct Point {
    int x;
    int y;
};

void Point_ctor(struct Point* this, int x, int y) {
    this->x = x;
    this->y = y;
}

int Point_get_x(const struct Point* this) {
    return this->x;
}

int Point_get_y(const struct Point* this) {
    return this->y;
}

void Point_move(struct Point* this, int dx, int dy) {
    this->x += dx;
    this->y += dy;
}

void Point_dtor(struct Point* this) {}{}
    

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

    
        void foo() {
  Point p = Point(1, 2);
  p.move(2, 3);
  printf("%d/n", p.get_x());
}{}
    

Этот код превращался в нечто подобное:

    
        void foo() {
  struct Point p;
  Point_ctor(&p, 1, 2);
  Point_move(&p, 2, 3);
  printf("%d/n", Point_get_x(&p));
  Point_dtor(&p);
}{}
    

Заметьте, что в конце любого скоупа, в котором был создан объект компилятором вставлялся вызов деструктора, тем самым обеспечивая идиому RAII. Have a legacy. Stay cool. #cppcore #goodoldc #compiler

​​История компилятора С++ #новичкам С++ начал свой путь в 1979 году, когда Бьерн Страуструп работал над своей диссертацией. Он назвал его "С с классами". Это была довольно примитивная версия С++, были просто добавлены классы, их методы, возможность наследования и другие более минорные фичи. Никакого полиморфизма и шаблонов. Для компиляции этой версии было достаточно написать препроцессор для С компилятора, который бы транслировал инструкции С++ в С-шный код. Этот препроцессор + С-компилятор назывался CPre. Но Бьерн не забросил свою разработку и в 1982 году разработал улучшенную версию С с классами и назвал ее С++. Она уже включала виртуальные функции, перегрузку функций и операторов, ссылки, стандартные функции работы с памятью(new/delete). И CPre уже не справлялся с такими мощными фичами. Да он и изначально был довольно костыльным, потому что не было работы с типами, которой быть и не могло на этапе препроцессинга. Нужно было делать лексический и синтаксический анализ, строить ast дерево программы, чтобы поддерживать типобезопасность. Но хотелось сохранить возможность получения С-шного кода из С++, потому что это способствовало более быстрому распространению языка и его можно было использовать в новых модулях старых проектов. По сути нужен был полноценный компилятор, преобразующий С++ код в С. И им стал Cfront. Вот теперь пошли интересности. Первая простейшая версия языка С++ и компилятора Cfront была написана на "С с классами" и скомпилирована CPre. В дальнейшем мощные фичи в язык добавлялись уже с помощью Сfront, который писался на предыдущей версии С++. CPre не вывозил возросшей сложности. Ну хорошо, Бьерн у себя на домашнем компьютере с определенной архитектурой имеет свежайшую версию Cfront, которая написана на С++. С++ уже не может быть скомпилирован CPre. Как получить компилятор на другой архитектуре? Здесь помогла именно трансляция С++ в С код. При компиляции свежей версии Cfront на выходе на самом деле получается Сшный код. Если этот код чуть причесать и убрать оттуда платформозависимые решения, то можно принести его на компьютер с другой архитектурой, скомпилировать его существующим там С-компилятором и получить готовый Cfront, умеющий компилировать С++. Таким образом распространялись версии компилятора под разные архитектуры. Cfront успешно развивался еще несколько лет, но у него были объективные недостатки: 👉🏿 скорость компиляции в С/С++ и так не славится скорость, так тут еще и двухступенчатая компиляция была 👉🏿 при попытке компиляции ошибки показывались в сгенерированном C-коде, а не в исходном C++, что затрудняло отладку 👉🏿 некоторые возможности C++ было сложно или невозможно реализовать через трансляцию в C. С не всесилен и довольно лаконичен в используемых инструментах. В итоге при попытке добавить в язык исключения Cfront умер... Но благо разработчики прониклись С++ и поняли, что для быстрой и полноценной работы с С++ им нужен полноценный компилятор С++ в асм. Ну а дальше начал разрастаться зоопарк плюсовых компиляторов, некоторые умирали, а некоторые дожили до наших дней. The end. Know that everything has its limits. Stay cool. #tools #compiler