Александр Титов

Нет, это не очень хорошо. Вам желательно использовать легкие (green) треды и/или event pool. Иначе, при большом количестве клиентов уткнетесь в ограничения по количеству тредов.
Посмотрите на асинхронные библиотеки типа aiohttp или twisted cyclone.io.

Основные отличия - гита от svn - распределенность и хорошая поддержка ветвлений в разработке (ветки).

SVN, конечно же, поддерживает ветки, но при сложных ветвлениях (ветки мержатся между собой) случаются неожиданные конфликты и т.п. Хотя, если у вас классическая схема - фича-ветка от мастера (транка) и обратный мердж в мастер (транк) - разница почти незаметна.

Про распределенность: у SVN центральный сервер, у гита - граф серверов, хотя 99% процентов разработчиков используют локальный репо + один удаленный, т.е. по сути - тот же центральный сервер. Зато, так как репа локальная, гит очень быстр в переключении веток.

Есть еще куча различий и, как плюсов, так и минусов у каждого ПО. Хотя сегодня SVN все реже и реже можно встретить, но в общем для многих рабочих групп его вполне достаточно для полноценной работы. С другой стороны - знать git тоже обязательно сегодня, ибо почти стандарт ;)

Если вот так на первый взгляд поискать "чем svn лучше"...

• работа с бинарными файлами, и быстрее и есть централизованные локи по репозиторию (что важно, ибо мердж бинарного файла обычно не очень эффективен);
  
• есть система управления доступом вплоть до веток;
  
• комит определенного юзера этим юзером и подписан, тогда как в гите аутентификация и поле автора не связаны никак (впрочем, последние две проблемы можно пофиксить хуками);
  
• порядок комитов явный, т.е. есть глобальный счетчик с номером у каждого комита, хотя, конечно, не так принципиально;
  
• частичный чекаут, т.е. начиная с любого узла SVN, удобно, если много мелких проектов - не нужно несколько репозиториев, просто один с папками проектов в корне
  

Но я бы не стал говорить, что svn нормальный, а git нет. Просто он другой и со своими тараканами. Сам долгое время работал на SVN, потом потихоньку перебрались на git в основном из-за подводных камней сложного ветвления.

Незыблемых правил два.
1. В CPP первым — свой хедер. Это даёт уверенность, что в хедере нет недостающих включений.
2. Избегать циклической зависимости по интерфейсам. Делить программу на слои и не включать ничего из верхних слоёв.

Если уж второе не получилось — есть три решения, каждое из которых решает свою задачу.
1. Forward declaration, полумера против сильной связанности классов.

// Хедер 1
class Master;

class Slave {
  Master* master;
}

// Хедер 2
class Master {
  Slave slave;
}

2. Разорвать порочный круг интерфейсом.

// Хедер 1
class Master {  // interface
public:
  virtual void enumSlaves(const EnumSlavesCallback& v) = 0;
  virtual ~Master() = default; 
}

class Slave {
  Master* master;
}

// Хедер 2
class MyMaster :  public Master {
public:
  Slave slave;
  void enumSlaves(const EnumSlavesCallback& v) override {}
}

3. Вынести общие типы/функции в отдельный хедер под названием someDefines.h или someUtils.h.

Проще всего использовать файлы отображаемые в память, там уже за вас обо всем подумали.

Смотря что именно подразумевается под "создать массив" )) Вот хорошая шпаргалка на тему, что это может означать и где он в результате окажется:

int arr1[100000]; // BSS
vector<int> arr2; // HEAP
 
struct DumbStruct {
    int someArr[10000];
};
 
int main () {
    int arr3[100000]; // STACK
    vector<int> arr4; // HEAP
    int* arr5 = new int[100000]; // HEAP
    int* arr6 = (int*) malloc(100000 * sizeof(int)); // HEAP
    static int arr7[100000]; // BSS
    DumbStruct struct; // STACK
    DumbStruct* struct2 = new DumbStruct(); // HEAP
    vector<DumbStruct> structarr; // HEAP
    int n;
    scanf("%d", &n);
    int arr8[n]; // STACK (assuming C99 -- this does not compile in C++)
}

Если речь именно о динамическом выделении памяти и именно о С++, то есть два варианта: malloc()/free() и new[]/delete[]. Теоретически в случае фрагментации памяти (когда ее, в принципе, достаточно, но не "одним куском") ни тот, ни другой не "заполнит" никаких "свободных" ячеек. malloc() вернет NULL, a new[] кинет std::bad_alloc.

А практически, конечно, возможно, что угодно... т.к. 1. new - это оператор, и значит, его можно переопределить, 2. с помошью std::set_new_handler ему можно подсунуть свой аллокатор, а также 3. полезет ли new[] вообще к malloc(), строго говоря, не гарантируется и, наконец 4. реализация malloc(), вообще-то, зависит от ОС, а они нынче умные и могут прореагировать как угодно - вплоть до убийства затребовавшего память процесса OOM менеджером.

Так что, наиболее точный ответ на вопрос: возможны варианты (хорошие и разные)... Однако, если суть вопроса в том, а не получится ли при этом случайно массив, который не массив, то ответ - нет, не получится. Массив, это семантическая конструкция языка. В С++ программист может полагаться на то, что память в массиве непрерывна.