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

Да, в общем-то русским (английским) по черному написано - 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");
}

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

Достаточно предположить, что функция fopen_s внезапно не сможет открыть файл и вернёт ошибку. Допустим, файла не существует, или на его открытие нет прав у пользователя. Ты же не проверяешь возврат результата из функции открытия и пытаешься что-то записать в F, даже если функция не смогла открыть файл и вернула ошибку. А когда она вернёт её, переменная F останется нулевыем указателем или, в первом твоём случае, вообще будет обращение к неинициализированной переменной, где ты получишь неопределённое поведение. Вот оно и ругается на эту ветку развития событий.

Добавь проверки на возвращаемые значения функций, и предупреждение пропадёт.

Для решения этой проблемы по уму надо написать вот это в определении производного класса:

using Array<T>::_size;
using Array<T>::_capasity;
using Array<T>::_data;

Ответ на вопрос "почему" в С++ всегда один: "потому что стандарт":

Non-dependent names are looked up and bound at the point of template definition. This binding holds even if at the point of template instantiation there is a better match:

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

Надо как-то компилятору указать, где искать вот эти ваши _size и т.д.
Например, через this-> или через using или через Array<T>::.

Вообще от этих правил lookup-а в C++ волосы дыбом встают и куча приколов вылезает. Их надо только запомнить. Оно неинтуитивно, но таково оно есть.

С чего вы взяли, что внутри шаблона это работет? Вы его инстанциировать пробовали (объявить переменную класса Outer<int>, например)?

Вылезает точно такая же ошибка.

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