Грокаем C++

Виртуальные функции в compile-time
#опытным

Виртуальные функции являются средством реализации динамического полиморфизма в С++. Почему он вообще называется динамическим?

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

Но что, если я вам скажу, что мы можем реализовывать полиморфизм времени компиляции с помощью виртуальных функций?

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

Начиная с С++11 у нас есть constexpr функции. Эти функции могут быть вычислены на этапе компиляции, если их аргументы также известны на этом этапе. Аргументы могут быть константами, литералами, constexpr переменными или результатом вычисления других constexpr функций.

constexpr int double_me(int n)
{
    return n * 2;
}
// условие верное и мы не падаем
static_assert(double_me(4) == 8);
// условие ложно и компиляция прервется на этой строчке
static_assert(double_me(4) == 7);

В примере мы определяем constexpr функцию double_me и проверяем с помощью static_assert'а то, что она вычисляется во время компиляции.

Изначально constexpr функции были довольно ограничены по возможностям своего применения. Однако с новыми стандартами спектр применений расширяется, так как все больше операций из стандартной библиотеки можно проводить в compile-time. Сейчас даже с контейнерами в complie-time можно работать. Но мы сейчас не об этом.

Начиная с С++20 constexpr функции могут быть виртуальными!

struct VeryComplicatedCaclulation
{
    constexpr virtual int double_me(int n) const = 0;
};

struct Impl: VeryComplicatedCaclulation
{
    constexpr virtual int double_me(int n) const override
    {
        return 2 * n;
    }
};

constexpr auto impl = Impl{};
// для полиморфизма с виртуальными функциями нужна ссылка
constexpr const VeryComplicatedCaclulation& impl_ref = impl;

constexpr auto a = impl_ref.double_me(4);
static_assert(a == 8); // true

Все как мы привыкли: делаем иерархию классов с виртуальной функцией, только везде на всех этапах приписываем constexpr. И это работает!

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

Increase your usability. Stay cool.

#cpp11 #cpp20 #cppcore

Виртуальные функции в compile-time
#опытным

Виртуальные функции являются средством реализации динамического полиморфизма в С++. Почему он вообще называется динамическим?

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

Но что, если я вам скажу, что мы можем реализовывать полиморфизм времени компиляции с помощью виртуальных функций?

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

Начиная с С++11 у нас есть constexpr функции. Эти функции могут быть вычислены на этапе компиляции, если их аргументы также известны на этом этапе. Аргументы могут быть константами, литералами, constexpr переменными или результатом вычисления других constexpr функций.

constexpr int double_me(int n)
{
    return n * 2;
}
// условие верное и мы не падаем
static_assert(double_me(4) == 8);
// условие ложно и компиляция прервется на этой строчке
static_assert(double_me(4) == 7);

В примере мы определяем constexpr функцию double_me и проверяем с помощью static_assert'а то, что она вычисляется во время компиляции.

Изначально constexpr функции были довольно ограничены по возможностям своего применения. Однако с новыми стандартами спектр применений расширяется, так как все больше операций из стандартной библиотеки можно проводить в compile-time. Сейчас даже с контейнерами в complie-time можно работать. Но мы сейчас не об этом.

Начиная с С++20 constexpr функции могут быть виртуальными!

struct VeryComplicatedCaclulation
{
    constexpr virtual int double_me(int n) const = 0;
};

struct Impl: VeryComplicatedCaclulation
{
    constexpr virtual int double_me(int n) const override
    {
        return 2 * n;
    }
};

constexpr auto impl = Impl{};
// для полиморфизма с виртуальными функциями нужна ссылка
constexpr const VeryComplicatedCaclulation& impl_ref = impl;

constexpr auto a = impl_ref.double_me(4);
static_assert(a == 8); // true

Все как мы привыкли: делаем иерархию классов с виртуальной функцией, только везде на всех этапах приписываем constexpr. И это работает!

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

Increase your usability. Stay cool.

#cpp11 #cpp20 #cppcore

Сравниваем производительности оператора<
#опытным

В этом посте я рассказал об отличном способе лексикографического сравнения набора объектов с помощью std::tie. Однако в комментариях несколько подписчиков задались вопросом, а не будет ли использование std::tie сильно ударять по производительности? Настоящих плюсовиков всегда на подкорке волнует вопрос оверхеда используемых инструментов. Поэтому сегодня мы выясним, есть ли разница в более менее практических вычислениях между разными вариантами оператора< .

Большое спасибо, @SoulslikeEnjoyer, за представление основного объема кода.

Сравним 4 реализации operator<:

struct Time_comparison_unreadable {
  int hours;
  int minutes;
  int seconds;

  bool operator<(const Time_comparison_unreadable& other) {
    if ((hours < other.hours) || (hours == other.hours && minutes < other.minutes) || (hours == other.hours && minutes == other.minutes && seconds < other.seconds))
      return true;
    else
      return false;
  }
};

struct Time_comparison_readable {
// fields
  bool operator<(const Time_comparison_readable& other) {
    if (hours < other.hours) return true;
    if (hours > other.hours) return false;
    if (minutes < other.minutes) return true;
    if (minutes > other.minutes) return false;
    if (seconds < other.seconds) return true;
    return false;
  }
};

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

struct Time_spaceship {
// fields
  auto operator<=>(const Time_spaceship &) const = default;
};

Первые 2 варианта - это обычные реализации лексикографического оператора сравнения, просто второй из них более читаемый. В структуре Time_tie мы используем std::tie для формирования тупла и используем оператор сравнения тупла. В последнем варианте используем дефолтно-сгенерированный spaceship оператор.

Для того, чтобы качественно сравнить время выполнения чего-либо aka провести перфоманс тесты, нам поможет фреймфорк google benchmark. Она предоставляет гибкие инструменты для управления запуском кода и измерением времени его работы. Не будем вдаваться в детали фреймворка, а сразу посмотрим код:

std::random_device dev;
std::mt19937 rng(dev());
std::uniform_int_distribution<int> dist(1,100);

template <typename TimeClass>
static void time_comparison_experiment(benchmark::State& state) {
  std::vector<TimeClass> v(1'000'000);
  std::generate(v.begin(), v.end(), [&] () -> TimeClass { return TimeClass{ dist(rng) % 24, dist(rng) % 60, dist(rng) % 60 }; });
  while (state.KeepRunning()) {
    auto start = std::chrono::high_resolution_clock::now();
    std::sort(v.begin(), v.end());
    auto end = std::chrono::high_resolution_clock::now();
    
    auto elapsed_seconds =
    std::chrono::duration_cast<std::chrono::duration<double>>(
    end - start);
    state.SetIterationTime(elapsed_seconds.count());
    std::shuffle(v.begin(), v.end(), rng);
  }
}

BENCHMARK(time_comparison_experiment<Time_comparison_unreadable>)->UseManualTime()->Iterations(20);

BENCHMARK(time_comparison_experiment<Time_comparison_readable>)->UseManualTime()->Iterations(20);

BENCHMARK(time_comparison_experiment<Time_tie>)->UseManualTime()->Iterations(20);

BENCHMARK(time_comparison_experiment<Time_spaceship>)->UseManualTime()->Iterations(20);

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

В конце мы запускаем бенчмарк над функцией с измерением времени выполнения, говорим ему, что мы сами будет мерять время(UseManualTime), и сколько итераций цикла нужно выполнить(Iterations(20)).

ПРОДОЛЖЕНИЕ В КОММЕНТАРИЯХ

Compare things. Stay cool.

#performance #cpp20

Итоги конкурса

Мы долго ждали и, наконец, дождались. Вчера мы честно взяли генератор случайных чисел и нашли победителя и будущего счастливого обладателя книжки "С++ для начинающих" Герберта Шилдта. Ботов розыгрышей не хотелось использовать, без души все это. Надеюсь, вы доверяете нашей непредвзятости)

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

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

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

Be lucky. Stay cool.

Макросы
#новичкам

Один из способов избежать дублирования кода — использовать макросы. Макросы — инструкции препроцессора, которые позволяют заменять одни строки на другие:

#define MAX(a, b) ((a) > (b) ? (a) : (b))

Теперь вы можете использовать этот макрос, возвращающий максимальное из 2-х значений, для любых типов данных:

int result1 = MAX(1, 2);          // Работает
double result2 = MAX(1.5, 2.5);   // Тоже работает

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

#define MAX(a, b) ((a) > (b) ? (a) : (b))

int x = 5;
int y = 10;

int result = MAX(++x, ++y);

Мы хотим сравнить две переменные после их инкрементов. Поэтому ожидаемые значения: 11, 6, 11. Однако у препроцессора и компилятора есть свое мнение на этот счет. Реальный вывод:

Result: 11
x: 6
y: 12

Переменная y имеет значение на один больше ожидаемого. Это перестает быть удивительным после того, как мы посмотрим на то, во что раскрывается макрос:

int result = ++x > ++y ? ++x : ++y;

Мы просто подставили текст и в любых значениях x и y, одна из этих переменных претерпит лишний инкремент.

Более сложные ситуации генерируют все менее и менее тривиальные ошибки.

Недостатки макросов

🔞 Нетипобезопасность: Макросы не проверяют типы данных. Программа может скомпилироваться, но упасть в runtime.

🔞 Побочные эффекты: Макросы могут привести к неожиданным результатам, особенно если аргументы содержат побочные эффекты (например, инкременты).

🔞 Сложность отладки: Макросы могут раскрываться в причудливые строки, которые вы просто не увидите в своем коде. Придется отлаживаться по файлу с кодом после препроцессора, а это нетривиальная задача.

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

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

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

Don't be confusing. Stay cool.

#cppcore

Макросы
#новичкам

Один из способов избежать дублирования кода — использовать макросы. Макросы — инструкции препроцессора, которые позволяют заменять одни строки на другие:

#define MAX(a, b) ((a) > (b) ? (a) : (b))

Теперь вы можете использовать этот макрос, возвращающий максимальное из 2-х значений, для любых типов данных:

int result1 = MAX(1, 2);          // Работает
double result2 = MAX(1.5, 2.5);   // Тоже работает

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

#define MAX(a, b) ((a) > (b) ? (a) : (b))

int x = 5;
int y = 10;

int result = MAX(++x, ++y);

Мы хотим сравнить две переменные после их инкрементов. Поэтому ожидаемые значения: 11, 6, 11. Однако у препроцессора и компилятора есть свое мнение на этот счет. Реальный вывод:

Result: 11
x: 6
y: 12

Переменная y имеет значение на один больше ожидаемого. Это перестает быть удивительным после того, как мы посмотрим на то, во что раскрывается макрос:

int result = ++x > ++y ? ++x : ++y;

Мы просто подставили текст и в любых значениях x и y, одна из этих переменных претерпит лишний инкремент.

Более сложные ситуации генерируют все менее и менее тривиальные ошибки.

Недостатки макросов

🔞 Нетипобезопасность: Макросы не проверяют типы данных. Программа может скомпилироваться, но упасть в runtime.

🔞 Побочные эффекты: Макросы могут привести к неожиданным результатам, особенно если аргументы содержат побочные эффекты (например, инкременты).

🔞 Сложность отладки: Макросы могут раскрываться в причудливые строки, которые вы просто не увидите в своем коде. Придется отлаживаться по файлу с кодом после препроцессора, а это нетривиальная задача.

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

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

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

Don't be confusing. Stay cool.

#cppcore

Капибарам нужна ваша помощь на T-CTF

У них лапки, и они не могут защитить код от уязвимостей. Выручите их на ИТ-соревновании от Т-Банка с шансом выиграть приз до 420 000 ₽.

Без навыков в ИТ тут не обойтись — задания рассчитаны на разработчиков, QA- и SRE-инженеров, аналитиков и других ИТ-специалистов уровня middle и senior.

Вот что вас ждет:

— Выберите Лигу Разработки или Лигу Безопасности по своим скиллам. Если участвуете впервые, можно потренироваться на демозаданиях.
— Соревнуйтесь один или в команде до 3 человек. Организаторы помогут найти команду, если нет своей.
— Подключайтесь онлайн или приходите офлайн — в ИТ-хаб Т-Банка в одном из 6 городов России.
— Решайте задания по спортивному хакингу — для этого у вас будет 36 часов.

Соревнование пройдет 19 и 20 апреля.

Попробуйте свои силы — успейте зарегистрироваться до 18 апреля.

Реклама. АО «ТБанк», лицензия ЦБ РФ № 2673, erid: 2Ranyo2pn9w

Идеальная передача из лямбды
#опытным

Мутабельные лямбды позволили нам перемещать захваченные по значению объекты в сторонние функции:

auto callback = [message=get_message(), &scheduler]() mutable {
  // some preparetions 
  scheduler.submit(std::move(message));
}

Ну а передача копии вообще никогда не была проблемой:

auto callback = [message=get_message(), &scheduler]() {
  // some preparetions 
  scheduler.submit(message);
}

Однако подобную функцию можно использовать в двух контекстах: с возможностью повторного выполнения и одноразового исполнения:

callback(); // retry(callback)
std::move(callback)(); // try-or-fail(rvalue)

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

Это все можно делать с помощью явного this и std::forward_like:

auto callback = [message=get_message(), &scheduler](this auto &&self) {
    return scheduler.submit(std::forward_like<decltype(self)>(message));
};

Пара интересных наблюдений:

👉🏿 Если c std::forward мы могли идеально передать лишь объект замыкания, то с использованием std::forward_like мы можем кастить любой объект к точно такому же ссылочному типу, как и у объекта замыкания. Это позволяет мувать сообщение внутрь шедулера при использовании try-or-fail подхода вызова лямбды.

👉🏿 Можно заметить, что лямбда не мутабельная, хотя в ней возможно изменение объекта message. Это потому что при использовании явного this оператор() у замыкания по умолчанию мутабельный. Таков закон стандарт.

Из адекватных примеров явного this на этом все.

Deducing this - одна из мажорных фичей 23-го стандарта. Рано или поздно все на него перейдут и нужно заранее знать кейсы, где фичу можно использовать, чтобы писать более понятный и оптимальный код.

Be a major figure. Stay cool.

#template #cpp23

Идеальная передача из лямбды
#опытным

Мутабельные лямбды позволили нам перемещать захваченные по значению объекты в сторонние функции:

auto callback = [message=get_message(), &scheduler]() mutable {
  // some preparetions 
  scheduler.submit(std::move(message));
}

Ну а передача копии вообще никогда не была проблемой:

auto callback = [message=get_message(), &scheduler]() {
  // some preparetions 
  scheduler.submit(message);
}

Однако подобную функцию можно использовать в двух контекстах: с возможностью повторного выполнения и одноразового исполнения:

callback(); // retry(callback)
std::move(callback)(); // try-or-fail(rvalue)

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

Это все можно делать с помощью явного this и std::forward_like:

auto callback = [message=get_message(), &scheduler](this auto &&self) {
    return scheduler.submit(std::forward_like<decltype(self)>(message));
};

Пара интересных наблюдений:

👉🏿 Если c std::forward мы могли идеально передать лишь объект замыкания, то с использованием std::forward_like мы можем кастить любой объект к точно такому же ссылочному типу, как и у объекта замыкания. Это позволяет мувать сообщение внутрь шедулера при использовании try-or-fail подхода вызова лямбды.

👉🏿 Можно заметить, что лямбда не мутабельная, хотя в ней возможно изменение объекта message. Это потому что при использовании явного this оператор() у замыкания по умолчанию мутабельный. Таков закон стандарт.

Из адекватных примеров явного this на этом все.

Deducing this - одна из мажорных фичей 23-го стандарта. Рано или поздно все на него перейдут и нужно заранее знать кейсы, где фичу можно использовать, чтобы писать более понятный и оптимальный код.

Be a major figure. Stay cool.

#template #cpp23

Идеальная передача из лямбды
#опытным

Мутабельные лямбды позволили нам перемещать захваченные по значению объекты в сторонние функции:

auto callback = [message=get_message(), &scheduler]() mutable {
  // some preparetions 
  scheduler.submit(std::move(message));
}

Ну а передача копии вообще никогда не была проблемой:

auto callback = [message=get_message(), &scheduler]() {
  // some preparetions 
  scheduler.submit(message);
}

Однако подобную функцию можно использовать в двух контекстах: с возможностью повторного выполнения и одноразового исполнения:

callback(); // retry(callback)
std::move(callback)(); // try-or-fail(rvalue)

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

Это все можно делать с помощью явного this и std::forward_like:

auto callback = [message=get_message(), &scheduler](this auto &&self) {
    return scheduler.submit(std::forward_like<decltype(self)>(message));
};

Пара интересных наблюдений:

👉🏿 Если c std::forward мы могли идеально передать лишь объект замыкания, то с использованием std::forward_like мы можем кастить любой объект к точно такому же ссылочному типу, как и у объекта замыкания. Это позволяет мувать сообщение внутрь шедулера при использовании try-or-fail подхода вызова лямбды.

👉🏿 Можно заметить, что лямбда не мутабельная, хотя в ней возможно изменение объекта message. Это потому что при использовании явного this оператор() у замыкания по умолчанию мутабельный. Таков закон стандарт.

Из адекватных примеров явного this на этом все.

Deducting this - одна из мажорных фичей 23-го стандарта. Рано или поздно все на него перейдут и нужно заранее знать кейсы, где фичу можно использовать, чтобы писать более понятный и оптимальный код.

Be a major figure. Stay cool.

#template #cpp23