Евгений Шатунов

Как я понимаю через выше aligment тем лучше?

Нет. Это бред. Тут не применимы термины лучше/хуже.

Alignment (выравнивание) - это просто свойство типа данных.
enum по умолчанию имеет тип int, соответственно и все его свойства наследуются. В С++ (с версии 17, если не ошибоаюсь) можно самому выбрать тип enum. Для выравнивания обычно действует простое правило - тип должен быть выровнен в памяти на границу кратную его размеру. Например у int размер 4 байта (обычно), и выравнивание должно быть по границе 4 байт. у char/uint8_t - размер 1 байт, соответственно ограничений по выравниванию нет, т.е. выравнивание по границе байта. Тип SDL_Color - это, видимо, структура, состоящая из 4 uint8_t (или что там в SDL используют для unsigned char), выравнивание для структуры берется из типа ее первого поля (если аттрибутами не задано другое).
Используй типизированный в uint8_t enum и будет тебе счастье.
https://en.cppreference.com/w/cpp/language/enum

Кстати, выравнивание, это не ограничение С++ - это ограничение процессора на аппаратном уровне. Правда почти все современные процессоры уже не имеют этого ограничения и нормально жуют не выровненные типы, но при этом операции выполняют медленнее, чем с выровненными. Фактически процы просто научились "маскировать" это ограничение. Поэтому ограничение в языке осталось.
К тому же все еще есть процессоры, где требование выравнивания действует, но это в основном что-то из разряда микроконтроллеров. На таких процессорах использование не выровненных типов приводит к ошибке шины и вылету программы.
Обычно тебе не нужно думать про выравнивание, т.к. компилятор об этом позаботится за тебя. Но бывают ситуации, когда программист должен это учитывать. Например когда ты читаешь поток бинарных данных из сети или из файла, и данные в потоке - это что-то сложнее, чем байты и символы.

Это ассимптотическая сложность O(n log n). В ассимптотической сложности константа не имеет значения. И 2n, и 1000n - все одно O(n). При изменении основания логарифма у вас появится лишь константный множитель, который O() игнорирует, ведь log_а (n) = log_b(n) / log_b(a). Поэтому можно использовать вообще любой логарифм.

В компьютерной науке обычно используют логарифм по основанию 2. Потому что в алгоритмах вылезает именно деление на 2, а не на 10 и тем более не на e.

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

Вообще, у вас там разыменование нулевого указатяля, что есть UB и делать это категорически нельзя.

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

Вам лучше подойдут указатели.

Да, в общем-то русским (английским) по черному написано - data_process.c включает data_process.h, который первым определил функцию normalization().
А потом сам data_process.c определил функцию normalization() чуть пониже - ессно компилятор выдает замечание о переопределении, ибо оно есть :)

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

В вашем коде 2 проблемы. = default; можно писать, если у вас нет никакого списка инициализации. И константную ссылку нельзя использовать для инициализации неконстантной.

Вот такой код компилируется:

template<typename T>
struct Test
{
    T& ref;  // нужно присвоить null

    Test(T& _ref) : ref(_ref) {};
};

то в первом пункте мне не понятно как связаны индексы i и 2*i

Если нумерация массива идет с 1, то два ребенка элемента i будут 2*i и 2*i+1. У вас же нумерация с 0, т.ч. у вас дети - 2*i+1 и 2*i+2.

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

Похоже, проблема в том, что у вас нумерация с 0 и, если новый элемент оказывается итак максимальным, вы вернете индекс 0, вместо нужного 1. Если вы элемент вниз просеиваете, то у вас там +1 стоит в res.first, но изначально у вас-то там 0.

Далее, вы вектор неправильно используете. Вы делаете reserve и потом работаете с пустым вектором, как-будто он фиксированного размера. Вам надо делать resize вместо reserve. Или еще лучше, вместо вашей переменной size вы используйте arr.size(). При изменении размера массива делайте pop_back() и push_back().

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

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

Совет по бенчмарку - если памяти не хватает, стоит по одному достаточно большому массиву пройтись 10000 раз. А лучше использовать готовые фреймворки для измерения скорости, вроде того де gbenchmark.

Еще, иногда полезно посмотреть на ассемблерный выхлоп. Вот, например, что происходит при -O3 опции компилятора. Он генерирует вообще идентичный код для обеих функций (развернув циклы)! И даже при -O2 оно одинаковый код выдает.

Без оптимизаций код разный, но там все не так как вы думаете. Вместо инструкции mov eax, dword ptr [rax + 4*rcx] в варианте с индексами используется инструкция mov eax, dword ptr [rax] для указателей. Это самое "складывание с указателем массива" вообще не отдельная операция - а вариант адрессации в инструкции mov. Они могут вообще одинаковое количество тактов занимать, это надо мануал по конкретной архитектуре процессоров читать.

или по вкусу.. или оба! .. понимание различий даст быстрый рост многих пониманий ;)))
PS

Надо ли учить Си? Или может лучше начать с C#, а дальше уже выучу C++?

уже три разных языка.. мое мнение - если хватит азарта, учите все ;)))
.. и все внимание на различия областей применений и возможностей ;)))

Понять, что C и C++ - это два разных языка, и либо использовать C++, либо не использовать iostream.

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

Все правильно: выводится адрес элемента в массиве. Они два не совпадают, потому что в figure_collection лежит копия line, со своим уникальным адресом в памяти.

Edit: и вы через массив к исходному line никак не обратитесь, только если не смените тип массива на Figure*

Лучше так делать не надо. Это UB - нарушение всяких strict aliasing, выравниваия и вообще от порядка байт в машине зависит. Лучше руками собрать ULL по частям, вроде

for (int i = 0; i < 8; ++i) result |= byte_array[i+1] << (8ULL*i);

или

for (int i = 0; i < 8; ++i) result |= byte_array[i+1] << (8ULL*(7-i));

На худой конец, если очень узкое место, надо делать memcpy из массива в &result.

Проблема вызвана использованием шаблона rewrite из шаблона search.

Если вы перенесете специализацию шаблона rewrite вверх, до специализации search, то все скомпилируется. Или надо где-то выше первого использования шаблона rewrite задекларировать специализацию (что ваш закомментированный код и делает).

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

Specialization must be declared before the first use that would cause implicit instantiation, in every translation unit where such use occurs:

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

Но push_back не на порядок медленнее. В худшем случае в пару раз. И то и другое будет работать за O(n). Если у вас программа еще хоть что-то делает, кроме запихивания чисел в массив, то вы разницу особо и не заметите.

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

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

template <typename T>
auto search (std::string str) {
    // T - data type
    T res;
    // do something
    return res;
}

int main () {
    auto a = search<int>("a");
    auto b = search<std::string>("a");
}