jcmvbkbc

Можно ли создать шаблон только для одного метода класса?

Да, можно. В чём сложность взять и попробовать?

class C {
public:
    template<typename T>
    void f(T v)
    {
        ...
    }
};

почему вот это не компилируется?

Потому что первый элемент пары -- константа, присваивать ему нельзя.

если строки не константны - то все работает

Ну да, что тут удивительного?

предполагаю где-то накосячил в Vect, подскажите где именно?

Накосячил вот здесь:

inline void push_back(const T &elem)
    {
        capacity;
        pvector[size] = elem;
        ++size;
    }

Ты забыл выделить память под pvector, и поэтому получил segfault.

Почему то при вызове GetDiskFreeSpaceEx() программа останавливается

PULARGE_INTEGER Free;
    PULARGE_INTEGER Total;
    PULARGE_INTEGER TotalBytes;

  cout<<"\n\nСписок томов:";
HANDLE search = FindFirstVolume(Volume, sizeof(Volume));
do {
    cout <<"\n"<<Volume;
    GetDiskFreeSpaceEx(Volume, Free, Total, TotalBytes); //

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

ULARGE_INTEGER Free;
    ULARGE_INTEGER Total;
    ULARGE_INTEGER TotalBytes;

  cout<<"\n\nСписок томов:";
HANDLE search = FindFirstVolume(Volume, sizeof(Volume));
do {
    cout <<"\n"<<Volume;
    GetDiskFreeSpaceEx(Volume, &Free, &Total, &TotalBytes); //

void CheckPressedKey(char** area, char** area_buf, int row, int col)
{
  struct Ships ships;

Структура ships -- автоматическая, существует на стеке только во время выполнения этой функции, создаётся (с неопределёнными значениями полей) при входе в неё и исчезает при выходе.
Если ты хотел, чтобы она сохранялась между вызовами этой функции, нужно было добавить static: static struct Ships ships;. С этим изменением будет работать так как ты задумал, но наличие статических переменных в функциях -- не очень хорошая практика. Обычно лучшим решением является передача таких данных в функцию как параметра, например:

void CheckPressedKey(char** area, char** area_buf, int row, int col, struct Ships *ships)

Как в gcc сохранять объектные файлы

Опция -o -- путь к результату, препроцессирования/компиляции/линковки. Научи свой Makefile подставлять правильный путь в эту опцию.
Ты скажешь "а у меня 100500 исходных файлов компилируется разом". Ответ -- а не надо так делать. Компилятор всё равно вызывается каждый раз новый. Напиши правило компилирующее один файл в нужный каталог -- и выполни его по разу для каждого исходника. Например так:

NAME = calc

SRC = main.c \
  parser.c \
  ft_lib/ft_atoi.c \
  ft_lib/ft_putchar.c \
  ft_lib/ft_putnbr.c

BUILDDIR=build
OBJ = $(addprefix $(BUILDDIR)/,$(subst /,_,$(patsubst %.c,%.o,$(SRC))))

FLAGS = #-Wall -Wextra -Werror

all: $(NAME)

$(NAME): $(OBJ)
  gcc $(OBJ) -o $(NAME)

define CC_RULE =
$(BUILDDIR)/$(subst /,_,$(patsubst %c,%o,$(SOURCE))): $(SOURCE)
  gcc $(FLAGS) -c $< -o $@
endef

$(foreach SOURCE,$(SRC),$(eval $(call CC_RULE,$(SOURCE))))

clean:
  rm -f $(OBJ)

fclean:
  rm -f $(NAME)

re: fclean all

Смотри: я сделал список объектников из $(SRC), написал генератор CC_RULE, который для любого исходника генерирует правило компиляции его в объектник под $(BUILDDIR) и вызвал его для всех исходников в $(SRC).

Это забавное развлечение, но гораздо практичнее воспользоваться существующей системой сборки: autotools/CMake/...

Падает после окончания/записи char элемента на long long элементе..

Ты бы показал, что твоя программа печатает когда падает. И заодно в фильтре адрес напечатал бы, а то непонятно, может у тебя начало long long в одной странице, а окончание -- в другой?

Есть ли какая-то разница?

Разница в том, что инициализация bool full = false; выполняется для любого конструктора, у которого поле full не перечислено в списке инициализации.
Конечное состояние конструируемого объекта одинаково в обоих случаях.

И почему так конструктор не работает:

Потому что у класса Token отсутствует конструктор по умолчанию.

int *array = new int[mSize];
...
HANDLE hThread = CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)a,&array,0,&tid);
...
int a(int *array)

В вызове CreateThread надо заменить &array на array, потому что переменная array -- не массив, а указатель.

первый вопрос: можно и нужно ли после этого вызывать delete, чтобы передать очищенную память в пользование ОС?

Если ты заглянешь в стандарт С++, в место определяющее оператор delete, то увидишь, что его можно вызывать только для памяти выделенной new. Поскольку память под код функций ты не выделял через new, то и delete вызывать нельзя.

Что будет, если создать что-то вроде продвинутого singleton, который будет динамически выделять память для класса при запуске, а после выполнения функций можно будет вызвать функцию, которая просто сотрёт класс и отпустит память?

В принципе это можно реализовать. Но приведённая реализация даже близко не делает того, что ты ожидаешь.
Сначала может показаться, что она работает. Память, правда, возвращаться в ОС не будет. Потом ты может быть заметишь, что код тоже остаётся на месте. Потом ты может быть заметишь, что программа иногда падает из-за NULL-пойнтера в каком-то другом объекте. Короче, если ты сможешь это отладить, у тебя прибавится знаний в том, как всё устроено на уровне ассемблера. Если не сможешь, то твою программу ждут чудесные падения, а тебя -- не менее чудесные баг-репорты.

Можете, пожалуйста, объяснить как точно все это устроено в памяти?

Обычно это устроено так, что поля идут одно за другим в памяти. Но кроме размера у полей есть выравнивание. Например, uint32_t выравнивается на 4 байта, а uint64_t -- на 8. Поэтому между идущими подряд полями разного типа могут быть дырки.
В приведённом примере double -- поле с наибольшим выравниванием, выравнивание объекта будет на 8, поле c будет по смещению 0 в объекте, поле d -- по смещению 8, а поле i -- по смещению 16. Если иметь это в виду, то игры с указателями приобретают смысл.

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

Пожалуйста, никогда так не делай.

при первом запуске клиента,цвет меняется, запускаю второй клиент, у него уже просто символы

Потому что это скорее всего две консоли с разными настройками терминалов. Интерпертация esc-кодов, их удаление из выводимого потока и смена цвета -- это функция терминала.

Как работает наследование полей у шаблонного класса?

Наследование работает так же как и у не-шаблонного класса, а поиск имён -- по-другому.

Почему не получается неявно найти, что head и tail это поля базового класса?

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

(соответственно, пофиксить можно не только написав myList<T>::head, но и this->head, оба эти изменения делают имя head зависимым [от параметра шаблона]).

Это правило поиска имён отличается от правил поиска имён в обычных классах, которое включает в себя родительские классы.