Дмитрий

Там же один файл в исходниках. Просто запустите компиляцию руками. Там какой-то древний Makefile.
$ gcc -march=native -O2 -lz afsctool.c -o afsctool

Вам нужны знания графики. Понимания, как оно всё там работает под капотом. Без этого всего DirectX будет казаться чем-то космическим и непонятным. DirectX никак не завязан на чистый WinAPI. Он базируется на технологии COM. Это посложнее для понимания, чем WinAPI. Ну и, соответственно, это всё работает только на Windows.
OpenGL чуть проще, там чистое Сишное API. Можно писать для множества операционных систем, в том числе, для мобильных платформ.

Оба API используют конечный автомат для рендеринга, все состояния которого тоже нужно отлично понимать. У OpenGL, на мой взгляд, он более лёгок для понимания.
Но для всего этого вам нужно знать, что используется там под капотом. Бездумно искать строки кода и копипастить их к себе не получится. Нужно знать что делает каждая функция, какие состояния конечного автомата меняют, и т. п.

Если хотите начать учить всё это дело, советую начать с отличных статей на Хабре. Если вы осилите весь этот курс, то сможете писать хоть на OpenGL, хоть на DirectX, хоть на Unity/Unreal/CryEngine.

Т.е по сути моя i должна быть равна 3

Не должна она вам ничего, пока документацию не прочитаете.

Зачем вы добавили ios::trunc при открытии файла?
trunc от слова truncate, переводится как: обрезать, усекать, урезать, сокращать.

В документации ясно написано же: trunc discard the contents of the stream when opening. Что переводится как, отбрасывает содержимое потока при открытии.
Он же вам его очищает и открывает новый пустой файл, вы его читаете, а там нечего читать. Вот и результат.

Гуглится ж за полторы секунды.
google://ssh-agent forwarding

Подскажите, пожалуйста, каким образом выявить и уничтожить эту заразу?

Полной переустановкой сервера.

libuv
libevent

Самые шустрые и распространённые библиотеки.
Первая используется в ядре Node.js.
Вторая — в куче проектов типа хрома, тора, файрфокса, мускуля. Умеет http-роутер из коробки.

На Си дурной тон писать сервер, когда не знаешь Си. Бред наркомана.
90% всех существующих серверов написано на Си. Другое дело, что надо знать одновременно и язык, и тонкости ОС, и тонкости сетей, уметь пользоваться профилировщиками памяти. Ну, и времени нужно очень приличное количество.

Сети — это сети. А C++ — это C++. Не бывает такого, чтобы была книга сразу по двум громадным направлениям.

Сначала учите C++, а потом сети.
К тому же, под C++ нет сетевых API. Они все всё равно написаны изначально на чистом Cи и никак не пересекаются.

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

Откройте документацию хотя бы, и прочитайте про входные параметры for_each:

template< class InputIt, class UnaryFunction >
UnaryFunction for_each( InputIt first, InputIt last, UnaryFunction f );

От вас требуют на вход итератор на первый элемент first и итератор на последний элемент last. Ниже можно найти, что InputIt значит InputIterator.

Теперь смотрим документацию std::list.

Iterators
begin   returns an iterator to the beginning 
cbegin  (public member function)

end     returns an iterator to the end 
cend    (public member function)

То, что нам нужно. begin() даст нам итератор на первый элемент, т.е. first, а end() — на last.

Смотрим дальше

Member types
Member type	Definition

iterator	BidirectionalIterator

Смотрим, что такое BidirectionalIterator. Написано, что он должен быть в свою очередь ForwardIterator'ом. А ForwardIterator удовлетворяет концепту InputIterator. Как раз то, что нам нужно.

В итоге, достаточно написать for_each(test.begin(), test.end(), show);

Но, сейчас на дворе 2017 год, давно уже введены новые фишки в C++. Например, можно сходу передать анонимную функцию (лямбду) вместо обычной функции, в случае, если она однострочная:

for_each(test.cbegin(), test.cend(), [](int v) {std::cout << v << std::endl;});

Также, C++11 добавляет новые методы для получения константного итератора cbegin() и cend(), т. к. нам не нужно модифицировать список, лучше воспользоваться константными итераторами, чтобы избежать ошибок в случае случайной модификации.

Либо, как уже сказали, если у вас слишком большое тело цикла, чтобы не городить из лямбд спагетти и чтобы это всё легко читалось, можно использовать range-for:

for(const auto &v : test)
  std::cout << n << ' ';
std::cout << '\n';

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

Clion для начала вполне годный. Со сложными исходниками и последними стандартами у него беда, конечно. Глючит порядочно, но постоянно что-то фиксят. Был бы бесплатный, ещё ладно. Но платить за это поделие желания нет. Если у вас меньше 4-х ядер и 8-ми гигабайт, можете даже не пробовать, будет жутко бесить тормозами. Хотя, в последних EAP довольно неплохо улучшили отзывчивость в нагрузке. Раньше даже печатать было невозможно, пока он там шуршит.

Есть ещё простенькая IDE — juci++. Но она пока что в активной разработке и очень спартанская, мало чего умеет, но не тупит и очень неплохо автодополняет.

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

QtCreator до сих пор не научился HiDPI. У меня на обоих девайсах dpi достаточно высокий, всё выглядит как пережатый 50 раз jpeg. Может быть, если у вас обычный монитор, то будет нормально.

Если есть желание позамарачиваться, можете освоить vim. Для него есть неплохой плагин YouCompleteMe. Но там всё надо тюнить, крутить 50 тысяч параметров. Но настроив под себя, довольно удобно получается, хотя, мало кто это осиливает.

Это вообще разные вещи.
Нужно отличать изучение API, от изучения технологии. Если вы хотите выучить просто API, учите что угодно, ибо разницу заметите только, когда поймёте основы, базу.

OpenGL проектировался когда были другие архитектуры железа. Мультипроцессорность была только в теории, и считалась уделом суперкомпьютеров и ненужной для пользовательских ПК.
Можно привести аналогию: OpenGL == C++, Vulkan == асинхронный Assembler + hardware threads. Например, в C++ сейчас довольно много архитектурных косяков, которые пытаются решить новыми стандартами, объявляют какие вещи устаревшими, потому что они концептуально неверны и не подходят под современные реалии.
Но, при этом, вы можете всё то же самое написать на ассемблере, но нужно намного лучше понимать, как работает процессор и ОС, самому писать примитивы синхронизации, и т. п.

Для этих же целей и создавался вулкан. Для программирования на нём, нужно знать все тонкости железки, читать кучи пейперов от той же НВидии, исследовать, придумывать новые фичи для современных архитектур с нуля, которые изначально были придуманы в OpenGL, но для старого железа.
Т. е. на Вулкане нужно делать больше руками, больше оптимизировать. Вместо одного вызова функции OpenGL, на вулкане придётся несколько сотен строк написать. При этом, если вы не понимаете какой-то одной тонкости, вы сделаете менее эффективнее то, что изначально было хорошо реализовано в OpenGL. К тому же, OpenGL умеет выбрасывать ошибки, в случае, когда вы где-то накосячили. Вулкан же их не выбрасывает, он полагается на то, что вы уже знаете как этим пользоваться. Точно так же, как ассемблер просто меняет состояние регистров, у него нет понятия ошибки. Как интерпретировать эти регистры, зависит от того, насколько хорошо разработчик читал мануал к процессору.

В итоге, я бы ответил так:

Если вы будете заниматься графикой как наукой, дико задротить а-ля Кармак в студенчестве с его движками, что-то исследовать, писать какие-то гениальные алгоритмы, защищать на этом диссертации, публиковать их, рассказывать потом на конференции, как вы круто справились с какой-то насущной задачей, повысили производительность, то тогда учите Vulkan. Vulkan — это именно про графику как технологию, про производительность, про инжиниринг и архитектурный дизайн, а не про API и само программирование. С вулканом придётся больше сидеть с диаграммами, документациями и строить архитектуру, придумывать методы взаимодействия частей этой архитектуры, синхронизации состояний, нежели писать код.

Если же вы пишете простые прикладные вещи, которым нужно показать какую-то графику, то учите OpenGL. Здесь вы учите только API, соглашаясь с уже готовым, слегка устаревшим, архитектурным дизайном.

Если хотите писать игры не мирового класса, то учите готовые движки, Unity или Unreal. Они уже поддерживают за вас Vulkan, продумали за вас API и архитектуру.