Максим Мосейчук

В целом, твой вопрос не имеет точного ответа, т.к. вопрос затрагивает темы вкуса цветных карандашей и просто является риторическим.

Помимо всей этой воды, что я ниже изложил, еще очень стоит ознакомиться с разделом "SF: Source files" официального гайдлайна:
https://github.com/isocpp/CppCoreGuidelines/blob/m...
(Очень советую изучить весь гайдлайн от корки до корки)

По первому вопросу, коротко: если тип используется по значению - полное объявление типа обязательно, иначе можно обойтись Forward declaration.

Немного подробнее:

Существует такой принцип формирования проекта, когда каждый заголовочный файл предоставляет полную информацию о зависимостях. Forward declaration в таком случае или запрещено, или сильно порицается. Каждый заголовочный файл должен обязательно включать в себя заголовочные файлы всех зависимостей. А файл исходного кода должен включать ровно один заголовок - тот, чей интерфейс реализуется в исходном коде.
Это позволяет сразу видеть все зависимости кода, не париться с размещением файлов, не париться с транзитивными зависимостями, просто не париться, а так же существенно огребать на времени компиляции. Особенно если в проекте разрешен только #include "", а #include <> порицается.
В качестве примера можно почитать UE4.

Существует и другой принцип формирования проекта, когда файловая структура отражает макроуровень архитектуры проекта. Скажем, если проект базируется на подсистемах или слоях, каждый слой(подсистема) представляется ровно одним заголовочным мастер-файлом и своей отдельной папкой в файловой системе. Внутри этой папки расположены все внутренние заголовочные файлы подсистемы. Ни один внутренний заголовочный файл не содержит никаких зависимостей, только объявление своего интерфейса. Все зависимости (FD, другие подсистемы или слои, системные заголовки и.т.д.) описывает только мастер-файл, он же в нужной последовательности подключает все внутренние заголовки. Другие подсистемы, равно как и исходный код самой подсистемы, включают в себя только мастер-файл.
Это позволяет снять всю шелуху с внутренних заголовков и сосредоточить их текст ровно на декларации интерфейса. С другой стороны, ради использования какого-нибудь мелкого типчика всегда приходится подключать всю подсистему, т.к. внутренние заголовки подключать нельзя по правилам формирования проекта и потому что их зависимости неясны.

В обоих принципах применяется одно очень важное правило: Один класс - один комплект исходного кода с именем самого класса. Это, можно сказать, самый базовый принцип формирования проектов. Классы с инвариантом и богатым функционалом должны быть объявлены каждый в своем отдельном заголовке, имеющим имя класса. Описание функционала каждого такого класса должно лежать в своем отдельном файле исходного кода с именем описываемого класса. Иногда и вовсе требуется несколько файлов исходного кода на один класс, потому что класс выполняет слишком много функций, но разделять его нельзя.
Этот принцип нередко приводит к проблеме циклической зависимости, когда два класса ссылаются друг на друга и в каждом заголовке необходимо включение второго заголовка. В этом случае помогает или редизайн классов для ослабления зависимостей, или Forward declaration как меньшее из зол.

С точки зрения компилятора есть только один формат файла - формат исходного кода, который ему и надо обработать.
С точки зрения человека форматов файла не два, а 3 или 4:

• .c , .cc , .cxx , .cpp , c++ - формат исходного кода, в котором стоит производить определение интерфейсов и держать все приватные инструменты (код и типы);
  
• .h , .hh , .hpp - формат заголовка, в котором подключаются заголовки зависимостей и объявляется интерфейс - ровно то, что может понадобиться в другом коде или не может быть определено в файле исходного кода. И ничего больше;
  
• .inl - формат вспомогательного заголовка, в котором производится определение inline функций и сложных шаблонных конструкций;
  
• .inc - формат вспомогательного заголовка, в котором описываются форварды, внешние глобальные переменные, константы и прочие данные. Этот формат используется реже всего. Вместо него чаще используют формат заголовка (.h), размещая в нем весь контент .inc файла.
  

Если с "человеческими форматами" все должно быть хорошо понятно, то с форматом файла для компилятора стоит уяснить одну тонкость - все эти человеческие шахматы с бубнами и делением на файлы должны складываться в как можно более удобный для компиляции вид. Чем меньше одинаковых #include, тем лучше. Чем меньше #include в целом, тем лучше. Трансляция - дело итак нелегкое.

Обязательно к прочтению, перед использованием Git

Если разделы с NTFS монтируются через /etc/fstab , то добавьте там опции uid=username,gid=groupname для нужного юзера и группы.

Напустите ldd на исполняемую программу, он покажет какие библиотеки откуда загружаются :и где не хватает:
$ ldd hello-world-program
Можно еще включить отладочный режим загрузки библиотек при запуске программы:
$ LD_DEBUG=libs ./hello-world-program

"релизы" в терминах гитфлоу - это тэги на мастере.
если форсить можно, что всё просто: git checkout master; git reset --hard second

так обновите pkg, вам же написали что требуется pkg версии 1.6.0 и выше, а у вас стоит 1.5.4
сделайте
pkg update
pkg upgrade pkg

Придумайте число, выходящее за пределы int, и попробуйте его присвоить переменной long без "L", программа не скомпилируется.

Ну, раз вам "понятно, веб-разработка", то вспомните о том, где вся эта "веб-разработка" крутится и какие операционные системы стоят на подавляющем большинстве серверов.

Массив - это непрерывная область памяти (буфер) определенного типа.
С++ на уровне языка определяет для этого два средства: статические массивы (a[10]) и выделение блоков памяти, на которые можно ссылаться через указатель (int *a = new int[10];)

Но, в отличие от многих других языков, C++ не котролирует выход за границы массива, в результате чего можно сделать так:

int a[10];
a[333] = 5; // запись в ячейку памяти 
//по адресу 334 * sizeof(int) от начала массива.

Кроме того, для массивов, расположеных в куче (выделенных с помощью new) нельзя определить их реальные размеры (для статических массивов мы можем сделать sizeof(a)/sizeof(int)). Кроме того передавать многомерные массивы в функции, оперировать с динамическими массивами (изменяющими размер в процессе работы) и многие другие проблемы. Для их решения существует класс std::vector, который дарит нам абстракцию над массивом в хипе.

PS С С++11 появился еще std::array, который является абстракцией над статическим массивом.