​​Inline виртуальные методы
#опытным

В догонку предыдущего поста. Если можно сделать обычные методы inline, то можно и виртуальные сделать. Что это изменит?

Ну то есть такая иерархия:

class Base {
public:
    virtual int foo() = 0;

protected:
    int x = 2;
};

class Derived : public Base {
public:
    int foo() override {
        x *= 2;
        return x;
    }
};

Получим ли мы какой-то профит от того, что виртуальные методы теперь inline?

Посмотрим на такой код:

void simple() {
    Derived d;
    std::cout << d.foo();
}

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

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

void vec_base(std::vector<std::unique_ptr<Base>>& my_vec) {
    for (auto &p : my_vec) {
        std::cout << p->foo();
    }
}
// другая TU
std::vector<std::unique_ptr<Base>> my_vec;
my_vec.push_back(new Derived());
vec_base(my_vec);

Здесь все понятно. Компилятор реально не знает, какие типы находятся внутри my_vec в функции vec_base. Поэтому все, что он может сделать - это использовать указатель на таблицу виртуальных функций и пусть рантайме уже решается, какой конкретно метод вызвать.

Теперь посмотрим такой код:

void vec_derived(std::vector<std::unique_ptr<Derived>>& my_vec) {
    for (auto &p : my_vec) {
        std::cout << p->foo();
    }
}
// другая TU
std::vector<std::unique_ptr<Derived>> my_vec;
my_vec.push_back(new Derived());
vec_base(my_vec);

И здесь тоже не инлайнится код! Хотя компилятор же видит, что Derived - это единственный наследник.

Но на деле это может быть не так. Единица трансляции с vec_derived может не знать о наследниках уже Derived класса, которые определены отдельно. Компилятор не может достоверно доказать, что у Derived нет наследников, поэтому и не может инлайнить код. Опять vtable и оверхэд.

И здесь в игру вступает ключевое слово final и девиртуализация вызовов, о которой мы говорили тут и тут. Пометив класс как final, мы можем ожидать, что компилятор поймет, что никаких наследников у него нет. Поэтому он может встраивать вызов метода foo для Derived класса в последнем примере.

Вот код на годболте с последними примерами и final девиртуализацией. Немного упростил его, чтобы легче было ассемблер читать.

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

Учитывая, что

1️⃣ виртуальные функции обычно довольно громоздкие(их код будет генерится во всех единицах трансляции, что раздувает бинарь)

2️⃣ операции над непосредственно типами наследниками не распространены

3️⃣ а для девиртуализации нужно танцевать с бубнами

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

Be useful. Stay cool.

#cppcore #OOP #design

​​Zero-Cost Abstractions
#новичкам

Нельзя в промышленных масштабах писать код без абстракций. Вряд ли вы за обозримое время напишите даже эхо-сервер на ассемблере. Даже сам язык программирования - это абстракция. Он позволяет писать программы более-менее на английском языке(или на патриотическом Русском на 1С).

Абстракции упрощают программирование. А что с перфомансом?

Гипотеза такова, что чем выше уровень абстракции, тем выше косты производительности в рантайме.

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

Однако есть и такие абстракции, которые не накладывают оверхэд на рантайм! Они называются Zero-Cost абстракциями.

И это чуть ли не основаная философия программирования на С++. Мы можем играться с уровнями абстракции, писать самый отдаленный от железа код и за все это мы ничего не платим! Компилятор своим мегамозгом анализирует на код, выполняет кучу оптимизаций и на выходе получаем быструю, высокопроизводительную конфетку.

За примерами долго ходить не надо. Можно сложить элементы вектора руками, а можно использовать std::accumulate:

void foo(std::vector<int>& vec) {
    int sum = 0;
    for(int i = 0; i < vec.size(); i++) {
        sum += vec[i];
    }
    std::cout << sum;
}

void bar(std::vector<int>& vec) {
    int sum = std::accumulate(vec.begin(), vec.end(), 0);
    std::cout << sum;
}

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

На каких китах стоит возможность использовать "бесплатные" абстракции в С++?

🐳 Полиморфизм времени компиляции, compile-time вычисления и метапрограммирование. Тут все просто: переносим вычисления с рантайма в компайл тайм с помощью шаблонов, constexpr и меты и радуемся жизни. Параллельно можно еще и кофеек себе заваривать, пока проект билдится.

🐳 Инлайнинг. Одна из основных оптимизаций компилятора. Позволяет встраивать код функции в вызывающий код. С помощью инлайнинга 4 вложенных вызова функций могут превратиться в одну сплошную портянку низкоуровневого кода без дорогостоящих инструкций call.

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

Объединяя эти механизмы, C++ стремится обеспечить абстракции высокого уровня, которые можно использовать для написания выразительного и читаемого кода, сохраняя при этом производительность сравнимую с более низкоуровневым кодом, написанным например на С.

Don't pay for abstraction. Stay cool
#cppcore #compiler

std::allocate_shared
#опытным

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

Причиной является то, что для выделения памяти она использует глобальный new. Поэтому и для освобождения памяти должна использовать глобальный delete. Здесь нет места кастомщине.

Но что, если нам очень нужно по-особенному работать с памятью для объекта? Даже хотя бы просто отслеживать выделение и разрушение без влияния на глобальный delete?

Тут на помощью приходит функция std::allocate_shared. Первым аргументом она принимает аллокатор, который и будет ответственен за выделение и освобождение памяти.

Вот вам простой примерчик с простым STL-совместимым аллокатором, логирующим операции выделения и освобождения памяти:

template <typename T>
class LoggingAllocator {
public:
    using value_type = T;
    using pointer = T *;
    using const_pointer = const T *;
    using reference = T &;
    using const_reference = const T &;
    using size_type = std::size_t;
    using difference_type = std::ptrdiff_t;

    template <typename U>
    struct rebind {
        using other = LoggingAllocator<U>;
    };

    LoggingAllocator() noexcept = default;

    template <typename U>
    LoggingAllocator(const LoggingAllocator<U> &) noexcept {}

    pointer allocate(size_type n) {
        size_type bytes = n * sizeof(T);
        std::cout << "Allocating " << n << " elements ("
                  << bytes << " bytes)\n";
        return static_cast<pointer>(::operator new(bytes));
    }

    void deallocate(pointer p, size_type n) noexcept {
        size_type bytes = n * sizeof(T);
        std::cout << "Deallocating " << n << " elements ("
                  << bytes << " bytes)\n";
        ::operator delete(p);
    }
};

template <typename T, typename U>
bool operator==(const LoggingAllocator<T> &,
                const LoggingAllocator<U> &) noexcept { return true; }

template <typename T, typename U>
bool operator!=(const LoggingAllocator<T> &,
                const LoggingAllocator<U> &) noexcept { return false; }

class MyClass {
public:
    MyClass(int value) : value(value) {
        std::cout << "Constructed with " << value << "\n";
    }
    ~MyClass() {
        std::cout << "Destroyed with  " << value << "\n";
    }
    void print() const {
        std::cout << "Value: " << value << "\n";
    }

private:
    int value;
};

int main() {
    LoggingAllocator<MyClass> alloc;
    auto ptr = std::allocate_shared<MyClass>(alloc, 42);
    ptr->print();
    return 0;
}
// OUTPUT:
// Allocating 1 elements (24 bytes)
// Constructed with 42
// Value: 42
// Destroyed with  42
// Deallocating 1 elements (24 bytes)

Стандартом на аллокаторы накладываются определенные требования: нужно определить нужные алиасы, методы allocate и deallocate, структуру rebind и соответствующий конструктор копирования и операторы сравнения. Полный список требований можно прочитать тут.

По консольному выводу видно, что аллокатор выделяет немного больше памяти, чем должен занимать объект. Это сделано в том числе для того, чтобы хранить в выделенном куске еще и контрольный блок std::shared_ptr. Так что касаемо особенностей аллокации и деаллокации тут похожая ситуация с std::make_shared.

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

Customize your solutions. Stay cool.

#cppcore #STL #memory

​​Оператор, бороздящий просторы вселенной
#новичкам

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

struct Time {
  int hours;
  int minutes;
  int seconds;

  bool operator<(const Time& other) {
    return std::tie(hours, minutes, seconds) < std::tie(other.hours, other.minutes, other.seconds);
  }
};

Однако иногда структуры требуется сравнивать и с помощью других операторов: >, ==, !=, >=, <=. В итоге полноценный набор операторов сравнения для Time выглядит так:

struct Time {
    int hours;
    int minutes;
    int seconds;

    bool operator<(const Time& other) const noexcept {
        return std::tie(hours, minutes, seconds) < std::tie(other.hours, other.minutes, other.seconds);
    }

    bool operator==(const Time& other) const noexcept {
        return std::tie(hours, minutes, seconds) == std::tie(other.hours, other.minutes, other.seconds);
    }

    bool operator<=(const Time& other) const noexcept { return !(other < *this); }
    bool operator>(const Time& other) const noexcept { return other < *this; }
    bool operator>=(const Time& other) const noexcept { return !(*this < other); }
    bool operator!=(const Time& other) const noexcept { return !(*this == other); }
};

Попахивает зловонным бойлерплейтом.

Недавно увидел мем, где девочка 8-ми лет, которая изучает питон, спрашивает отца: "папа, а если компьютер знает, что здесь пропущено двоеточие, почему он сам не может его поставить?". И батя такой: "Я не знаю, дочка, я не знаю ...".

Здесь вот похожая ситуация. Компилятор же умеет сравнивать набор чисел в лексикографическом порядке. Какого хрена он не может сделать это за нас?

Начиная с С++20 может!

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

struct Time {
    int hours;
    int minutes;
    int seconds;

    bool operator<(const Time& other) const = default;
    bool operator==(const Time& other) const = default;
    bool operator<=(const Time& other) const = default;
    bool operator>(const Time& other) const = default;
    bool operator>=(const Time& other) const = default;
    bool operator!=(const Time& other) const = default;
};

В отличие от специальных методов класса, компилятор не сгенерирует за нас эти операторы, если мы явно не попросим. Получается, что мы решили только полпроблемы и нам все равно нужно писать 6 скучных засоряющих код строчек. Хотелось бы один раз сказать, что нам нужны сразу все операторы.

Тут же нам на помощью приходит еще одна фича С++20 - трехсторонний оператор сравнения или spaceship operator. Теперь код выглядит так:

struct Time {
    int hours;
    int minutes;
    int seconds;

    // Один оператор вместо шести!
    auto operator<=>(const Time& other) const = default;
};

Spaceship потому что похож на космический корабль, имхо прям имперский истребитель из далекой-далекой.

Один раз определив этот оператор можно сравнивать объекты какими угодно операторами и это будет работать. Подробнее про применение будет в следующем посте.

Conquer your space. Stay cool.

#cppcore #cpp20

Spaceship оператор. Детали 1
#новичкам

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

Ну для начала: наличие определенного spaceship оператора гарантирует вам наличие всех 6 операций сравнения:

struct Time {
    int hours;
    int minutes;
    int seconds;

    // Spaceship operator (генерирует все 6 операторов сравнения)
    auto operator<=>(const Time& other) const = default;
};

Time t1{10, 30, 15};  // 10:30:15
Time t2{9, 45, 30};   // 09:45:30
Time t3{10, 30, 15};  // 10:30:15

assert(t1 > t2);    // 10:30:15 > 09:45:30
assert(!(t1 < t2)); // 10:30:15 не < 09:45:30
assert(t1 == t3);   // 10:30:15 == 10:30:15
assert(t1 != t2);   // 10:30:15 != 09:45:30
assert(t1 <= t3);   // 10:30:15 <= 10:30:15
assert(t1 >= t2);   // 10:30:15 >= 09:45:30

Это уже прекрасно, но это еще не все!

Обратите внимание на сигнатуру spaceship operator. Зачем там нужен auto?

Вот теперь объясненяем, почему это называется оператор трехстороннего сравнения.

Он возвращает объект, который содержит информацию о результате сравнения:

Time t1{10, 30, 15};  // 10:30:15
Time t2{9, 45, 30};   // 09:45:30

// Можно использовать и сам spaceship operator напрямую
auto cmp = t1 <=> t2;
if (cmp > 0) {
  std::cout << "t1 is later than t2\n";
} else if (cmp < 0) {
  std::cout << "t1 is earlier than t2\n";
} else {
  std::cout << "t1 is the same as t2\n";
}
// OUTPUT:
// t1 is later than t2

Если результат сравнения >0, то первый операнд больше второго. И так далее по аналогии.

Тип возвращаемого значения у оператора один из этих трех:
- std::strong_ordering
- std::weak_ordering
- std::partial_ordering

Что они значат - тема отдельного разговора, но каждый из них может находится в одном из 3-х состояний: less, greater, equal. Это можно использовать, например, для проверки возвращаемых значений системных вызовов:

constexpr int strong_ordering_to_int(const std::strong_ordering& o)
{
    if (o == std::strong_ordering::less)    return -1;
    if (o == std::strong_ordering::greater) return 1;
    return 0;
}

char buffer[256];
ssize_t bytes_read = read(fd, buffer, sizeof(buffer));

// Сравниваем результат read() с нулём через <=>
switch (strong_ordering_to_int(bytes_read <=> 0)) {
  case 1:
    std::cout << "Read " << bytes_read << " bytes: " 
          << std::string(buffer, bytes_read) << "\n";
    break;
  case 0:
    std::cout << "End of file reached (0 bytes read)\n";
    break;
  case -1:
    perror("read failed");
    return 1;
}

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

Be universal. Stay cool.

#cppcore #cpp20

struct String {
  std::string str;
  bool operator==(const String &other) const {
    std::cout << "Using optimized ==\n";
    if (str.size() != other.str.size())
      return false;
    return str == other.str;
  }
  auto operator<=>(const String &other) const {
    std::cout << "Using <=>\n";
    return str <=> other.str; // Сравнивает символы до первого различия
  }

};

struct SString {
  String str;
  auto operator<=>(const SString &other) const = default;
};

a == b; // Вызовет operator==
a != b; // Вызовет operator!=, который определен через ==
a < b; // Вызовет spaceship
// OUTPUT:
// Using optimized ==
// Using optimized ==
// Using <=>

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

Don't go to a rabbit hole. Stay cool.

#cppcore

Unity build
#опытным

Чем знаменит С++? Конечно же своим гигантским временем сборки программ. Пока билдится плюсовый билд, где-то в Китае строится новый небоскреб.

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

Компиляция всяких шаблонов сама по себе долгая, особенно, если использовать какие-нибудь рэнджи или std::format. Но помните, что конкретная инстанциация шаблона будет компилироваться независимо в каждой единице трансляции. В одном цппшнике использовали std::vector<int> - компилируем эту инстанциацию. В другом написали std::vector<int> - заново скомпилировали эту инстанциацию. То есть большая проблема в компиляции одного и того же кучу раз.

Но помимо компиляции вообще-то есть линковка. И чем больше единиц трансляции, библиотек и все прочего, тем больше времени нужно линковщику на соединение все этого добра в одно целое.

Обе эти проблемы можно решить одним махом - просто берем и подключаем все цппшники в один большооой и главный цппшник. И компилируем только его. Такой себе один большой main. Такая техника называется Unity build (aka jumbo build или blob build)

Условно. Есть у вас 2 цппшника и один хэдэр:

// header.hpp
#pragma once
void foo();

// source1.cpp
#include "header.hpp"
void foo() {
  std::cout << "You are the best!" << std::endl;
}

// source2.cpp
#include "header.hpp"
int main() {
  foo();
}

Вы все цппшники подключаете в один файл unity_build.cpp:

#include "source1.cpp"
#include "source2.cpp"

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

Или нет?

У этой техники есть ряд недостатков:

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

Потенциальные конфликты имен. Конфликты статических переменных и функций с одинаковыми именами в разных файлах, конфликты символов из анонимных namespace'ов, неожиданное разрешение перегрузки функций - все это может подпортить вам жизнь.

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

У кого был опыт с unity билдами, отпишитесь по вашим впечатлениям.

Solve the problem. Stay cool.

#cppcore #compiler #tools

​​Ответ
#новичкам

Многие из вас подумали, что будет ошибка компиляции. В целом, логичная цепочка мыслей: ну как же можно мувнуть данные из константной ссылки? Она же неизменяема.

Но она все же неверная. Правильный ответ: на консоль выведется "copy ctor".

Копия? Мы же муваем!

Сейчас разберемся. Но для начало вспомним сам пример:

#include <iostream>

struct Test {
    Test() = default;
    Test(const Test &other) {
        std::cout << "copy ctor" << std::endl;
    }
    Test(Test &&other) {
        std::cout << "move ctor" << std::endl;
    }
    Test &operator=(const Test &other) = default;
    Test &operator=(Test &&other) = default;
    ~Test() = default;
};

int main() {
    Test test;
    const Test &ref = test;
    (void)std::move(ref);
    auto emigma = std::move(ref);
}

На самом деле проблема в нейминге. Все вопросы к комитету. Это они имена всему плюсовому раздают.

std::move ничего не мувает. Она делает всего лишь static_cast. Но не просто каст к правой ссылке, это не совсем корректно. Посмотрим на реализацию std::move:

template <class T>  
constexpr typename std::remove_reference<T>::type&& move(T&& t) noexcept {  
  return static_cast<typename std::remove_reference<T>::type&&>(t);  
}

Обратите внимание, что от типа отрезается любая ссылочность и только затем добавляется правоссылочность. Но константность-то никуда не уходит. По сути результирующий тип выражения std::move({константная левая ссылка}) это константная правая ссылка.

Чтобы это проверить, перейдем на cppinsights:

Test test;
const Test &ref = test;
using ExprType = decltype(std::move(ref));

// под капотом ExprType вот чему равен

using ExprType = const Test &&;

Так как мы просто кастуем к валидному типу, мув успешно отрабатывает, но строчка (void)std::move(ref); не дает в консоли никакого вывода, потому что никаких новых объектов мы не создаем.

Теперь про копирование. Вспомним правила приведения типов. const T&& может приводится только к const T&. То есть единственный конструктор, который может вызваться - это копирующий конструктор.

Интересная ситуация, конечно, что "перемещение" может приводить к копированию в плюсах. Но имеем, что имеем. Терпим и продолжаем грызть гранит С++.

Give a proper name. Stay cool.

#cppcore #template

​​Гарантии безопасности исключений
#новичкам

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

Даже не зная, что вы работаете с исключениями - вы уже работаете с ними. Даже обычный, казалось бы, безобидный new может кинуть std::bad_alloc. И это core языка. Стандартная библиотека пронизана исключениями.

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

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

Итак, существует 3 гарантии безопасности исключений:

Базовая гарантия. Формулировка разнится, но более общая звучит так: "после возникновения исключения и его обработки программа должна остаться в согласованном состоянии". Теперь на рабоче-крестьянском: не должно быть утечек ресурсов и должны сохраняться все инварианты классов. С утечками, думаю, все понятно. Инвариант - некое логически согласованное состояние системы. Если класс владеет массивом и содержит поле для его размера, то инвариантом этого класса будет совпадение реального размера массива со значением поля-размера. Для класса "легковая машина" инвариантом будет количество колес - 4. Обычная машина без одного или нескольких колес просто не едет. И для того, чтобы машина корректно работала, количество колес должно быть одинаково - 4. Или например, нельзя, чтобы дата создания чего-то была больше текущего дня, ну никак. Вот такие штуки должны сохраняться.

Строгая гарантия. Если при выполнении операции возникает исключение, операция не должна оказать на систему никакого влияния. То есть пан или пропал. Либо вся операция выполняется успешно и ее результат применяется, либо система откатывается в состояние до выполнения операции. Это свойство программы называется транзакционностью.

Гарантия отсутствия исключений. Ни при каких обстоятельствах не будет брошено исключение. Легко сказать, но тяжело сделать. С++ и его стандартная библиотека разрабатывались с учетом использования исключений. И это накладывает свои ограничения на отсутствие исключений. Мы все-таки не на Go пишем.

Ну и есть еще одна гарантия - отсутствие каких-либо гарантий. Мама - анархия, во всей красе.

Тема важная, будем потихоньку ее разбирать с примерами по каждой гарантии.

Be a guarantor. Stay cool.

#cppcore

​​Базовая гарантия исключений
#новичкам

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

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

class IntArray {
    int *array;
    std::size_t nElems;

public:
    // ...

    ~IntArray() { delete[] array; }

    IntArray(const IntArray &that);  // nontrivial copy constructor
    IntArray &operator=(const IntArray &rhs) {
        if (this != &rhs) {
            delete[] array;
            array = nullptr;
            nElems = rhs.nElems;
            if (nElems) {
                array = new int[nElems];
                std::memcpy(array, rhs.array, nElems * sizeof(*array));
            }
        }
        return *this;
    }

    // ...
};

Внутренний инвариант класса IntArray - член array является валидным (возможно, нулевым) указателем, а член nElems хранит количество элементов в массиве. В операторе присваивания освобождается память текущего array'я и присваивается значение счётчику элементов nElems до выделения нового блока памяти для копии. В результате, если из new вылетит исключение, то array будет нулевым, а размер массива нет. Это нарушение инварианта и таким объектом просто небезопасно пользоваться. Метод size потенциально вернет ненулевой размер, а закономерное использование следом оператора[] приведет к неопределенному поведению.

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

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

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

И это главное. Вся магия с раскруткой стека и вызовом деструктором локальных объектов работает только если деструкторы вызываются безопасно. А для этого объект должен быть в валидном, но необязательно определенном, состоянии. То есть вы в принципе не можете восстановить работоспособность приложения, если ваши инструменты не предоставляют хотя бы базовую гарантию.

Здесь кстати можно провести параллель с мувнутыми объектами: ими тоже особо не попользуешься и по хорошему их надо просто удалить.

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

auto db = std::make_shared<DBConnection>(credentials);
try {
  auto result = db->Execute("UPDATE ...");
  process(result);
} catch (std::exception& ex) {
  std::cout << "We can cannot rely on table state and must retry with that in mind" << std::endl;
  // retry
}

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

Provide guarantees. Stay cool.

#cppcore

​​Строгая гарантия исключений
#новичкам

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

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

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

Давайте перепишем оператор присваивания класс IntArray из предыдущего поста так, чтобы он предоставлял строгую гарантию:

class IntArray {
    int *array;
    std::size_t nElems;

public:
    // ...

    ~IntArray() { delete[] array; }

    IntArray(const IntArray &that);  // nontrivial copy constructor

    IntArray &operator=(const IntArray &rhs) {
        int *tmp = nullptr;
        if (rhs.nElems) {
            tmp = new int[rhs.nElems];
            std::memcpy(tmp, rhs.array, rhs.nElems * sizeof(*array));
        }
        delete[] array;
        array = tmp;
        nElems = rhs.nElems;
        return *this;
    }

    // ...
};

В этот раз мы ничего не изменяем в самом объекте до тех пор, пока не выделим новый буфер и не скопируем туда элементы rhs. И только после этого выполняем обновление самого объекта с помощью небросающих инструкций.

Хрестоматийный пример из стандартной библиотеки - вектор с его методом push_back. Если у типа есть небросающий перемещающий конструктор, то метод предоставляет строгую гарантию. Вот примерно как это работает:

template <typename T>
class vector {
private:
    T *data = nullptr;
    size_t size = 0;
    size_t capacity = 0;

    void reallocate(size_t new_capacity) {
        // allocate memory
        T *new_data =
            static_cast<T *>(::operator new(new_capacity * sizeof(T)));
        size_t new_size = 0;

        try {
            // Move or copy elements 
            for (size_t i = 0; i < size; ++i) {
                new (new_data + new_size) T(std::move_if_noexcept(data[i]));
                ++new_size;
            }
        } catch (...) {
            // Rollback in case of exception
            for (size_t i = 0; i < new_size; ++i) {
                new_data[i].~T();
            }
            ::operator delete(new_data);
            throw;
        }

        // cleanup
        // ...
    }

public:
    void push_back(const T &value) {
        if (size >= capacity) {
            size_t new_capacity = capacity == 0 ? 1 : capacity * 2;

            // save for rollback
            T *old_data = data;
            size_t old_size = size;
            size_t old_capacity = capacity;

            try {
                reallocate(new_capacity);
            } catch (...) {
                // restore
                data = old_data;
                size = old_size;
                capacity = old_capacity;
                throw;
            }
        }

        // actually insert element
        // ...
    }

};

в хэлпере reallocate используется std::move_if_noexcept, который условно кастит в rvalue ссылке, если мув конструктор noexcept. И только в этом случае можно предоставить строгую гарантию: если вы уже повредили один из исходных объектов, его уже никак не восстановить. А безопасное перемещение элементов гарантирует готовый к использованию новый расширенный буфер.

Be strong. Stay cool.

#cppcore

​​Гарантия отсутствия исключений
#новичкам

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

В сам язык С++(new, dynamic_cast), и в его стандартную библиотеку в базе встроены исключения. Поэтому писать код без исключений в использованием стандартных инструментов практически невозможно. Вы конечно можете использовать nothrow new и написать свой вариант стандартной библиотеки и других сторонних решений. И кто-то наверняка так делал. Но в этом случае разработка как минимум затянется, а как максимум вы бросите это гиблое дело.

Поэтому повсеместно предоставлять nothow гарантии с использованием стандартных инструментов не всегда реалистично.

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

Но для начала проясним термины.

Под гарантией отсутствия исключений подразумевается обычно 2 понятия: nothrow и nofail.

nothrow подразумевает отсутствие исключений, но не отсутствие ошибок. Говорится, что ошибки репортятся другими средствами(в основном через глобальное состояние, потому что деструктор ничего не возвращает) или полностью скрываются и игнорируются.

Примером сущностей с nothrow гарантией является деструкторы. С С++11 они по-умолчанию помечены noexcept. В основном это сделано для того, чтобы при раскрутке стека не получить double exception.
Но деструкторы могу фейлиться. Просто никаких средств, кроме глобальных переменных для репорта ошибок невозможно использовать. Они ведь ничего не возвращают, а исполняются скрытно от нас(если вы используете RAII конечно).

nofail же подразумевает полное отсутствие ошибок. nofail гарантия ожидается от std::swap, мув-конструкторов классов и других функций с помощью которых достигается строгая гарантия исключений.

Например в swap-идиоме std::swap и мув-конструкторы используются для определения небросающего оператора присваивания.

nofail гарантиями также должны обладать функторы-коллбэки модифицирующих алгоритмов. std::sort не предоставляет никаких гарантий на состояние системы, если компаратор бросит эксепшн.

В языке в целом эти гарантии обеспечиваются ключевым словом noexcept. При появлении этой нотации компилятор понимает, что для этой функций не нужно генерировать дополнительный код, необходимый для обработки исключений. Но у этого есть своя цена: если из noexcept функции вылетит исключение, то сразу же без разговоров вызовется std::terminate.

Provide guarantees. Stay cool.

#cppcore #cpp11

​​WAT
#опытным

Спасибо, @Ivaneo, за любезно предоставленный примерчик в рамках рубрики #ЧЗХ.

"Век живи - век учись" - сказал Луций Сенека.

"Век живи - век учи С++" - реалии нашей жизни.

Просто посмотрите на следующий код:

struct Foo
{
  void Bar();
};

void Foo::Foo::Foo::Foo::Foo::Foo::Foo::Foo::Foo::Foo::Foo::Foo::Bar()
{
    printf("Foofoo!");
}

int main()
{
    Foo f;
    f.Bar();
    return 0;
}

И он компилируется.

WAT?

Это называется injected class name. Имя класса доступно из скоупа этого же класса. Так сделано для того, чтобы поиск имени X внутри класса X всегда разрешался именно в этот класс.

Такое поведение может быть полезно в таком сценарии:

void X() { }
class X {
public:
  static X Сreate() { return X(); }
};

injected class name гарантирует, что из метода Сreate будет возвращен именно инстанс класса Х, а не результат вызова функции Х.

Это также полезно внутри шаблонов классов, где имя класса можно использовать без списка аргументов шаблона, например, используя просто Foo вместо полного идентификатора шаблона Foo<blah, blah, blah>.

Ну и побочным эффектом такого поведения является возможность написания длиннющей цепочки из имен класса.

Так что это не у вас в глазах двоится, это плюсы такие шебутные)

Find yourself within. Stay cool.

#cppcore

​​data race
#новичкам

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

Начнем с data race. Это по сути единственная категория, которая четко определена в стандарте С++.

Скажем, что два обращения к памяти конфликтуют, если:

- они обращаются к одной и той же ячейке памяти.
- по крайней мере одно из обращений - запись.

Так вот гонкой данных называется 2 конфликтующих обращения к неатомарной переменной, между которыми не возникло отношение порядка "Произошло-Раньше".

Если не вдаваться в семантику отношений порядков, то отсутствие синхронизации с помощью примитивов(мьютексов и атомиков) при доступе к неатомикам карается гонкой данных и неопределененным поведением.

Простой пример:

int a = 0;

void thread_1() {
  for (int i = 0; i < 10000; ++i) {
    ++a;
  }
}

void thread_2() {
  for (int i = 0; i < 10000; ++i) {
    ++a;
  }
}

std::jthread thr1{thread_1};
std::jthread thr1{thread_2};
std::cout << a << std::endl;

В двух потоках пытаемся инкрементировать a. Проблема в том, что при выводе на консоль a не будет равна 20000, а скорее всего чуть меньшему числу. Инкремент инта - это неатомарная операция над неатомиком, поэтому 2 потока за счет отсутствия синхронизации кэшей будут читать и записывать неактуальные данные.

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

Have an order. Stay cool.

#cppcore #concurrency

​​Самая надежная гарантия отсутствия исключений
#опытным

Исключения не любят не только и не столько потому, что они нарушают стандартный поток исполнения программы, могут привести к некорректному поведению системы и приходится везде писать try-catch блоки. Исключения - это не zero-cost абстракция. throw требуют динамические аллокации, catch - RTTI, а в машинном коде компилятор обязан генерировать инструкции на случай вылета исключений. Плюс обработка исключений сама по себе медленная.

Поэтому некоторые и стараются минимизировать использование исключений и максимально использовать noexcept код.

Но можно решить проблему накорню. Так сказать отрезать ее корешок под самый корешок.

Есть такой флаг компиляции -fno-exceptions. Он запрещает использование исключений в программе. Но что значит запрет на использование исключений?

👉🏿 Ошибка компиляции при выбросе исключения. А я говорил, что под корень рубим. Вы просто не соберете программу, которая кидает исключения.

int main() {
  throw 1; // even this doesn't compile
}

👉🏿 Ошибка компиляции при попытке обработать исключение. Ну а че, если вы живете в мире без исключений, зачем вам их обрабатывать?

int main() {
// even this doesn't compile
try {
} catch(...) {
}

}

👉🏿 Можно конечно сколько угодно жить в розовом мире без исключений, но рано или поздно придется использовать чужой код. Что будет, если он выкинет исключение?

std::map<int, int> map;
std::cout << map.at(1) << std::endl;

Моментальное завершение работы. Оно как бы и понятно. Метод мапы at() кидает std::out_of_range исключение, если ключа нет в мапе. Обрабатывать исключение нельзя, поэтому чего вола доить, сразу терминируемся. И никакой вам раскрутки стека и graceful shutdown. Просто ложимся и умираем, скрестив ручки.

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

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

Как тогда код писать? А об этом через пару постов.

Handle errors. Stay cool.

#cppcore #compiler

​​Что не так с модулями?
#опытным

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

Модули - это новая фундаментальная единица организации кода, которая должна дополнить и в идеале(в мечтах комитета) заменить старую концепцию заголовочных файлов.

Если по простому, то модуль - это такой бинарный черный ящик, у которого четко определен интерфейс, который он экспортирует наружу.

Экспортируемые сущности явно помечаются в коде модуля. Затем модуль компилируется и из бинарного его представления можно дергать только эти экспортируемые сущности.

Короткий пример:

// math.cppm - файл модуля
export module math;  // Объявление модуля

import <vector>;     // Импорт, а не включение

// Макросы НЕ экспортируются!
#define PI 3.14159

// Явный экспорт - только то, что нужно
export double calculate_circle_area(double radius);

// Внутренние функции скрыты
void internal_helper();

и его использование:

// main.cpp - обычный С++ файл
import math;    // Импорт интерфейса, не всего кода

// Используем экспортированную функцию
double area = calculate_circle_area(10);

// internal_helper();  // ERROR! функция скрыта
// double x = PI;      // ERROR! макросы не экспортируются

Модули призваны решать следующие проблемы:

✅ Одни и те же заголовки могут сотни раз обрабатываться компилятором при компиляции программ из многих единиц трансляции. Модули же компилируются один раз, в них кэшируется информация, необходимая для нормальной компиляции cpp файлов и потом эта информация просто используется при компиляции. Никакой повторной работы!
Это значит, что время компиляции должно заметно уменьшиться.

✅ В хэдэрах зачастую нужно оставлять некоторые детали реализации, которые не нужны пользователю, но нужны для корректной компиляции. Модули же явно экспортируют только нужный интерфейс.

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

На словах - прекрасные плюсы будущего. Но на словах мы все Львы Толстые, а на деле...

А на деле это все до сих пор работает довольно костыльно. До 23, а скорее 24 года использовать модули было совсем никак нельзя. Сейчас все немного лучше, но реализации все еще пропитаны проблемами. А проекты не спешат переходить на модули. Но почему?

😡 Модули - довольно сложная штука в реализации. Не будем вдаваться в нюансы, но компилятор должен сильно измененить свое поведение и преобрести свойства системы сборки, чтобы нормально компилировать модули. А делать они этого не хотят. Плюс многие компиляторы опенсорсные и не так-то просто в опенсорсе реализовывать такие масштабные идеи. На винде с этим попроще, потому что во главе всего Microsoft и они завезли модули раньше всех.

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

😡 Из-за этого в том числе хромает тулинг. Дело в том, что модуль - это бинарный файл и программист просто так не может, например, посмотреть сигнатуру метода в каком-то файле. Это большая проблема, которую должны решить редакторы и анализаторы кода. Но отсутствие стандартизации формата мешает интеграции модулей в них.

😡 Очень много усилий нужно потратить на переработку архитектуры и кода существующих проектов, чтобы перевести их на модули.

😡 Ускорение компиляции может неоправдать затрат. В среднем ускорение составляет порядка 30%. И это просто не стоит усилий.

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

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

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

Use new features. Stay cool.

#cppcore #compiler #tools

​​pointer to data member
#опытным

В этом посте мы рассказывали о том, что с помощью ranges и и параметра проекции можно кастомизировать алгоритмы с соответствии с определенным полем класса. Например, чтобы найти в коллекции элемент с максимальным определенным полем, то можно сделать так:

struct Payment {
    double amount;
    std::string category;
};
auto max = *std::ranges::max_element(payments, {}, &Payment::amount);

max в этом случае будет транзакцией с максимальным размером платежа.

В последней строчке используется &Payment::amount - указатель на поле amount в классе Payment. Но если это параметр функции, то это значение какого-то типа. Но какой тип у этого указателя?

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

Явный тип указателя на поле класса используется так:

struct Payment {
    double amount;
    std::string category;
};

double Payment::*ptr = &Payment::amount; // Here!

Payment payment{3.14, "Groceries"};
std::cout << payment.*ptr << std::endl;
// OUTPUT:
// 3.14

double Payment::*       ptr         = &Payment::amount;
// тип указателя    имя указателя    инициализатор

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

Мы обязательно должны указать, на какой тип полей этот указатель может указывать. Таким образом указатель ptr может указывать на любое поле класса Payment, имеющее тип double. То есть:

struct Type {
    int a;
    int b;
    float c;
};

int Type::*p = nullptr;

p = &Type::a; // OK, a is int
p = &Type::b; // OK, b is int

p = &Type::c;  // ERROR! c is float

Указателю на интовое поле нельзя присвоить указатель на флотовое. И наоборот, указатель p работает с любыми полями типа int.

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

// Takes pointer to any data member for any type
template<typename T, typename FieldType>
void print_field(const T& obj, FieldType T::*field) {
    std::cout << obj.*field << std::endl;
}

Payment payment{3.14, "Groceries"};
Type t(42, 69, 3.14);

print_field(payment, &Payment::amount);
print_field(payment, &Payment::category);

print_field(t, &Type::a);
print_field(t, &Type::b);
print_field(t, &Type::c);
// OUTPUT
// 3.14
// Groceries
// 42
// 69
// 3.14

print_field может печатать значение любого поля любого класса по его указателю. Обратите внимание на шаблонную сигнатуру.

Walk through the nooks and crannies. Stay cool.

#cppcore #memory

​​WAT
#опытным

Спасибо, @Ivaneo, за любезно предоставленный примерчик в рамках рубрики #ЧЗХ.

Всегда ли nullptr указатель равен нулю?

Казалось бы в названии дан ответ:

int * p = nullptr;
std::cout << std::boolalpha << (p == nullptr) << "\n";
std::cout << std::hex << std::bit_cast<std::uintptr_t>(p) << "\n";
// OUTPUT
// true
// 0

Но в общем случае это неправда! Смотрим на пример:

struct A {
    int i;
};

int main() {
    int A::* p = 0;

    std::cout << std::boolalpha << (p == nullptr) << "\n";
    std::cout << std::hex << std::bit_cast<std::uintptr_t>(p) << "\n";
    std::cout << std::boolalpha << (std::bit_cast<std::uintptr_t>(p) == 0xffffffffffffffff) << "\n";
}
// OUTPUT:
// true
// ffffffffffffffff
// true

nullptr указатель равен совсем не нулю, как декларировалось в начале main.

WAT? Что за фокусы с пропажей нуля?

Во вчерашнем посте мы рассказывали об особом типе указателя - pointer to data member. Этот указатель, которым и является p из примера, по сути хранит информацию о том, как в объекте найти нужное поле класса.

И в большинстве случаев эта информация представляет собой просто смещение поля относительно начала объекта в байтах.

Однако нулевое смещение используется для локации самого первого поля класса. Поэтому в байтовом представлении неинициализированный указатель не может быть нулем.

Вместо этого обычно используется число -1, которое в байтовом представлении как раз выглядит как все единички:

std::cout << std::hex << static_cast<long long int>(-1) << "\n";
// OUTPUT:
// ffffffffffffffff

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

struct Type {
    double a;
    char b;
    float c;
    long long d;
    short e;
    unsigned f;
};

std::cout << std::dec << std::bit_cast<std::uintptr_t>(&Type::a) << "\n";
std::cout << std::dec << std::bit_cast<std::uintptr_t>(&Type::b) << "\n";
std::cout << std::dec << std::bit_cast<std::uintptr_t>(&Type::c) << "\n";
std::cout << std::dec << std::bit_cast<std::uintptr_t>(&Type::d) << "\n";
std::cout << std::dec << std::bit_cast<std::uintptr_t>(&Type::e) << "\n";
std::cout << std::dec << std::bit_cast<std::uintptr_t>(&Type::f) << "\n";

// OUTPUT:
// 0
// 8
// 12
// 16
// 24
// 28

Опять же, интересный уголок плюсов.

Walk through the nooks and crannies. Stay cool.

#cppcore #memory

​​Сколько весит объект полиморфного класса?
#новичкам

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

У нас уже был пост про размер объекта пустого класса.

А что если это будет класс с виртуальными методами? Сколько тогда будет весить этот класс?

struct SomeClass {
  
  virtual ~SomeClass() = default;
  
  virtual void Process() {
    std::cout << "Process" << std::endl;
  }
};

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

Таблица одна на все объекты заданного класса. И им каким-то образом нужно получить доступ к этой таблице.

Учитывайте, что нельзя захардкодить эту информацию по статическому типу объекта(например SomeClass& или SomeClass*), потому что под его личиной может скрываться наследник.

Значит надо ее класть в каждый объект. И самое простое - положить в них указатель на свою таблицу виртуальных функций. Так и делают на самом деле. Этот указатель называют vptr.

Соответственно размер класса зависит от битности системы. Для 64-бит указатель имеет размер 8 байт(64 бита) поэтому и размер класса SomeClass будет 8 байт.

std::cout << sizeof(SomeClass) << std::endl;
// OUTPUT
// 8

Пустые наследники SomeClass кстати тоже будут иметь размер 8 из-за того, что им нужно лишь другое значения указателя.

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

Be lightweight. Stay cool.

#cppcore #interview

​​enum class
#новичкам

Перечисления пришли в С++ еще из С и отлично живут. Однако плюсовикам не очень с ними комфортно работать с силу наследования слабой типизации и неявных преобразований enum'ов в числовые типы и в другие enum'ы

В С++11 появился новый тип перечислений - scoped enumerations. Или ограниченные областью видимости перечисления. Определяются они так:

enum class Enumeration {CATEGORY1, CATEGORY2, CATEGORY3};

Он решает две большие проблемы обычных перечислений:

👉🏿 Обычные перечисления неявно преобразуются в int и обратно, что вызывает ошибки, когда не предполагается использование перечисления в качестве целого числа.

Можно например попробовать получить следующее значение перечисления, просто прибавив единицу:

cpp
enum Color { RED, GREEN, BLUE };

Color c = RED;
Color next = c + 1;  // Implicit conversion to int and visa versa!

Что значит прибавить красному цвету единицу - решительно непонятно.

Неявные преобразования enum class'ов же запрещено:

enum class Color { RED, GREEN, BLUE };

Color c = Color::RED;
Color next = c + 1; // ERROR!

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

Color c = Color::RED;
Color next = static_cast<Color>(static_cast<int>(c) + 1);

👉🏿 Обычные перечисления экспортируют свои перечислители в окружающую область видимости, вызывая конфликты имён с другими сущностями в этой окружающей области:

enum Color { RED, GREEN, BLUE };
 
enum TrafficLight { RED, YELLOW, GREEN }; // ERROR!

void graphics_library() {
    Color c = RED;
}

У scoped enum'ов такой проблемы нет. Имена перечислителей находятся в скоупе своего перечисления:

enum class Color1 { RED, GREEN, BLUE };
enum class Color2 { RED, GREEN, BLUE };

void graphics_library() {
    Color1 c1 = Color1::RED;
    Color2 c2 = Color2::RED;
}

И все прекрасно компилируется.

С учетом неймспейсов и любви к явным кастам в коммьюнити, в С++ лучше использовать enum class'ы вместо обычных перечислений.

Protect your scope. Stay cool.

#cppcore #cpp11