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

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

Обычно разделяемые библиотеки загружаются на самом старте программы(какие-нибудь 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

📈Хотите, чтобы ваши приложения на C++ работали на максимуме?

Присоединяйтесь к открытому уроку «Как сделать ваши приложения C++ супер-производительными»!

На вебинаре вы:
— Научитесь использовать инструменты профилирования gprof, valgrind, Google Benchmark.
— Овладеете техниками повышения производительности кэша и оптимизации управления памятью.
— Узнаете, как использовать оптимизации компилятора для улучшения работы программы.

Все участники вебинара получат скидкуна большое обучение «C++ Developer. Professional».

🔥Не упустите шанс улучшить свои навыки и повысить производительность программ! Регистрация открыта: https://otus.pw/uFr8/

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

​​starts_with, ends_with
#новичкам

До (и включая) C++17, если вы хотите проверить начало или конец в строке на соответствие референсу, вы должны использовать самописные решения, буст или другие сторонние библиотеки. К счастью, это меняется с C++20.

В нем появляются стандартные методы std::string/std::string_view .starts_with() и .ends_with():

constexpr bool starts_with(string_view sv) const noexcept;
constexpr bool starts_with(CharT c ) const noexcept;
constexpr bool starts_with(const CharT* s ) const;

constexpr bool ends_with(string_view sv )const noexcept;
constexpr bool ends_with(CharT c ) const noexcept;
constexpr bool ends_with(const CharT* s ) const;

Как видите, они имеют три перегрузки: для string_view, одного символа и строкового литерала.

const std::string url { "https://isocpp.org" };
    
// string literals
if (url.starts_with("https") && url.ends_with(".org"))
    std::cout << "you're using the correct site!\n";

// a single char:
if (url.starts_with('h') && url.ends_with('g'))
    std::cout << "letters matched!\n";

Кейсов применения этих методов предостаточно: валидация расширения файла, валидация url, html кода, префикса пути до файла, хэдэров http реквестов. В любом более менее большом проекте найдется местечко для этих методов.

Примерчик:

const std::vector<std::string> tokens { 
    "<header>",
    "<h1>",
    "Hello World",
    "</h1>",
    "<p>",
    "This is my super cool new web site.",
    "</p>",
    "<p>",
    "Have a look and try!",
    "</p>",
    "</header>"
};

auto text = tokens | 
            std::views::filter([](const std::string& s) {
                if (s.starts_with("<") || s.ends_with(">"))
                    return false;
                
                return true;
            });

for (const auto& str : text)
    std::cout << str << std::endl;
    
// OUTPUT:
// Hello World
// This is my super cool new web site.
// Have a look and try!

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

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

Be expressive. Stay cool.

#cpp20 #STL

​​std::type_identity
#опытным

Не так давно мы разбирали функцию std::clamp, которая ограничивает значение переменной верхней и нижней границей:

double increment_speed(double curr_speed, double acceleration, double time_delta) {
  curr_speed += acceleration * time_delta;
  return std::clamp(curr_speed, kMinSpeed, kMaxSpeed);
}

В таком виде это прекрасно работает. Однако у std::clamp есть одна проблема: все три ее параметра должны быть одного типа:

template<class T>
constexpr const T& clamp( const T& v, const T& lo, const T& hi );

Если попытаться использовать функцию с разными типами, то получим ошибку вывода типов:

auto bounded = std::clamp(42, 3.14, 69.f); // ERROR!

Компилятор не поймет, какой тип Т имелся ввиду, потому что все три аргумента разных типов.

Можно было сделать 3 отдельных параметра:

template<class T1, class T2, class T3>
constexpr const T& clamp( const T1& v, const T2& lo, const T3& hi );

Но тогда приходилось бы навешивать какие-то compile-time проверки совместимости типов.

Есть подход получше - использовать C++20 std::type_identity. Это максимально простая обертка над типом:

template<class T>
struct type_identity { using type = T; };

template< class T >
using type_identity_t = type_identity<T>::type;

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

template <class T>
auto bound(T num, typename std::type_identity<T>::type low, typename std::type_identity<T>::type high) {
    return std::clamp(num, low, high);
}

auto bounded = bound(25.5, 20, 25);

При использовании зависимых имен(type - зависимое имя шаблонного класса type_identity) компилятор не вывод тип Т для аргументов. Он либо полагается на явное указание аргументов при инстанциации, либо на вывод типа из других параметров. В последнем сниппете только параметр num находится в контексте вывода и по нему компилятор выводит тип Т. Типы параметров low и high не зависят от того, какие соответствующие аргументы мы передаем при вызове функции. Они определяются выведенным типом первого аргумента.

В данном случае тип num выведется в double, поэтому и типы low и high тоже будут double. При вызове просто сработает неявное преобразование от int к double.

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

template<class T>
void foo(typename std::type_identity<T>::type arg) {}

foo<int>(42);  // T жёстко задаётся как int
// foo(42);    // Ошибка: вывод T невозможен!

Тоже самое для вариадиков:

template <typename... Ts>
void process(typename std::type_identity<std::tuple<Ts...>>::type data) {
}

process<int, double>(std::tuple{1, 2.0}); // OK
process(std::tuple{1, 2.0}); // ERROR, не указаны типы шаблонных параметров

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

Спасибо @d7d1cd за идею для поста)

Turn off deduction when it is not needed. Stay cool.

#template #cpp20

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

Благо есть свет в конце тоннеля, а точнее несколько звездочек на темном небе:

👉🏿 Канал Ильи Шишкова. ex-Яндекс, в настоящем СберТеховец, создатель, пожалуй, самых качественных курсов по С++ - "Пояса С++". На канале он рассказывает интересные кейсы с работы, как разрабатывает СУБД Pangolin, и как устроится в компанию мечты за толстую котлету.

👉🏿 Канал Ивана Ходора "this-notes". Работает в Яндекс Лавке, а на канале собирает дайджесты интересных экспертных статей по плюсам, хайлоаду и не только, да еще и с кратким обзором. Если лень самому искать инфу, то просто читайте статьи из его обзоров и уже преисполнитесь силушкой ITшной.

👉🏿 Ну а если хочется чуть больше углубиться в плюсы, получать подборки хороших лекции по С++, то вам в канал "Библиотека С++ разработчика".

Мы тут немного коллабимся и собрали все наши каналы в одной папке - https://t.me/addlist/jEIgjFluVUI0YjM6.

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

Make quality things. Stay cool.

​​Конфигурация и переменные окружения
#опытным

Любой серьезный сервис нуждается в конфигурации. Файлы конфигурации (JSON, YAML, INI) — популярный способ хранения настроек приложений. Так параметры можно хранить в репозитории, версионировать, да и просто удобно, когда все можно менять в одном месте и никак не менять команду запуска.

Однако не одними конфигами едины. Не всегда они подходят для решения определенных задач.

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

Не совсем. Что если какой-нибудь умник после тестирования приложения случайно закоммитит ключ в репозиторий? Это серьезная опасность: репозиторий вашей команды скорее всего может читать любой сотрудник, у которого есть доступ к вашей системе совместной разработки. А если у вас еще сторонние лица имеют доступ к репе... Не завидую вам. Безопасники будут радостно потирать ладоши, когда будут вам пистоны вставлять за эту ошибку. Потом еще ключ перевыпускать скомпрометированный, долго и мучительно заменять его... Сам наступал на эти грабли, приятного мало.

{
  "data_key": "qwerty123"  // Утечка при публикации кода!
}

Да и хранить ключ в открытом виде в файле на сервере такое себе. А если кто-нибудь подглядит?

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

# config.yml (попадает в Git)
db:
  host: db.example.com
  username: admin
  password: "P@ssw0rd123!"  # Утечка при публикации кода!

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

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

Переменные окружения можно установить видимыми только для конкретного запущенного docker контейнера:

docker run -e MY_VAR=value my_image

В k8s можно брать переменые окружения из отдельно развернутого и защищенного Vault. В этом случае вообще отсутсвует явное указание секрета:

env:
  - name: MY_VAR
  - value: vault:my_group/my_service#my_var

Переменные окружения не попадают в репозиторий -> нет компрометации секретов.

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

# Local
export DB_HOST=localhost

# Dev
export DB_HOST=dev-db.example.com

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

К чему это я и причем здесь С++?

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

Protect your secrets. Stay cool.

#goodpractice #tools

​​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