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

Метапрогеры очень любят работать с компайл-тайм структурами, типа std::array, std::pair и std::tuple. Когда работают с такими структурами, то интересны прежде всего элементы этих структур. И очень хочется иногда как-то единообразно передавать их распакованные элементы куда-то в другую функцию.

Именно этим и занимается std::apply, которая появилась в С++17. По факту, эта такое дженерик решение для того, чтобы вызвать какую-то функцию с аргументами из элементов tuple-like объектов.

Простейшее, что можно с ней делать - вывести на экран все элементы тапла.

const std::tuple<int, char> tuple = std::make_tuple(5, 'a');
std::apply([](const auto&... elem)
{
  ((std::cout << elem << ' '), ..., (std::cout << std::endl));
}, tuple);

Здесь мы применяем fold-expression и оператор-запятая. Можете освежить знания в этом посте.

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

Может получится что-то такое:

template <typename T, typename = void>
struct is_tuple_like : std::false_type {};
template <typename T>
struct is_tuple_like<T, std::void_t<decltype(std::tuple_size<T>::value), decltype(std::get<0>(std::declval<T>()))>> : std::true_type {};
template <typename T>
constexpr bool is_tuple_like_v = is_tuple_like<T>::value;

template<typename Tval, typename ... T>
void serialize_tuple_like(std::stringstream &outbuf, const Tval& arg, const T& ... rest) noexcept {
  if constexpr (is_tuple_like_v<Tval>){
    outbuf << "{ ";
    std::apply([&outbuf](auto const&... packed_values) {
      serialize_tuple_like(outbuf, packed_values ...);
      }, arg);
    outbuf << " }";
  }
  else{
    outbuf << arg;
  }
  
  if constexpr(sizeof...(rest) > 0){
    outbuf << ' ';
    serialize_tuple_like(outbuf, rest ...);
  }
}

template<typename ... T>
std::string args_to_string(const T& ... args) noexcept {
  std::stringstream outbuf{};
  if constexpr(sizeof...(args) > 0){
    serialize_tuple_like(outbuf, args ...);
  }
  return outbuf.str();
}

int main(){
  std::cout << args_to_string("test", 1,
                std::tuple{"tuple1", 2, 3.0,
                  std::tuple{"tuple2", "boom"}},
                std::pair{"pair", 4},
                std::array{5, 6, 7, 8, 9});
}

Вывод будет такой:

test 1 { tuple1 2 3 { tuple2 boom } } { pair 4 } { 5 6 7 8 9 }

Даже не знаю, как эту лапшу разбирать. Идея такая что is_tuple_like_v проверяет аргумент на соответствие tuple-like объекту. Если нам на очередном вызове serialize_tuple_like попался такой объект, то мы берем и распаковываем его параметры в рекурсивный вызов serialize_tuple_like. Если у нас не tuple-like объект, то просто выводим его в стрим. Наверное, нужны проверки на то, что объект можно вывести в стрим, но решил, что это немного борщ для этого кода.

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

Don't live in metaverse. Stay cool.

#template #cpp17

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

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

Так вот чтобы голова не болела при работе с std::variant надо 2 раза в день после еды принимать std::visit.

Эта функция позволяет применять функтор к одному или нескольким объектам std::variant. И самое главное, что вам не нужно беспокоиться по поводу того, какой именно объект находится за личиной варианта. Компилятор все сам сделает.

template< class Visitor, class... Variants >  
constexpr visit( Visitor&& vis, Variants&&... vars );

template< class R, class Visitor, class... Variants >  
constexpr R visit( Visitor&& vis, Variants&&... vars );

Так выглядят ее сигнатуры. Первым параметром передаем функтор, дальше идут варианты.

Попробуем использовать эту функцию:

using var_t = std::variant<int, long, double, std::string>;

std::vector<var_t> vec = {10, 15l, 1.5, "hello"};

for (auto& v: vec)
{
  var_t w = std::visit([](auto&& arg) -> var_t { return arg + arg; }, v);
  std::visit([](auto&& arg){ std::cout << arg; }, w);
}
//OUTPUT:
// 20 30 3 hellohello

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

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

std::visit([](auto&&... arg){ ((std::cout << arg << " "), 
                               ..., 
                               (std::cout << std::endl)); }, vec[0], vec[1]);
std::visit([](auto&&... arg){ ((std::cout << arg << " "), 
                               ..., 
                               (std::cout << std::endl)); }, vec[0], vec[1], vec[2]);
// OUTPUT
// 10 15 
// 10 15 1.5

Используем здесь дженерик вариадик лямбду, чтобы она могла принимать столько аргументов, сколько нам нужно. И эта конструкция работает для любого количества переданных объектов std::variant;

Так что std::variant и std::visit - закадычные друзья и им друг без друга грустно! Не заставляйте их грустить.

Have a trustworthy helper. Stay cool.

#template #cpp17

​​Фикс баги с инициализацией инта

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

auto i = {0};

i будет иметь тип std::initializer_list<int>.

С++17 исправил такое поведение. Но для полного понимания мы должны определить два способа инициализации: копирующая и прямая. Приведу примеры

  auto x = foo();  // копирующая инициализация
  auto x{foo()};  // прямая инициализация, 
//                   проинициализирует initializer_list (до C++17)
  int x = foo();  // копирующая инициализация
  int x{foo()};  // прямая инициализация

Для прямой инициализации вводятся следующие правила:

• Если внутри скобок 1 элемент, то тип инициализируемого объекта - тип объекта в скобках.
• Если внутри скобок больше одного элемента, то тип инициализируемого объекта просто не может быть выведен.

Примеры:

auto x1 = { 1, 2 }; // decltype(x1) -  std::initializer_list<int> 
auto x2 = { 1, 2.0 }; // ошибка: тип не может быть выведен, 
//                      потому что внутри скобок объекты разных типов
auto x3{ 1, 2 }; // ошибка: не один элемент в скобках
auto x4 = { 3 }; // decltype(x4) - std::initializer_list<int>
auto x5{ 3 }; // decltype(x5) -  int

Этот фикс компиляторы реализовали задолго до того, как стандарт с++17 был окончательно утвержден. Поэтому даже с флагом -std=c++11 вы можете не увидеть некорректное поведение. Оно воспроизводится только на древних версиях. Можете убедиться тут.

Fix your flaws. Stay cool.

#cpp11 #cpp17 #compiler

​​Наследование? От лямбды? Ч1
#опытным

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

Как это вообще возможно?

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

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

Значит это вполне легальный кандидат на наследование!

Придется конечно немного поколдовать вокруг отсутствия имени, но для С++ это не проблема.

template<class Lambda>
struct DerivedFromLambda : public Lambda
{
  DerivedFromLambda(Lambda lambda) : Lambda(std::move(lambda)) {}
  using Lambda::operator();
};

int main(){
  auto lambda = []{return 42;};
  DerivedFromLambda child{lambda};
  std::cout << child() << std::endl;
}

// OUTPUT:
// 42

Ничего особенного. Мы просто создали класс-обертку над каким-то функциональным объектом и используем его оператор(), как свой.

Дальше создаем лямбду и создаем объект обертки, просто передавая лямбду в конструктор. Мы специально не указываем явно шаблонный параметр DerivedFromLambda, потому что мы не знаем настоящего имени лямбды. Мы даем возможность компилятору самому вывести нужный шаблонный тип на основании инициализатора. Это возможно благодаря фиче С++17 Class Template Argument Deduction.

Но даже и на С++11-14 можно написать подобное. Ведь у нас есть оператор decltype, который возвращает в точности тип того выражения, которое мы в него передали. Тогда мы бы создавали объект так:

auto lambda = []{return 42;};
DerivedFromLambda<decltype(lambda)> child{lambda};

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

Do surprising things. Stay cool.

#template #cppcore #cpp11 #cpp17

Наследование? От лямбды? Ч2
#опытным

Лямбды - это функциональные объекты по своей сути. Объекты классов с перегруженным оператором(). Зачем вообще от такой сущности наследоваться? Можно же просто сделать обычный класс с такими же перегруженным оператором и расширять его сколько влезет.

Ну как будто бы да. От одной лямбды наследоваться особо нет смысла. А что насчет множественного наследования?

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

Покажу чуть подробнее:

template<class Lambda1, class Lambda2>
struct DerivedFromLambdas : public Lambda1, Lambda2
{
DerivedFromLambdas(Lambda1 lambda1, Lambda2 lambda2)
  : Lambda1(std::move(lambda1))
  , Lambda2{std::move(lambda2)} {}
using Lambda1::operator();
using Lambda2::operator();
};

int main(){
  DerivedFromLambdas child{[](int i){return "takes int";}, [](double d){return "takes double";}};
  std::cout << child(42) << std::endl;
  std::cout << child(42.0) << std::endl;
  return 0;
}
// OUTPUT:
// takes int
// takes double

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

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

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

Have a sense. Stay cool.

#template #cppcore #cpp17

Наследование? От лямбды? Ч3

А давайте сделаем еще один шаг вперед. Зачем нам наследоваться от какого-то фиксированного количества лямбд? Не будем себя ничем ограничивать. Давайте наследоваться от произвольного количества!

template<typename ... Lambdas>
struct DerivedFromLambdas : Lambdas...
{
    DerivedFromLambdas(Lambdas&& ...lambdas) : Lambdas(std::forward<Lambdas>(lambdas))... {}
  
    using Lambdas::operator()...;
};

И что нам этот шаг дал?

Теперь мы можем благодаря variadic templates в компайл-тайме генерить структурки, которые включают произвольное количество различных вариантов вызвов оператора(). И слово "вариант" здесь неспроста.

Помните наш std::visit? Который применяет визитор к объекту варианта.

Так вот теперь мы можем налету делать наши визиторы!

template<typename ... Lambdas>
struct Visitor : Lambdas...
{
    Visitor(Lambdas&& ...lambdas) : Lambdas(std::forward<Lambdas>(lambdas))...
    {
    }
    using Lambdas::operator()...;
};

using var_t = std::variant<int, double, std::string>;

int main(){
    std::vector<var_t> vec = {10, 1.5, "hello"};  
    std::for_each(vec.begin(),
        vec.end(),
        [](const auto& v)
        {
            std::visit(Visitor{
                [](int arg) { std::cout << arg << ' '; },
                [](double arg) { std::cout << std::fixed << arg << ' '; },
                [](const std::string& arg) { std::cout << std::quoted(arg) << ' '; } }
            , v);
        });
}

Создаем вектор, который может содержать 3 типа. И не так уж просто обрабатывать элементы такого вектора. Но вооружившись std::visit и созданным налету нашим Visitor'ом мы играючи обошли все элементы и красиво вывели их на экран:

10 1.500000 "hello"

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

Но вообще, конкретно вот эта конструкция с наследованием от лямбд называется overload паттерн. Это стандартное и более короткое название для этого дизайн решения.

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

Visit your close ones. Stay cool.

#template #design #cpp17

Смешиваем std::visit и std::apply
#опытным

Подумал об интересном сочетании функций std::visit и std::apply. В прошлом посте про паттерн overload мы в цикле проходились по вектору вариантов и к каждому элементу применяли std::visit. Но прикольно было бы просто взять и за раз ко всем элементам коллекции применить std::visit. Ну как за раз. Без явного цикла.

И такую штуку можно сделать для tuple-like объектов, среди которых std::pair, std::tuple и std::array. Функция std::applyможет распаковать нам элементы этих коллекций и вызвать для них функцию, которая принимает в качестве аргументов все эти элементы по отдельности. Это же то, что нам нужно!

Давайте попробуем на примере std::array запихать все его элементы в функтор и лаконично вызвать std::visit.

template<typename ... Lambdas>
struct Visitor : Lambdas...
{
  Visitor(Lambdas... lambdas) : Lambdas(std::forward<Lambdas>(lambdas))... {}
  using Lambdas::operator()...;
};

using var_t = std::variant<int, double, std::string>;

int main(){
  std::array<var_t, 3> arr = {1.5, 42, "Hello"};
  Visitor vis{[](int arg) { std::cout << arg << ' '; },
        [](double arg) { std::cout << std::fixed << arg << ' '; },
        [](const std::string& arg) { std::cout << std::quoted(arg) << ' '; } };
  
  std::apply([&](auto&&... args){(std::visit(vis, std::forward<decltype(args)>(args)), ...);}, arr);
}

Начало в целом такое же, только теперь у нас std::array. Нам интересна последняя строчка.

В std::apply мы должны передать функтор, который может принимать любое количество параметров. Благо у нас есть вариадик лямбды, которые позволяют сделать именно это. Компилятор сам сгенерирует структуру, которая сможет принимать ровно столько аргументов, сколько элементов в массиве arr.

Дальше мы все эти аргументы распаковываем в серию вызовов std::visit так, чтобы каждый элемент массива передавался в отдельный std::visit. Естественно, все делаем по-красоте, с perfect forwarding и fold-expression на операторе запятая.

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

Выглядит клёво!

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

Look cool. Stay cool.

#template #cpp17

Когда мы вынуждены явно использовать new
#опытным

Сырые указатели - фуфуфу, бееее. Это не вкусно, мы такое не едим. new expression возвращает сырой указатель на объект. Соотвественно, мы должны максимально избегать явного использования new. У нас все-таки умные указатели и функции std::make_* довольно давно завезли.

Однако все-таки есть кейсы, когда мы просто вынуждены использовать new явно:

👉🏿 std::make_unique не может в кастомные делитеры. Если хотите создать уникальный указатель со своим удалителем - придется использовать new.

auto ptr = std::unique_ptr<int, void()(int*)>(new int(42), [](int* p) {
    delete p;
    std::cout << "Custom deleter called!\n";
});

👉🏿 Приватный конструктор у класса. Странно вообще пытаться создать объект такого класса, но не торопитесь. Приватный конструктор может быть нужен, чтобы оставить только один легальный способ создания объекта - фабричную функцию Create. Она возвращает уникальный указатель на объект и обычно является статическим членом класса. Функция Create имеет доступ к приватным методам, поэтому может вызвать конструктор. Но вот std::make_unique ничего не знает о приватных методах класса и не сможет создать объект. Придется использовать new.

struct Class {
  static std::unique_ptr<Class> Create() {
    // return std::make_unique<Class>(); // It will fail.
    return std::unique_ptr<Class>(new Class);
  }
private:
  Class() {}
};

👉🏿 Жизнь без 20-го стандарта. До 20-го стандарта вы не могли создать объект POD класса без указания фигурных скобок. Но именно так и делает std::make_unique.

То есть вот так нельзя делать в С++17:

struct MyStruct {
  int a, b, c;
};
auto ptr = std::make_unique<MyStruct>(1, 2, 3); // Will fail C++17
auto ptr = std::unique_ptr<MyStruct>(new MyStruct{1, 2, 3}); // Norm

Но можно в С++20. Так что тем, кто необновился, придется использовать new.

В целом, все. Если что забыл - накидайте в комменты.

Но помимо этого, администрация этого канала не рекомендует в домашних и рабочих условиях явно вызывать new. Это может привести к потери конечности(отстрелу ноги).

Stay safe. Stay cool.

#cppcore #memory #cpp20 #cpp17

Тип возвращаемого значения тернарного оператора
#опытным

Представьте, что вам пришел какой-то запрос с json'ом и вам его нужно переложить в плюсовую структуру и дальше как-то ее обрабатывать. В джейсоне записаны какие-то персональные данные человека, но они не всегда присутствуют в полном составе. Давайте посмотрим на структуру, чтобы было понятнее:

struct PersonalData {
    std::string name;
    std::string surname;
    std::string patronymic;
    std::optional<std::string> address;
    std::optional<std::string> email;
    std::optional<std::string> phone;
};

Пусть мы обрабатываем какие-то анкетные данные или что-то в таком духе. И человеку обязательно указать свои ФИО, но адрес, эл. почту и телефон - не обязательно.

Берем джейсон и перекладываем(то есть занимаемся тем, чему 6 лет учат в тех вузах):

PersonalData person{
    .name = json["name"],
    .surname = json["surname"],
    .patronymic = json["patronymic"],
    .address = json.HasMember("address") ? json["address"] : std::nullopt,
    .email = json.HasMember("email") ? json["email"] : std::nullopt,
    .phone = json.HasMember("phone") ? json["phone"] : std::nullopt};

Просто, чтобы кучу if'ов не плодить, воспользуемся тернарным оператом. Если в json'е есть данное поле, то инициализируем опциональное поле им, если нет, то std::nullopt'ом.

Ничего криминального не сделали. Вдобавок использовали designated initialization из с++20.

Компилируем ииииииии..... Ошибка компиляции.

Пишет, что тернарный оператор не может возвращать разные типы.

Дело в том, что std::nullopt - это константа типа nullopt_t. А поле джейсона имеет тип строки. Конечно, из обоих типов можно сконструировать объект std::optional. Но тернарный оператор не знает, что мы хотим. Ему просто не разрешается возвращать разные типы.

Но почему? Это же так удобно.

С++ - это не всегда про удобство)

Представьте себе шаблонную функцию, возвращаемый тип которой выводит сам компилятор. Условно - try_stoi. Если строка может быть преобразована в int, то возвращаем число, если нет - то возвращаем нетронутую строку.

auto try_stoi(const std::string& potential_num) {
  if (can_be_converted_to_int(potential_num)) {
      return std::stoi(potential_num);
  } else {
      return potential_num;
  }
}

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

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

Придется явно оборачивать все в std::optional:

PersonalData person{
    .name = json["name"],
    .surname = json["surname"],
    .patronymic = json["patronymic"],
    .address = json.HasMember("address") ? std::optional(json["address"]) : std::nullopt,
    .email = json.HasMember("email") ? std::optional(json["email"]) : std::nullopt,
    .phone = json.HasMember("phone") ? std::optional(json["phone"]) : std::nullopt};

Это немного снижает читаемость и привносит кучу повторения кода, но имеем, что имеем.

Be flexible. Stay cool.

#cppcore #cpp17 #cpp20

​​Что будет если бросить исключение в деструкторе? Ходим по тонкому льду.
#опытным

Но что же делать, если у вас есть безудержное желание бросить исключение в деструкторе? Возможно ли это как-то безопасно сделать?

На самом деле есть один вариант. Вряд ли вам хочется прям явно написать "throw" в деструкторе. Думаю, что на самом деле вы хотите использовать в деструкторе функцию, которая потенциально может бросить исключение:

constexpr std::string_view defaultSymlinkPath = "/system/logs/log.txt";

class Logger
{
  std::string   m_fileName;
  std::ofstream m_fileStream;
  
  Logger(const char *filename)
    : m_fileName { filename }
    , m_fileStream { m_fileName }
    {}
  
  void Log(std::string_view);
  
  ~Logger() noexcept(false)
  {
    fileStream.close();
    std::filesystem::create_symlink(m_fileName, defaultSymlinkPath);
  }
};

Логгер может писать в файл с нестандартным именем, но хочет в деструкторе сделать симлинк на него в системной директории /system/logs/log.txt.

Одна проблема - std::filesystem::create_symlink может кинуть исключение, если например прав доступа к директории нет.

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

И такой инструмент есть, называется он std::uncaught_exception(). Это функция проверяет, есть ли сейчас живой объект исключения и исполнение еще не дошло до блока catch. То есть программа находится в режима разворачивания стека. И можно на основе этого знания какую-то логику строить.

Например, не создавать симлинк в логгере, если есть живой объект исключений:

~Logger()
{
  fileStream.close();
  if (!std::uncaught_exception())
  {
    std::filesystem::create_symlink(m_fileName, defaultSymlinkPath);
  }
}

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

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

И std::uncaught_exception() позволяет динамически изменять поведение программы, если вы уже попали в исключительную ситуацию.

Однако в C++17 эта функция призвана устаревшей и была удалена в C++20. В следующий раз посмотрим, почему так и что пришло ей на замену.

Walk on a thin ice. Stay cool.

#cpp17 #cpp20