Alexander Movchan

Её нет.

float *k = new float[polynomsize];

Вы переопределили k и присваиваете локальному указателю, а не полю.

Как вам уже ответили в комментарии, вы просто не указали параметр для -o.
cc -o tr main_0.o main_1.o

Вообще, никогда не нужно использовать абсолютные пути в Makefile.
И ещё, если вы поменяете свой header.h, то make об этом не узнает.
У компиляторов есть специальные опции, чтобы сгенерировать зависимости .c файлов от заголовков.
Вот вам универсальный Makefile для простых проектов:

PROJECT = tr
SOURCES = main_0.c main_1.c
OBJECTS = $(SOURCES:.c=.o)
HEADER_DEPS = $(SOURCES:.c=.d)

.PHONY: all

all: $(PROJECT)

$(PROJECT): $(OBJECTS)
	$(CC) $(CFLAGS) $^ -o $@

-include $(HEADER_DEPS)

%.o: %.c
	$(CC) $(CFLAGS) -MM -MT $@ -MF $(patsubst %.o,%.d,$@) $<
	$(CC) $(CFLAGS) -c $< -o $@

.PHONY: clean

clean:
	$(RM) $(PROJECT) $(OBJECTS) $(HEADER_DEPS)

Библиотеки обычно устанавливают в /usr/lib/, /usr/local/lib и их подпапки. Обычно эти пути и так находятся в LD_PATH, так что достаточно указать -l<libname>.

Так же библиотеки часто устанавливаются вместе с pkg-config конфигурацией, так что можно использовать его так:

gcc -c file.c `pkg-config --cflags <libname>`
gcc file.o -o file `pkg-config --libs <libname>`

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

Для C/C++ де-факто стандрата сборки нет, но есть несколько систем сборки, которые обычно используються:

make - очень простая утилита, но неудобно для больших проектов.
Можно определить по наличию файла Makefile. Иногда этот файл генерируеться скриптом configure.
Если есть Makefile, запускаем:
$ make
Удалить сгенерированные файлы (чтобы запустить сборку заново):
$ make clean

cmake- более высокоуровневая система сборки, генерирует проекты для IDE или те же Makefile.
Можно определить по наличию CMakeLists.txt

mkdir cmake-build
# Создаём папку для сгенерированных файлов, чтобы не смешивались с исходниками
# Это называеться out-of-source build
cd cmake-build

# Генерируем проект или Makefile
cmake ..

# Запускаем билд, можно просто запустить make
cmake --build .

qmake - система сборки разработаная для сборки Qt и проектов использующих Qt.
Можно определить по наличию .pro файлов. Билдим так:

qmake
make

В вашем случае используеться make.

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

#include <iostream>
#include <functional>

template <typename T>
class defer {
private:
    std::function<T()> mFunctor;
public:
    defer(std::function<T()> functor) : mFunctor(functor) {}
    ~defer() { mFunctor(); }
};

int main() {
    defer<void> d([] { std::cout << "Deferred func!" << std::endl; });
    //...
    
    std::cout << "Hello, world!" << std::endl;
    
    if (true) {
        return 0;
    }
    //...
    if (false){
        return 1;
    }
    
    return 0;
}

Qt - не среда разработки, а фреймворк. Среды разработки это QtCreator, CLion, Visual Studio. Все они позволяют работать с Qt.
Кроме Qt можете посмотреть на GTK+ (gtkmm), wxWidgets.

Перед инициализацией GLEW нужно создать контекст OpenGL.

Обычно разделяют сессии и авторизацию:

Сессия. Чтобы реализовать сессии сервер при первом соединении с клиентом может генерировать некоторый случайный токен и устанавливать его в куки. Тут важно, что куки должны передаваться по защищённому каналу (HTTPS). Таким образом можно сохранять некоторую информацию о сессии в базе данных или же в самих куки, но тогда нужно подписывать куки, чтобы пользователь не мог их изменять.
В любом случае, сервер будет хранить информацию о активных сессиях в БД.
Подписать куки можно, например, добавив в них помимо нужной вам информации какой-нибудь HMAC.

Авторизация. Сервер никогда не хранит пароли. В базе данных хранят логин и хеш пароля (на самом деле нет). Для авторизации пользовтель передаёт логин и пароль (HTTPS). Сервер вычисляет хеш от пароля и, если он совпадает, сессия помечается как авторизованная.

Соль. Теперь представим, что вы действительно храните логин и хеш пароля в таблице:

login | pass_hash
------+----------
vasya | 4B32E1C...

В идеальном мире это бы неплохо работало. Но в реальном мире 90% ваших пользователей будут иметь пароль вида 12345, password, password123, etc. Соответственно в базе данных будет много одинаковых хешей и злоумышленнику не составит труда быстро подобрать пароли большинства ваших пользователей.
Для этого для каждого пользователя сервер сохраняет некоторые уникальные случайные данные (соль). А вместо хеша пароля хранится hash(pass + salt).

login | salt   | hash
------+--------+-----
vasya | 4B3... | 2A3B9...

Таким образом усложняется перебор паролей по словарю.

Хеш. Возможно вы где-то видели или слышали про MD5. Так вот, MD5 на сегодняшний день не является надёжной криптографической хеш функцией и даже если вы примените MD5 сто или тысячу раз, это не сильно изменит ситуацию. На сегодняшний день рекомендуется использовать SHA-2 или SHA-3.

P. S. Соль и токены обязательно должны быть сгенерированы с помощью CSPRNG.

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

Можно ли вынести реализацию шаблонного класса в отдельный cpp файл?

- Можно ли вынести реализацию шаблонного класса в отдельный cpp файл?
- Нет.

1. Указать путь к заголовочным файлам.
   
2. Указать путь и имя библиотеки.
   

Детали могут отличаться в зависимости от вашей среды разработки. В visual studio должны быть настройки для этого. Если используете cmake, тогда используйте find_package, target_include_directories, target_link_libraries.