Грокаем C++

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

Как и в обычных функциях и методах класса, в виртуальных методах тоже можно определять параметры по-умолчанию. Однако, они могут вести себя не совсем так, как вы этого ожидаете. Спасибо, @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

📌 24 мая, System Level Meetup от YADRO, Санкт-Петербург и онлайн

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

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

Классные бонусы для офлайн-участников: демозона с «железом» YADRO для ЦОД и телеком-операторов, технические интерактивы и подарки от компании.

В программе:

— Константин Владимиров и Илья Андреев расскажут о девиртуализации в C++, её основных проблемах и о том, как компиляторы эти проблемы решают.

— Леонид Меркин расскажет, как благодаря программированию на C++ в российской аэрокосмической индустрии растёт надёжность mission-critical-IT-решений.

— Илья Шишков прочитает доклад «C++ внутри PostgreSQL: удобство против традиций» и поделится тем, как смог вплести C++ в строго C-шную кодовую базу и каких результатов добился.

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

📍Санкт-Петербург, Loft Hall, Арсенальная набережная, 1 или онлайн-трансляция.

Участие бесплатное, но нужна регистрация.

До встречи!

Квиз

Сегодня будет интересный #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.

Перегружаем шаблоны классов
#опытным

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

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

Но как и практически любое ограничение в С++, его можно хакнуть.

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

template <typename... T>
struct Foo;

template <typename T1>
struct Foo<T1> {};

template <typename T1, typename T2>
struct Foo<T1,T2> {};

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

Вот такие фокусы.

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

template <typename T, int N>
struct Foo<T, N> {}; // forbidden 

Но все равно это хороший инструмент, которым можно пользоваться.

Hack the boundaries. Stay cool.

#template #cppcore

Частичная специализация шаблонов функций
#опытным

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

Частичной специализации шаблонов функции не существует. И точка!

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

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

Безусловно, вы правы. Большинству разработчиков такие тонкости знать не нужно. Но мы ведь тут грокаем С++, у нас много постов про такие тонкости. Поэтому погнали.

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

void f(int) { std::cout << "int-overload" << std::endl; }; 
void f(int*){ std::cout << "int-p-overload" << std::endl; }

template<class T> void f(T) { std::cout << "T-overload" << std::endl; }; 
template<class T> void f(T*){ std::cout << "T-p-overload" << std::endl; }

Заметьте, что синтаксис одинаковый с точностью до появления template<class T> и замены конкретного типа на шаблонный параметр.

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

template<typename T>
class Foo {};

template<typename T>
class Foo<T*> {};

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

template <typename T1>
struct Foo<T1> {};
// Так нельзя делать, это несвязанные шаблоны
template <typename T1, typename T2>
struct Foo<T1,T2> {};

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

template<class T> void f(T) { std::cout << "T-overload" << std::endl; }; 
template<class T> void f(T*){ std::cout << "T-p-overload" << std::endl; }

template<class T> void f<T*>(T*){std::cout << "T-p-specialization" << std::endl;}

Ну и как компилятору выбирать между T-p-overload и T-p-specialization?

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

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

Don't be confused. Stay cool.

#template #cppcore

Частичная специализация шаблонов функций
#опытным

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

Частичной специализации шаблонов функции не существует. И точка!

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

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

Безусловно, вы правы. Большинству разработчиков такие тонкости знать не нужно. Но мы ведь тут грокаем С++, у нас много постов про такие тонкости. Поэтому погнали.

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

void f(int) { std::cout << "int-overload" << std::endl; }; 
void f(int*){ std::cout << "int-p-overload" << std::endl; }

template<class T> void f(T) { std::cout << "T-overload" << std::endl; }; 
template<class T> void f(T*){ std::cout << "T-p-overload" << std::endl; }

Заметьте, что синтаксис одинаковый с точностью до появления template<class T> и замены конкретного типа на шаблонный параметр.

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

template<typename T>
class Foo {};

template<typename T>
class Foo<T*> {};

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

template <typename T1>
struct Foo<T1> {};
// Так нельзя делать, это несвязанные шаблоны
template <typename T1, typename T2>
struct Foo<T1,T2> {};

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

template<class T> void f(T) { std::cout << "T-overload" << std::endl; }; 
template<class T> void f(T*){ std::cout << "T-p-overload" << std::endl; }

template<class T> void f<T*>(T*){std::cout << "T-p-specialization" << std::endl;}

Ну и как компилятору выбирать между T-p-overload и T-p-specialization?

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

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

Don't be confused. Stay cool.

#template #cppcore

Выгорание

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

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

Если это про вас, то загляните в канал Психолог взрослого человека - эксперта по выстраиванию гармоничных отношений с карьерой.

▪️ Как научиться отвлекаться от работы и отдыхать?
▪️ Как совместить кучу рабочих задач и время с семьей?
▪️ Как справиться с прокрастинацией?
▪️ Как не растерять запал, даже если начальник и коллеги 💩 и кажется, что ничего не выходит?

Знакомо? На эти и другие вопросы вам поможет найти ответы Вадим Петров, автор канала.

На одном коде жизнь не заканчивается. Подписывайтесь на канал @vadimpetrovpsi и снова работайте с горящими глазами и в балансе с личной жизнью!

👨🏻‍💻 Псс. Обязательно загляните в закреп канала - там вас ждут много полезных плюшек, и даже бесплатный мини-курс.

Особый день

Хоть весна нас особо не греет, сегодня очень важный и теплый для нашей страны праздник - День Победы.

К нему можно по-разному относиться, непростая ситуация сейчас в мире. Но, на наш взгляд, это не имеет значения.

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

Любой знаковый день - повод сделать что-то. Накидываем беспроигрышный вариант.

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

С праздником, дорогие подписчики! Благодарность свернет горы.

Tip your hat to your ancestors. Stay cool.

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

Представьте, что вам пришел какой-то запрос с 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