res2001

Для того, чтобы использовать в main.c функцию, определенную в math_functions.c, вам надо иметь ее объявление в main.c

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

Можно просто в main.c написать то, что вы бы написали в math_functions.h. Но это быстро становится сложно, если у вас проект большой и функции используются в разных файлах. Надо будет эти объявления копировать в кучу мест. А если вам еще и поменять что-то надо потом, вы офигеете. Для этого и придумали заголовочные файлы - вы пишите объявление один раз и потом его везде используете.

Вообще, сейчас не обязательно math_functions.h включать и в math_functions.c. Раньше надо было определять функцию даже если ее объявления нигде нет. В современных стандартах это не так. Но все равно хедеры включают в соответствующий файл, чтобы ловить ошибки. Если вы поменяете функцию в .c но не поменяете в хедере, компилятор заметит несоответствие объявления и определения и сообщит об ошибке.

Хедеры служат, чтобы два c-файла — они называются «единицы трансляции» — компилировались по отдельности. Это основное назначение той разновидности include-файлов, которые называются хедерами.

Можно в h-файлы посадить и тела функций, только убедиться, что каждое тело ровно в одной единице трансляции — есть такой подход под названием «одна единица трансляции», и он существует у больших редко перекомпилируемых библиотек, чтобы перекомпиляция была покороче.

Подключение main.c←math_functions.h служит, чтобы сказать компилятору: а где-то в другом месте есть эти функции.

Подключение math_functions.c←math_functions.h — частично для подключения прочего общего вроде типов, частично для проверки на ошибки. Дело в том, что Си традиционно не козявит (does not mangle) имена функций, и если в хедере sin(int), а в реализации sin(double) — будут трудноуловимые ошибки.

Да, деление на единицы компиляции решает и другую задачу — декомпизицию программы на меньшие элементы, и есть противоречие одного с другим (особенно в языке Си++, где хедеры огромны)

В хедере находится только то, что не производит кода. Если говорить про Си++, то…
• inline-объекты (код производят вызовы объекта)
• определения типов, функций и прочего; extern-определения переменных (код производят тела функций и окончательные определения переменных)
• шаблоны, если те нужны более чем в одной единице компиляции (код производит специализация)
Но полные специализации шаблонов производят код и находятся в cpp-файле!

Как оказалось не учел соглашение о вызовах.
__cdecl: очищает стек после каждого вызова (add esp, X)
__stdcall: очищает стек внутри функции(retn X)

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

typedef int (__stdcall *crsGetStringType)(void *, int, char *Destination, int Count);

На Ассемблере проще писать, чем на С++ с учетом кучи тонкостей..

У вас проблемы в каждой команде.

git commit -m "hw-EDU-9336"
...
nothing to commit...

— коммитить было нечего и коммит не создался. Но это не мешает делать push.



Совет: в любой непонятной ситуации смотрите git status. Смотрите его как до команд, так и после.

git push
... The current branch ... has no upstream branch

Здесь Git говорит, что текущая ветка не имеет связи ни с какой вышестоящей веткой. Git понятия не имеет, куда вы хотите пушить и что пушить.
В общем случае команда выглядит примерно так:
git push <репо_куда_пушить> <какую_ветку_пушить>

Обычно при первой отправке мы просим гит создать связь локальной и вышестоящей веток.
Гит подсказывает вам, как это сделать:

git push --set-upstream origin hw-EDU-9336-sprint-1

но можно написать проще, чтобы не мучиться запоминанием длинных названий:
git push -b origin HEAD
HEAD это синоним текущей ветки.

Дальше у вас реальная ошибка. Скорее всего проблема в авторизации.

Проверьте, что ключ действительно стучится в GitLab
ssh -T git@gitlab.quality-academy.ru
Успешный вариант: GitLab поздоровается и скажет, что логин найден.
Неуспешный: "Permission denied (publickey)".

И главное — публичный ключ должен быть добавлен в GitLab:
User Settings → SSH Keys
Если после этого Git продолжает упираться — значит просто нет прав на запись в репозиторий, а не проблема с ключами.

Почему в ethtool не выводится информация о партнёре?

Не реализовано в драйвере. Информация о том, что предложил link partner берётся из поля lp_advertising структуры ethtool_cmd, см. Функция igb_get_link_ksettings это поле не заполняет, см. Вот пример функции, которая заполняет, см.

arrOne и arrTwo - это переменные, типов int[5] и int[3][2]. Это на уровне C. Под капотом там указатели: компилятор знает адрес начала массива. Путаницу может вызвать то, что массивы в языке C тождественны указателям на начало с той лишь разницей, что компилятор знает его длину и всякие sizeof() сработают правильно.
Соответственно, arrOne неявно приводится к int*, а arrTwo к int (*)[2] (указатель на массив из 2 элементов, что в свою очередь неявно приводиться к указателю на указатель на инт).

Поэтому работает код:

int a[3][2];
   int (*b)[2];
   b = a;

Можно считать, что arrOne - указатель на первый элемент int, а arrTwo - указатель на первую строку int[2], по совместительству на первый элемент в первой строке:

int x = *arrOne;
   int y = **arrTwo; // с одной * не сработает ибо int[2], оно же int* к int не приводиться.
   int *z = arrOne+2; // указатель на 3-ий элемент
   int *w = arrTwo + 1; // указатель на вторую строку (первый элемент в ней).

Но лучше на закапываться в адрессную арифметику, а воспринимать массивы, как свой отдельный тип данных. Не пишите arrOne+1, а пишите arrOne[1] и не парьтесь.

Даже для int переменных компилятор знает их адрес, так что там под капотом тоже есть указатель. Не очень большая разница.

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

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

В целом, в С++ хорошее правило - передавать большие переменные как const &.

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

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

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

С чего вы взяли, что переполняется память? Если диспетчер задач пишет о всего-то 20мб?

Потребляет ли много памяти какой-то другой процесс?

Возможно там утечка каких-то ресурсов, вроде хендлов.

Каким-нибудь process explorer можно посмотреть сколько хендлов ваша программа имеет, если это число растет, надо разбираться, какие из виндовых объектов вы правильно не уничтожаете. Вроде бы все битмапы вы корректно уничтожаете через DeleteObject, возможно ошибка в другом коде.

Можно еще поробовать вашу программу подебажить. Вот когда окно вылезает, какой ваш код выполняется? Подключитесь к вашему процессу visual studio и смотрите. Или добавьте отладочный вывод, чтобы понять, какая функция начинает выполнятся но не заканчивает. Это подскажет вам, какие объекты вы не удалили правильно.

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

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

Можно сделать указатель на const. Вот этот ваш const, он относится к самому указателю, его нельзя менять (в смысле, на другой адрес). Но после разыменовывания получается не константная ссылка. Вот оно в документации:

typename std::add_lvalue_reference<T>::type operator*() const

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

Так что если вы хотите запретить менять объект, то можно сделать так:

void foo(const std::unique_ptr<const int>& ptr) {
    if (ptr) {
        *ptr += 5; // Ошибка компиляции.
        std::cout << *ptr;
    }
}

int main() {
    std::unique_ptr<const int> ptr = std::make_unique<const int>(5);
    foo(ptr);
}

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

Но вообще, обычно нет смысла передавать unique_ptr по ссылке. Можно передать по ссылке сам объект, все равно владение в функцию не передается же. И уже там можно навешивать const, если надо. Или, если передавать просто unique_ptr, без ссылки, то даже лишнего кода не надо для обработки const:

void foo(const std::unique_ptr<const int> ptr) {
}

int main() {
    std::unique_ptr<int> ptr = std::make_unique<int>(5);
    foo(std::move(ptr));
}

То, что вы описали в комментариях, это буквально блокировка чтения-записи. Функтор читает данные и может выполнятся параллельно несколько раз, но запись может быть только одна и она блокирует все чтения. Решение описано в википедии: 2 мьютекса, один счетчик. Атомиков не надо.