#cpp

Инициализация 1/2.

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

Первый пример:

int i;
return i; // ub

struct S {
int x;
};
S s;
return s.x; // ub

Это default initialisation, что вообще-то немного путает, потому что переменная у вас не инициализируется ничем дефолтным (мусор я бы дефолтным не назвал). Можно поправить так:

S() : x(0) {}

Это member initialiser list. Не оч удобно, потому что надо повторять во всех конструкторах, потому в C++11 появился

struct S {
int x = 0; // default member initialiser
};

Наверное использовать dmi может быть хорошим советом, пусть и не лишённым проблем.
Далее:

int i = 2; // copy initialisation

Такой же способ инициализации используется, когда вы передаёте аргумент в функцию по значению или по значению возвращаете. Если тип инициализируемого объекта и значения справа от = не совпадают, будет произведена некоторая цепочка преобразований типов (насколько я понимаю, сколько угодно стандартных преобразований и может быть одно пользовательское, всё это в произвольном порядке, конечно).
Помните, что copy init это никогда не operator=.

Aggregate init:

int i[3] = {1, 2, 3};
int i[] = {1, 2, 3};

struct S { int x; int y; };
auto s{1, 2};

Агрегатная инициализация будет copy-инициализировать каждый из переданных аргументов. У такого init есть фича:

struct S { int x; int y; };
S s = {1};
return s.y; // какое значение? ub?

Если вы опускаете часть аргументов при использовании агрегатной инициализации, остальные будут zero initialisated. Т.е. у вас никогда при таком способе не будет неинициализированных данных. Потому и работает вот такой способ заполнения массивов нулями:

int a[10] = {};

Ещё тут есть такая фича как brace elision.

Далее static initialisation:

static int i = 1; // constant initialisation
static int j; // zero initialisation

Все эти способы были просто унаследованы плюсами от C. Теперь про плюсовые.

Direct initialisations (whenever the initialiser is an argument list in parens):

S s(1, 2); // constructor
int i(3); // also for built-in type

Для built-in типов никакой разницы от copy init, но для остальных это возможность передать более одного аргумента при инициализации и отсутствие цепочки преобразований (просто вызов конструктора по всем правилам перегрузок). Тут стоит быть осторожным:

struct S {
explicit S(int) {}
S(double) {}
};
S s1 = 1; // S(double)
S s2(2); // S(int)

Value init (whenever the initialiser is a pair of empty parens):

int f() { return int(); }

Если есть пользовательский default ctor, то вызовется он, иначе zero init. Тут можно словить всякие маслины. Осторожно.

Uniform init — способ универсальной инициализации из C++11 (с помощью {}). Тут же появились list inits:

S s{1, 2}; // direct list init
S s = {1, 2}; // copy list init

И тут же появился std::initializer_list. Думаю, как им пользоваться вы знаете, так что опустим. Про его проблемы можно глянуть тут.
Для агрегатов list init это agregate init. Для built-in типов пример выше. Для классов либо вызов подходящего конструктора, либо direct/copy init.
{} — особый случай. Это дефолтный ктор, иначе ктор от initializer_list, иначе value init ☺️🎧
При list init никаких narrowing conversions не происходит, так что int i{1.0} не закатит.

Ну и опуская всякое неинтересное, не забудем про C++20 designated initialisation:

struct S { int x; int y; };
S s{.x = 1, .y = 2};

Подробнее со всякими интересными примерами можете посмотреть в доклад Тимура Думлера.

Тут мы упомянули даже не всё что на гифке. А на гифке тоже пары штук не хватает🙂

#cpp

Инициализация 2/2.

Непонятно что делать с этой инфой. Давайте посмотрим на пару примеров, которые помогут сделать выводы. Самый простой:

int m();

Вот я хочу инициализировать переменную m по месту. Но, учитывая most vexing parse, это у вас не переменная, а объявление функции. Всё сломалось. Или гораздо более стрёмный кейс:

vector<int> v(istream_iterator<int>(cin), istream_iterator<int>());

Fuck. Это тоже объявление функции (оно скомпилируется и вы получите ошибку в совсем другом месте!). Оставим разбор этого выражения читателю.

Из забавного (если конечно больно можно считать за смешно) следующие кейсы:

int i(1, 2);
int i = (1, 2);
int i = int(1, 2);
auto i(1, 2);
auto i = (1, 2);
auto i = int(7, 9);

Будет ли первое компилироваться? Конечно же нет. Наверное тогда и второе? Ошибка. Второе это оператор запятая, потому всё корректно. Третье, четвёртое и шестое (по аналогии с 3м), очевидно 🎧, тоже CE. Пятое по аналогии со вторым OK.

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

Из интересного ещё следующий момент. В C++11 следующая запись означала std::initializer_list<int>{1}:

auto i{1};

Однако в C++14 семантику подобного изменили, где это стало int{1}.

auto i = {1};

А что же тут? Это без сомнений init_list. Т.е. вы меняете тип объекта при инициализации с помощью =. Конечно интуитивно это вроде понятно, но кринж🥴, не правда ли? Говорят, что семантику такого поправлять не будут. Может просто запретят что-то такое делать в будущем (или нет, who knows). Мб потому стоит ещё и отказаться от инициализации с помощью =. Просто на всякий случай.
Хотя есть аргумент за такой стиль. У вас будет одинаковый способ “инициализации” переменных и типов:

auto x = …;
using T = …;

Для типов тогда лучше явно указывайте тип: auto i = int{1} (это всё мысли из AAA от Herb Sutter). В защиту такого подхода приводится поинт, что вы не забудете инициализировать вашу переменную. Хотя и тут есть траблы:

std::string x = “1”;
auto x = “1”s; // C++14

Вот эту s в конце (литерал) очень легко забыть/не обратить на неё внимания.
Ещё можно заметить, что такой способ работает (работал*) только для movable/copyable типов, иначе CE:

auto a = std::atomic<int>{9}; // CE before C++17

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

Чисто из опыта совет: помните, что значит первая буква в AAA — Almost. Потому что иногда поиск типа переменной становится неприятным муторным занятием, попросту тратящим время.

Ещё классический момент это инициализация вектора:

std::vector<int> v(3, 1); // 1 1 1
std::vector<int> v{3, 1}; // 3 1

Ну тут всё понятно. Не будем обсуждать.

В докладе Nicolai Josuttis можно посмотреть про это всё счастье подробнее. Там ещё много маслин словить можно.

#common

Базово про кодировки.

Очень важно различать два основных понятия: текст и его представление в виде байт. Есть две основные операции перевода из одной сущности в другую: из текста в байты с помощью какой-то кодировки (обычно называется encode), и наоборот (decode).

Собственно кодировка это способ/правило/функция отображения текста в байты и наоборот.

Одной из первых адекватных кодировок стала ASCII. Она в соответствие каждому символу ставит семибитовый код (т.е. хранится 128 символов). 32 символа - управляющие, остальные - стандартные английские буквы, цифры, знаки препинания и т.д. 8й бит использовался для контроля ошибок. Позже она была расширена до 256 символов (задействованы все 8 битов). Однако уже успели появиться другие однобайтовые кодировки, которые расширяли изначальные 128 символов. Например KOI-8 — кириллическая кодировка, имеющая интересную особенность: в случае, если используемый редактор не поддерживает эту кодировку, при преобразовании кириллических символов в ASCII получался транслит; соответственно русские буквы шли не по алфавиту. Или CP866 — кодировка, используемая в MSDOS, — и CP1251 — дефолтная кодировка при использовании кириллицы в windows до windows 10.

Со временем 256 символов конечно же перестало хватать. И наличие различных кодировок не является универсальным решением. Потому родился Unicode. Он также является отображением из кода в символ, только размеры чуть больше: 2^21 символов.

Unicode реализуют несколько основных кодировок:
- UTF-32. Каждый символ занимает ровно 4 байта. С ней легче всего работать, но она занимает больше всего памяти из-за фиксированного размера.
- UTF-16. Каждый символ представлен либо 2, либо 4 байтами.
- UTF-8. Символ кодируется 1, 2, 3 или 4 байтами. ASCII-часть кодируется одним байтом, причём коды символов полностью совпадают.

Устройство UTF-8 (наиболее популярная из вышеназванных).

Если говорить об ASCII-символе, то в начале идёт 0, а потом 7 бит символа.
Если символ не ASCII, тогда нужно понять, сколько байт нужно для представления символа. Для этого в самом первом байте вместо нуля пишется некоторое количество единиц. Это количество и указывает на то, сколько байт занимает символ. Т.е. если он занимает 3 байта, то пишется 111, после чего [что логично] идёт 0. Далее идут уже значащие для кода биты. Каждый последующий байт начинается с 10, после чего идут 6 значащих битов.
Зачем нужна такая избыточность 🤔 ?
При разработке кодировки требовалось сохранить обратную совместимость с уже большой кодовой базой, написаной на C, в котором нулевой символ является знаком окончания строки. Как видим, нулевой символ в UTF-8 только один. Ещё тут выполняется такое свойство, что ни один символ не является префиксом другого, что позволяет использовать некоторый набор старых функций, работающих с ASCII с UTF-8 (например поиск подстроки в строке).

Собственно если посчитать, сколько символов мы можем задать подобным образом, получится что-то около 2^21.

Вот хорошая статья про это всё.

#cpp

Чуть-чуть из доклада Daisy Hollman (не путать с Nadin Holman) на CppCon 2022 (прошлый я упоминал тут).

Fun fact. Можно скрыть общий шаблон с помощью constraint’ов:

template <class T>
struct B {
void print() { cout << “unreachable”; }
};

template <> requires true
struct B<T> {
void print() { cout << “new default”; }
};

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

Правда если вы потом захотите сделать ещё одну специализацию:

template <class T> requires std::integral<T>
struct B<T> {
void print() { cout << “integral”; }
};

то для условного int получится неоднозначность, потому что по факту это выбор между двумя requires true. Но это можно обойти объявлением всегда истинного концепта:

template <class T> concept True = true;

И поменять сигнатуры на

template <class T> requires True<T>
// и
template <class T> requires std::integral<T> && True<T>

Это какие-то жоские преки. Словно про поломанность std::void_t вспомнил.

Второй fun fact (ну это конечно чуваки крутят-вертят как хотят уже).
Помним можно писать user-defined literal templates:

template <char… Chars>
constexpr auto operator “”_i();

И использовать их можно вот даже для чисел:

auto x = 123_i;

Компилятор распарсит 123 в три символа и внутри оператора можете творить что хотите.
Собственно на этом и построена возможность обращаться к элементу тупла через operator[]:

template <size_t I> struct index {};

// преобразовываем литерал в число
template <char… Chars>
constexpr auto operator “”_i () {
return index<[]{
size_t rv = 0;
for (auto c : {Chars…})
rv = rv * 10 + (c - ‘0’);
}()>{};
}

template <class… Ts>
struct index_tuple : std::tuple<Ts…> {
using std::tuple<Ts…>::tuple;

template <size_t I>
auto operator[](index<I>) {
return std::get<I>(*this);
}
};

auto t = index_tuple<int, double>{1, 2.2};
cout << t[1_i];

Ну и всё. Файная обёртка над std::get готова😁
Но помните, что это работает только для литералов.

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

#common

Про ревью.

Что вы думаете, когда видите что-то такое:

> Это какой-то бред.

Оценочное суждение. Никакой конкретики, что же сделано не так. Никаких предложений по исправлению.

> Так лучше не делать.

Как??????????

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

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

Как сделать ваше ревью более полезным? Вот несколько набросов:
- цель код ревью в том, чтобы сделать код лучше. Потому при написании комментариев важно фокусироваться именно на коде и написанном, а не на авторе и других аспектах бытия;
- пишите конкретно.
Вот это не будет работать по таким-то причинам: раз, два, три. Можно сделать вот так. Вот ссылка на пример использования/функцию/метод/инструмент.
Донесите вашу мысль максимально чётко, чтобы автор кода понял вас с первого раза;
- не ленитесь и напишите (псевдо)код предлагаемого решения, если оно может показаться нетривиальным.
Вообще максимально старайтесь предлагать какие-то решения (вы же понимаете, как сделать лучше?). Это экономит время;
- по опыту, важно ещё и как вы оставляете комментарий. Если вы предлагаете что-то исправить в формулировке “Можем сделать ….?”, автор имеет полное право сказать “нет”, даже если это решаемый вопрос. Просто потому что не хочет. Напишите лучше что-то вроде “Давай сделаем …”;
- ну и в конце концов, будьте приятными и нетоксичными. Просто по-человечески добрыми. Это всегда приятно. Плюс к фидбеку охотнее прислушиваются, если он написан уважительно.

Будьте добрыми😎