​​No new line

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

Небольшой пример:

Файлик foo.hpp:

// I love code
// I love C++<no newline>

Файлик bar.cpp:

#include "foo.hpp"
#include "baz.hpp"

А теперь вспоминаем, что препроцессор вставляет все содержимое хэдера на место инклюда И(!) не вставляет после него символ конца строки. То есть спокойно может получится следующее:

// I love code
// I love C++#include "baz.hpp"

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

Стандарт нам говорит:

... If a source file that is not empty does not end in a new-line character,
 or ends in a new-line character immediately preceded by a backslash
 character before any such splicing takes place, the behavior is undefined.

Так что ub без кода - вполне существующая вещь.

Или уже нет?

На самом деле приведенная цитата была из стандарта 2003 года.

С++11 пофиксил эту проблему и обязал препроцессоры вставлять new line в конце подключаемых файлов:

A source file that is not empty and that does not end in a new-line character, 
or that ends in a new-line character immediately preceded by a backslash 
character before any such splicing takes place, shall be processed 
as if an additional new-line character were appended to the file.

Так что теперь проблемы нет.

Решил написать об этом, просто потому что очень весело, что в плюсах можно было такими неочевидными способами отстрелить себе конечность.

Ну и хорошо, что стандарт все-таки не только новую функциональность вводит, а фиксит вот такие вот недоразумения.

Fix your flaws. Stay cool.

#compiler

Квиз

Сегодня будет интересный #quiz из малоизвестной области плюсов. А именно дефолтные параметры виртуальных методов. У них немного неинтуитивное поведение. Так что давайте проверим, насколько ваша интуиция вам врет.

Правильный ответ показывать сразу не буду, пусть останется интригой до завтрашнего поста с объяснениями.

У меня к вам всего один вопрос. Каков результат попытки компиляции и запуска следующего кода под С++20?

#include <iostream>
struct base {
  virtual void foo(int a = 0) { std::cout << a << " "; }
  virtual ~base() {}
};

struct derived1 : base {};

struct derived2 : base {
  void foo(int a = 2) { std::cout << a << " "; }
};

int main() {
  derived1 d1{};
  derived2 d2{};
  base & bs1 = d1;
  base & bs2 = d2;
  d1.foo();
  d2.foo();
  bs1.foo();
  bs2.foo();
}

Challenge your life. Stay cool.

Дефолтные параметры виртуальных методов
#опытным

Как и в обычных функциях и методах класса, в виртуальных методах тоже можно определять параметры по-умолчанию. Однако, они могут вести себя не совсем так, как вы этого ожидаете. Спасибо, @d7d1cd, за идею для поста)

Правильный ответ из поста выше - 0 2 0 0 .

#include <iostream>
struct base {
  virtual void foo(int a = 0) { std::cout << a << " "; }
  virtual ~base() {}
};

struct derived1 : base {};

struct derived2 : base {
  void foo(int a = 2) { std::cout << a << " "; }
};

int main() {
  derived1 d1{};
  derived2 d2{};
  base & bs1 = d1;
  base & bs2 = d2;
  d1.foo();
  d2.foo();
  bs1.foo();
  bs2.foo();
}

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

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

А если мы вызываем метод по указателю или ссылке на базовый класс, то дефолтное значение будет взято из объявления метода в базовом классе.

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

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

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

Слышится легкое: "Эх, я когда-нибудь смогу выучить плюсы?...".

Don't be confusing. Stay cool.

#cppcore

Помогите Доре найти проблему в коде
#опытным

Наткнулся на просторах всемирной сети на интересный пример:

#include <cstdio>

void bar(char * s) {
  printf("%s", s);
}

void foo() {
  char s[] = "Hi! I'm a kind of a loooooooooooooooooooooooong string myself, you know...";
  bar(s);
}

int main() {
  foo();
}

Код работает и пример довольно игрушечный. Однако в этом С++ коде есть проблема/ы. Сможете ли вы их найти?

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

Critique your solutions. Stay cool.

#fun

​​Ответ

Поговорим о том, что не так в коде из предыдущего поста:

#include <cstdio>

void bar(char * s) {
  printf("%s", s);
}

void foo() {
  char s[]  =
    "Hi! I'm a kind of a loooooooooooooooooooooooong "
    "string myself, you know...";
  bar(s);
}

int main() {
  foo();
}

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

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

🔞 В bar() нет никакой проверки границ. Почему-то функция надеется, что когда-нибудь она встретит null-terminator. Но этого спокойно может и не быть: передадим туда обычный массив символов и будет UB.

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

Как мог бы выглядеть бы код на современных плюсах?

#include <print>
#include <string_view>

void bar(std::string_view s) {
  std::println("{}", s);
}

void foo() {
  constexpr std::string_view s  =
    "Hi! I'm a kind of a loooooooooooooooooooooooong "
    "string myself, you know...";
  bar(s);
}

int main() {
  foo();
}

Всего 2 простых улучшения:

✅ Использование легковестного std::string_view из С++17. Это по сути просто указатель + размер данных, так что накладные расходы на этот объект минимальны. А еще его даже рекомендуют передавать в функции по значению.

✅ Вместо сишной вариабельной нетипобезопасной функции printf используем типобезопасную плюсовую std::println на вариабельных шаблонах из С++23.

Простые улучшения, но в итоге все неприятности пофиксили. Магия С++.

Believe in magic. Stay cool.

#cppcore #cpp23 #cpp17

Квиз
#опытным

В тему std::invoke закину вам интересный #quiz. Будем вызывать ведьм мемберы класса.

Что выведется на консоль в результате попытки компиляции и запуска следующего кода?

#include <functional>
#include <iostream>

struct Data {
    int memberFunction(int value) {
        return value;
    }
    int field = 42;
};

int main() {
    Data data;
    auto methodPtr = &Data::memberFunction;
    auto fieldPtr = &Data::field;
    std::cout << std::invoke(methodPtr, data, std::invoke(fieldPtr, data)) << std::endl;
}

Explore details. Stay cool.

Квиз

Сегодня #quiz на любимую тему всех плюсовиков - утечку памяти.

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

Спасибо Сергею Борисову за идею для поста)

Ну а сейчас у меня для вас всего один вопрос. Будет ли в этом коде утечка памяти или нет?

#include <iostream>
#include <stdexcept>

class Bar {
public:
    Bar() {
        throw std::runtime_error("Error");
    }
};

int main() {
    Bar *bar = nullptr;

    try {
        bar = new Bar();
    } catch(...) {
        std::cout << "Houston, we have a problem" << std::endl;
    }
}

Challenge yoursef. Stay cool

Почему еще важен std::forward
#опытным

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

Также спасибо ему за предоставление следующего примера:

#include <iostream>

void bar(float&& x) { std::cout << "float " << x << "\n"; }
void bar(int&& x) { std::cout << "int " << x << "\n"; }

void foo(auto&& v) { bar(v); }

int main() {
  foo(1);
  foo(2.0f);
}

Как думаете, что выведется на консоль? Подумайте пару секунд.

Ну нормальный человек ответит:

int 1
float 2

Однако командная строка вам выдаст следующее:

float 1
int 2

Если не верите, по посмотрите в годболте. И можете уже сейчас написать в комментах: "ЧЗХ", "WTF", "WAT" и прочее.

А нам пораразбирацца.

Тут используется auto в аргументах функции, значит эта функция неявно шаблонная. Посмотрим, что нам выдаст cppinsights по этому коду:

#ifdef INSIGHTS_USE_TEMPLATE
template<>
void foo<int>(int && v)
{
  bar(static_cast<float>(v));
}
#endif


#ifdef INSIGHTS_USE_TEMPLATE
template<>
void foo<float>(float && v)
{
  bar(static_cast<int>(v));
}
#endif

Просто прекрасно. Какого черта компилятор кастит переменные к противоположным типам?

Первое, что важно понимать: внутри функции foo переменная v - это уже lvalue, так как имеет имя. Значит просто так вызвать перегрузки для правых ссылок он не может.

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

То есть происходит следующее: компилятор понимает, что подходящей перегрузки нет, поэтому начинает применять стандартные преобразования в другие типы. Любой каст дает временный объект. А временный объект типа int легко биндится к float&&, как и временный объект float легко биндится к int&&.

Вот и получается обмен вызовами.

Чтобы такого не происходило, применяйте перед сном std::forward. Если есть контекст вывода типов, то он помогает правильно передавать категорию выражения объекта во внутренние вызовы.

#include <iostream>

void bar(float&& x) { std::cout << "float " << x << "\n"; }
void bar(int&& x) { std::cout << "int " << x << "\n"; }

void foo(auto&& v) { bar(std::forward<decltype(v)>(v)); }

int main() {
  foo(1);
  foo(2.0f);
}

В этом случае вывод будет ожидаемым.

Be amazed. Stay cool.

#cppcore #cpp11 #template

Ревью
#новичкам

Сегодня у нас #ревью довольно простого кода, который показывает простые механики С++. Однако не расслабляйтесь! Это мир С++, а он не такой уж солнечный и приветливый даже в самых простых случаях.

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

Сегодняшний лот:

#include <cstring>
#include <iostream>

class Data {
public:
    char* buffer;

    Data(const char* input) {
        buffer = new char[strlen(input)];
        std::strcpy(buffer, input);
    }

    ~Data() {
        delete buffer;
    }
};

bool compareData(Data data1, Data data2) {
    return data1.buffer == data2.buffer;
}

int main() {
    Data d("Hello");
    bool result = compareData(d, d);

    std::cout << "Result: " << result << std::endl;
}

Продуктивной прожарки всем!

Critique your solutions. Stay cool.

Динамический полиморфизм: разделяемые библиотеки
#опытным

В тему указателей на функции вкину еще один способ реализации полиморфизма в С++ - разделяемые или динамические библиотеки.

Обычно разделяемые библиотеки загружаются на самом старте программы(какие-нибудь libc и libstdc++ например неявно подгружаются на старте). Основную часть таких библиотек мы прописываем в опциях линковки.

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

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

Тут пример будет довольно длинный, поэтому начнем с начала.

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

class PluginInterface {
public:
  virtual int method() = 0;
};

extern "C" PluginInterface* create_plugin();

extern "C" void destroy_plugin(PluginInterface* obj);

Эта команда берет и реализует этот интерфейс:

#include "PluginInterface.hpp"
#include <iostream>

class MyPlugin : public PluginInterface {
public:
  virtual void method() override;
};

int MyPlugin::method() {
  std::cout << "Method is called\n";
  return 42;
}

extern "C" PluginInterface* create_plugin() {
  return new MyPlugin();
}

extern "C" void destroy_plugin(PluginInterface* obj) {
  delete obj;
}

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

Функции create_plugin и destroy_plugin обязаны иметь сишную линковку, чтобы достать указатели на них по их имени из библиотеки с помощью dlsym:

#include "PluginInterface.hpp"
#include <dlfcn.h>
#include <iostream>

typedef PluginInterface *(*creatorFunction)();
typedef void (*destroyerFunction)(PluginInterface *);

int main() {
  void *handle = dlopen("myplugin.so", RTLD_LAZY);
  if (!handle) {
    std::println("dlopen failure: {}", dlerror());
    return 1;
  }
  creatorFunction create = reinterpret_cast<creatorFunction>(dlsym(handle, "create_plugin"));
  destroyerFunction destroy = reinterpret_cast<destroyerFunction>(dlsym(handle, "destroy_plugin"));
  
  PluginInterface *plugin = (*create)();
  std::println("{}", plugin->method());
  (*destroy)(plugin);
  dlclose(handle);
}

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

Разве по имени функции можно получить указатель на нее? Похоже на какую-то рефлексию с первого взгляда.

Тут дело в именах функций и отображении их в символы бинарного файла при компиляции. В С нет никакого манглинга имен, поэтому в готовом бинарном файле можно найти символ, соответствующий названию функции, и связанный с ним адрес этой фукнции. Именно поэтому create_plugin и destroy_plugin помечены extern "C", чтобы их имена обрабатывались по правилам С.

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

Choose the right name. Stay cool.

#cppcore #OS #compiler

​​WAT
#новичкам

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

Дан простой кусок кода:

#include <array>
#include <cstring>
#include <iostream>

int main(int argc, char *argv[]) {
    const char *string{nullptr};
    std::size_t length{0};
    if (const bool thisIsFalse = argc > 100000;
        thisIsFalse) {
        string = "ABC";
        length = 3;
    }

    std::array<char, 128> buffer;
    std::memcpy(buffer.data(), string, length);

    if (string == nullptr) {
        std::cout
            << "String is null, so cancel the launch.\n";
    } else {
        std::cout << "String is not null, so launch the "
                     "missiles!\n";
    }
}

Единственный вопрос: что выведется на экран при запуске программы без аргументов?

Подумайте несколько секунд.

"Да все очевидно же. string не меняется, поэтому сообщение об этом и выведется на экран".

Но мы же на плюсах пишем, тут невозможное становится возможным.

Например, при компиляции на gcc на О3 оптимизациях выводится String is not null, so launch the missiles!

"WAT? Где пруфы?"

А вот они.

Виновато конечно во всем ненавистное UB. Все грязные тряпки кидайте в него.

По стандарту, если в memcpy передать нулевой указатель, то поведение неопределено. Может случиться все, что угодно.

Это может произойти, только если количество аргументов запуска программы меньше 100000. То есть одна ветка приводит к UB, а вторая нет. И на основании этого gcc делает вывод, что порченная ветвь кода никогда не должна выполняться (так как UB означает, что поведение программы не определено, то компилятор может предполагать, что UB не должно происходить) и просто выкидывает эту ветку из ассемблера.

Уберите условие, либо memcpy, то вывод будет ожидаемым. Либо UB не будет, либо эвристики компилятора по-другому заработают.

Пишите качественный и безопасный код, чтобы не было таких неожиданностей.

Be safe. Stay cool.

#cppcore

​​std::getenv
#новичкам

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

- Конфигурации приложений
- Хранения чувствительных данных (паролей, ключей API)
- Управления поведением программ

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

Или например, более приближеный к плюсам пример, LD_LIBRARY_PATH. Это список путей, в котором линкер ищет указанные при линковке библиотеки.

И мы можем прочитать из плюсового кода переменные окружения с помощью С++11 функции std::getenv:

#include <cstdlib>

char* std::getenv(const char* name);

Это скоммунизженная из Сей функция, которая принимает имя переменной окружения и возвращает ее содержимое. Если искомой переменной не существует, возвращается nullptr.

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

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

Допустим, пишите вы какой-нибудь свой клиент-сервер на Boost.Asio. Хочется конфигурировать клиента адресом и портом сервера извне, чтобы иметь возможность по-разному запускать клиента локально и, допустим, через docker-compose. Конфиг и его парсилку писать довольно муторно, а адекватную парсилку аргументов командной строки - еще сложнее. Даже если использовать готовые решения в виде json парсера и boost.program_options.

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

#include <boost/asio.hpp>
#include <iostream>
#include <cstdlib>

using boost::asio::ip::tcp;

int main() {
    try {
        // HERE
        const char* host = std::getenv("SERVER_HOST");
        const char* port = std::getenv("SERVER_PORT");

        if (!host || !port) {
            std::cerr << "Please set SERVER_HOST and SERVER_PORT environment variables\n";
            return 1;
        }

        boost::asio::io_context io_context;

        // Создаем и соединяем сокет
        tcp::socket socket(io_context);
        tcp::resolver resolver(io_context);
        boost::asio::connect(socket, resolver.resolve(host, port));

        // Отправляем тестовое сообщение
        std::string message = "Hello from Boost.Asio client!\n";
        boost::asio::write(socket, boost::asio::buffer(message));

        // Читаем ответ (до символа новой строки)
        boost::asio::streambuf response;
        boost::asio::read_until(socket, response, '\n');

        // Выводим ответ
        std::istream is(&response);
        std::string reply;
        std::getline(is, reply);
        std::cout << "Server replied: " << reply << std::endl;

    } catch (std::exception& e) {
        std::cerr << "Exception: " << e.what() << "\n";
        return 1;
    }

    return 0;
}

Всего две строчки и никакой мороки! Очень удобная и полезная функция.

Explore your enviroment. Stay cool.

#cpp11

​​Третий аргумент main
#новичкам

Почти всегда вы пишите функцию main вот так:

int main() {
  // some code
}

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

int main (int argc, char* argv[]) {
  // argc - количество переданных аргументов
  // argv - массив из переданных аргументов

  // some parsing
}

Однако в стандарте описан еще один способ определения main:

int main(/ implementation-defined /) {body}

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

Самая часто встречающаяся нестандартная сигнатура main следующая:

int main(int argc, char*  argv[], char* envp[]) {}

Третий аргумент main - это массив строк переменных окружения в формате "KEY=value". Массив завершается null pointer'ом.

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

Вот минимальный примерчик:

#include <iostream>

int main(int argc, char* argv[], char* envp[]) {
    std::cout << "Environment variables:\n";
    
    for (char** env = envp; *env != nullptr; env++) {
        std::cout << *env << "\n";
    }
    
    return 0;
}

Возможный вывод:

PATH=/usr/local/bin:/usr/bin:/bin
USER=grokaem_cpp
...

Вы не так часто можете увидеть этот формат сигнатуры main по уже очевидным для вас причинам:

- нестандарт
- а самое главное - это дело надо парсить. Засовывать в мапу какую-то и искать потом по ключу нужную переменную. А зачем, если есть std::getenv или его брат getenv из Сей.

Рассказываю про это, чтобы вы при встрече в таким форматом аргументов main не думали, что что-то базовое упустили при изучении плюсов. Ну или просто для расширения кругозора)

Expand your horizons. Stay cool.

#NONSTANDARD #goodoldc

​​environ
#опытным

В POSIX-совместимых системах (Linux, macOS, BSD) существует еще один альтернатива параметру envp в функции main() и функции std::getenv() для получения значений переменных окружения. Это глобальная переменная extern char** environ, которая предоставляет прямой доступ ко всему окружению процесса.

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

#include <stdio.h>

extern char** environ;

void foo() {
    for(char** env = environ; *env != NULL; env++) {
        printf("%s\n", *env);
    }
}

В остальном, особенности работы такие же, как и у envp.

Но если мы уже зашли по колено в Posix, то там есть функция setenv, которая позволяет менять переменные окружения уже в ходе выполнения программы:

#include <stdlib.h>  
  
int setenv(const char *envname, const char *envval, int overwrite);

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

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

Интересно, как много в С|С++ методов получения окружения процесса. Но рекомендуется использовать конечно стандартный вариант std::getenv.

Be visiable. Stay cool.

#NONSTANDARD

​​Разбор ревью
#новичкам

Большое спасибо всем участникам ревью, которые проявили активность под предыщущим постом. Всем и каждому посылаем лучи благодарности!

Было непросто выбрать самый эффективный по критике комментарий, потому что некоторые люди предлагали странные решения. В итоге, мы выбрали @seweeex и вот его коммент. Давайте похлопаем ему 👏👏👏.

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

Поехали разбирать.

🔞 Зачем-то в очереди хранятся сырые указатели. Смысла в этом особого нет, кроме как подложить себе свинью на будущее и поджечь жёпы комментаторов. Тут даже умные указатели не нужны, зачем дополнительные аллокации? В очереди можно хранить сами объекты и никаких проблем с менеджментом памяти не будет.

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

🔞 Слон в посудной лавке здесь - это конечно отсутствие синхронизации на очереди. Это в принципе ub и дальше не о чем говорить. Нужна не стандартная, а потокобезопасная очередь.

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

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

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

🔞 Гонка на потоконебезопасном логировании. Нужен мьютекс, чтобы сообщения не интерферировали.

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

#include <queue>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <memory>
#include <optional>
#include <print>

struct Message {
    int data;
};

template<typename T>
class ThreadSafeQueue {
public:
    void push(T msg) {
        {
            std::lock_guard lock(mutex_);
            queue_.push(std::move(msg));
        }
        cv_.notify_one();
    }

    std::optional<T> pop() {
        std::unique_lock lock(mutex_);
        cv_.wait(lock, [this] { return !queue_.empty() || stopped_; });
        
        if (stopped_ && queue_.empty()) {
            return std::nullopt;
        }

        auto msg = std::move(queue_.front());
        queue_.pop();
        return msg;
    }

    void stop_receive() {
        stopped_ = true;
        cv_.notify_all();
    }

private:
    std::queue<T> queue_;
    std::mutex mutex_;
    std::condition_variable cv_;
    std::atomic<bool> stopped_ = false;
};

void println(const std::string& str) {
    static std::mutex mtx;
    std::lock_guard lock(mtx);
    std::cout << str << std::endl;
}

void sender(ThreadSafeQueue<Message>& msgQueue) {
    for (int i = 0; i < 20; ++i) {
        auto msg = Message(i); 
        println("Sent: " + std::to_string(msg.data));
        msgQueue.push(std::move(msg));
    }
    msgQueue.stop_receive();
}

void receiver(ThreadSafeQueue<Message>& msgQueue) {
    while (auto msg = msgQueue.pop()) {        
        println("Received: " + std::to_string(msg.value().data));
    }
}

int main() {
    ThreadSafeQueue<Message> msgQueue;
    std::thread t1(sender, std::ref(msgQueue));
    std::thread t2(receiver, std::ref(msgQueue));

    t1.join();
    t2.join();
}

Пишите свои дополнения, если что-то забыли.

Make things better. Stay cool.

#include <filename> vs #include "filename"
#новичкам

Тот нюанс, который зеленые программисты С++ впитывают из окружающей среды, но зачастую не понимают его деталей.

Дано: файл, который нужно включить в проект. Задача: определить, включать его через треугольные скобки или кавычки. Какой подход выбрать?

Стандарт нам дает отписку, что поведение при обоих подходах implementation defined, поэтому надо смотреть на то, как ведут себя большинство компиляторов.

Для начала: #include - это директива препроцессора. На месте этой директивы на этапе препроцессинга вставляется тело включаемого файла. Но для того, чтобы вставить текст файла, его надо в начале найти. И вот здесь главное различие.

У компилятора есть 2 вида путей, где он ищет файлы - системные директории и предоставленные юзером через опцию компиляции -I.

Так вот #include <filename> в начале ищет файл в системных директориях. Например, в линуксе хэдэры устанавливаемых библиотек могут оказаться в директориях /usr/include/, /usr/local/include/ или /usr/include/x86_64-linux-gnu/(на x86 системах).

А #include "filename" в начале ищет файл в текущей директории и в директориях, предоставленных через опцию компиляции.

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

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

✅ Используем #include <filename> для включения стандартных файлов и хэдэров сторонних библиотек. Так как они скорее всего установлены по стандартным директориям, логично именно там начинать их поиск.

#include <stdio.h> // Стандартный заголовочник
#include <curl/curl.h>  // Заголовочник из системной директории

int main(void) {
    CURL *curl = curl_easy_init();
    if(curl) {
        printf("libcurl version: %s\n", curl_version());
        curl_easy_cleanup(curl);
    }
    return 0;
}

✅ Используем #include "filename" для включения заголовочных файлов своего проекта. Препроцессор будет сначала искать эти файлы там, где вы ему об этом явно укажите с помощью опций.

// include/mylib.hpp - объявляем функцию из нашего проекта
#pragma once
void print_hello();

// src/main.cpp - используем локальный заголовочник через " "
#include <iostream> // Системный заголовочник
#include "mylib.hpp"  // Заголовочник локального проекта, ищем в указанных путях

int main() {
    print_hello();
    return 0;
}

void print_hello() {
    std::cout << "Hello from my project!\n";
}

// компиляция: g++ -Iinclude/ src/main.cpp -o my_program -std=c++17

See the difference. Stay cool.

#cppcore #compiler

​​Методы, определенные внутри класса
#новичкам

Вы хотите написать header-only библиотеку логирования и собственно пишите:

// logger.hpp
namespace SimpleLogger {

enum class Level { Debug, Info, Warning, Error };

class Logger {
public:
    Logger(const Logger &) = delete;
    Logger &operator=(const Logger &) = delete;

    static Logger &GetInstance() {
        static Logger instance;
        return instance;
    }

    void SetMinLevel(Level level) {
        m_minLevel = level;
    }

    void Log(Level level, const std::string &message) {
        if (level < m_minLevel)
            return;
        auto time = std::chrono::system_clock::to_time_t(std::chrono::system_clock::now());
        std::lock_guard lock{m_mutex};
        std::cout << "[" << std::put_time(std::localtime(&time), "%Y-%m-%d %H:%M:%S") << "] " << "["
                  << levelToString(level) << "] " << message << std::endl;
    }

private:
    Logger() : m_minLevel(Level::Info) { Log(Level::Info, "Logger initialized"); }

    Level m_minLevel;
    std::mutex m_mutex;

    std::string levelToString(Level level) {
        switch (level) {
        case Level::Debug: return "DEBUG";
        case Level::Info: return "INFO";
        case Level::Warning: return "WARN";
        case Level::Error: return "ERROR";
        default: return "UNKNOWN";
        }
    }
};

}  // namespace SimpleLogger

Ваши пользователи вызывают из одной единицы трансляции метод Log:

...
#include <logger.hpp>
...
using namespace SimpleLogger;
Logger::GetInstance().Log(Level::Info, "Select recent items");
db->Execute("Select bla bla");
...

И из второй:

...
#include <logger.hpp>
...
using namespace SimpleLogger;
if (!result) {
  Logger::GetInstance().Log(Level::ERROR, "Result is empty");
  throw std::runtime_error("Result is empty");
}
...

А потом это все успешно линкуется в один бинарник. Как так? Должно же было сработать One Definition Rule, которое запрещает иметь более одного определения функции на всю программу? А у нас как раз все единицы трансляции видят определение метода Log.

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

Так что явно использовать ключевое слово inline в этом случае бессмысленно.

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

Каждая единица трансляции должна сгенерировать свой код для inline метода. Это значит, что обильное использование inline методов может привести к увеличенному времени компиляции.

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

Противоречивые последствия. Либо быстрый рантайм и медленный компайл-тайм, либо наоборот. Как быть?

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

Look for a compromise. Stay cool.

#cppcore #goodpractice

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

Квиз
#новичкам

Сегодня короткий, но от того не менее интересный #quiz, . Можно было бы разобрать вопрос: "а что случится, если я мувну константную ссылку?", но так не очень интересно. Поэтому давайте проверим ваше знание мув-семантики.

У меня к вам всего один вопрос: Какой результат попытки компиляции и запуска следующего кода:

#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 enigma = std::move(ref);
}

Challenge yourself. Stay cool.

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

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

Но она все же неверная. Правильный ответ: на консоль выведется "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