Дмитрий

Сети — это сети. А 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 и архитектуру.

Вот к примеру
char ch = str[5];
длина str всего 3. Поэтому возникает ошибка, но vs не вылетает

Оно и не должно вылетать. Выход за пределы массива это неопределённое поведение. Компилятор вправе делать что угодно при неопределённом поведении, хоть систему вам форматировать, хоть пойти закурить. Он не обязан выкидывать исключение. Контроль этого только на вашей ответственности. Либо используйте статический анализатор, он вам покажет, что вы не так делаете.

А ещё лучше, для строк используйте специально созданный для этого контейнер std::string, для статических массивов — std::array, для динамических — std::vector. И ничего не будет вылетать.

google://filetime to systemtime

Если у вас С++, а не чистый Си, то конечно используют std::vector. А вместо char[] используют std::string.
Если Си, то придётся выделять динамически через malloc.

https://github.com/boostorg/asio/tree/develop/exam...