Mercury13

В первом приближении (деформации малы, балка лёгкая) — половина параболы.
Если точно — решить можно только численно.

Информационная безопасность требует от вас понимать, что такое эксплойт. Потому нужны оба языка. Может, не очень глубоко, но какой-то код надо писать на том и на другом.
Дело в том, что «няшная сишка» стала отличным полигоном для эксплойтов, да и низкоуровневые библиотеки пишут часто на ней (для компактности). А на Си++ пишут современный софт.
Раз вы на ПэХаПэ, вы не понимаете, что такое указатель, и потому лучше начать с Си++. Просто потому, что как-то можно программировать без указателей, а понять, что это за чёрт указатель — дело наживное.

1. Виртуальный деструктор тут нужен — ведь в списке будут вперемешку элементы разных классов.
2. Не видны два компонента, которые и делают список связным — указатель на следующий элемент (test* next) и указатель на голову (test* head = NULL).
3. В попытке скрыть реальную жизненную задачу — ведь СС не вещь в себе, а решает какую-то задачу вроде «держать список объектов в игре» — вы слишком уж напереименовывались.

Критерий таков.
1. Баланс ( и ) должен сохраниться.
2. а) Либо вырожденный случай (скобку меняем дважды на противоположную);
б) либо ) → ( идёт перед ( → );
в) либо уровень вложенности обеих скобок не менее 3, при этом они сидят в общих скобках 2-го уровня.

Из-за 2в без предобработки за O(n) проверить невозможно. Но предобработка хороша, если мы решаем кучу таких запросов, и с этим отдельный вопрос. В таком случае, вероятно, лучше использовать дерево отрезков, обрабатывающее каждый запрос за log n. Пока мне алгоритм понятен не до конца; если вы скажете, что действительно задача про кучу запросов — подумаю..

В первую очередь авиасимуляторы. Знаю, что из-за масштабов Земли им приходится справляться с ошибками float: если Земля 12000 км в поперечнике, то единица младшего разряда — полметра.
Первый X-COM имел круглую землю, но полёты были по локсодроме. А вот в опенсорсном ремейке 2014 года полёты уже по большому кругу.
Симуляторы бога от Питера Молиньё: Populous, Black and White. Возможно, и другие симуляторы богов (например, Spore — не проверял).

Я говорю именно про шарообразную карту, а не трубу/тор.

А так — я бы предостерёг от шарообразной земли с открытым миром. 1) Расстояния (глобальная карта с ускоренным временем или без времени не в счёт). 2) Навигация по миру (в том числе понятие «север»), проекция миникарты. 3) В какой-то момент нужно закругляться и выкатывать игру, а в какой-то — выдавать аддон. Тяжеловато будет. Кстати, во всех упомянутых играх мир или замкнутый, или намного больше, чем одна планета.

P.S. Моё определение открытого мира: игра, дающая относительную свободу действий и передвижения, но локальный участок, где орудует игрок/группа, намного меньше мира. В замкнутом мире, наоборот, участник орудует практически по всему «миру», оперативно переходя с одного участка на другой. Есть и пограничные случаи: огромное побережье нового Hitman — открытый мир или замкнутый?

Любой, работающий с HTTP.
Привязки к cURL — а именно он в большинстве случаев используется для HTTP — есть практически везде.
Проверено: есть сайты, где Indy (стандартная сетевая библиотека Delphi) не пройдёт, а cURL — за милую душу. Видимо, криптография + «Indy слишком вумный и скрытно корректирует сообщение».

Очередь, физически не перемещающая элементы (кольцевая или некое подобие std::deque) и позволяющая по указателю быстро определить позицию.

Плюс любой индекс (хэш- или деревянный), элементы которого — указатели на элементы очереди. Если элементы очереди unique_ptr, то указатели будут именно на unique_ptr! Для «мусорных» языков (C#, Java) вместо указателей можно придумать какие-то идентификационные коды — например, сочетание из номера в пуле массивов и номера в массиве.

Enqueue — вписываем элемент в индекс. Dequeue — удаляем из индекса. Обмен позициями — корректируем эти два элемента индекса.

1. ВЕРНО. A \cap C \in A \in B \in B \cup D (прости уж, что пишу тэгами TeX).
3. ВЕРНО, следует из законов логики.
5. UPD. Всё-таки ВЕРНО, тут надо действовать через x. Пусть $x \in A \cap C$, тогда $x \in A$ и $x \in C$. А значит, $x \in B$ и $x \in D$. Дальше понятно? Точно так же можно решить и 3.

Private — на что? Ведь тот, кто пойдёт этот интерфейс реализовать, их не увидит.

С protected штука более сложная. Дело в том, что в классическом интерфейсе ноль кода и данных, и эти protected должен вызывать — кто — разумеется, потомки. Преждевременно увековечивать внутреннюю архитектуру — зачем?

Встречается ещё такая штука, как «прокачанный интерфейс» — не знаю, как он правильно называется по ООП. Там есть две новых вещи: 1) утилиты — невиртуальные функции, которые представляют собой стандартный сценарий пользования интерфейсом; 2) штатные реализации — некоторым виртуальным функциям придумывают реализацию, которая как-то работает и пользуется другими виртуальными, но потомок, если захочет, может написать более эффективную версию.

Вот например, утилита.

// write Intel word
void st::Stream::writeIW(uint16_t w)
{
    write(&w, sizeof(uint16_t));
}

Утилита не часть интерфейса, и лучший синтаксис для утилит — методы-расширители C#. На худой конец подойдёт простая функция типа Streams.writeIW(stream, 10);.

Вот, например, штатная реализация.

// Возвращает остаток потока
// cu_minus = clipped unsigned minus
virtual Pos remainder() { return cu_minus<Pos>(size(),pos()); }

Если в языке нет штатных реализаций, строят класс, где эти функции чем-то реализованы — не всегда, но часто можно унаследоваться от этого класса.

Раз утилита пользуется обычными общедоступными функциями, нет никакого смысла её кидать в protected (теоретически private/protected могут быть некоторые части сложных утилит). Штатные реализации — тем более, это такая же часть интерфейса, как абстрактные size() и pos().

Это значит: объект класса B должен иметь (или не иметь) «товарища» класса C. Иметь не во владении, а по ссылке. А лучше не класса C, а его подмножества, реализованного как интерфейс (я его назвал IC). На A вообще чхаем — его задача собрать B и C в нужном виде, и всё.

Смотрите шаблон проектирования Dependency Injection.

class IC {   // interface
public:
  virtual int getC() = 0;
  virtual ~IC() = default;
};

class C : public IC {
public:
  int getC() final { return 42; }
};

class B {
public:
  IC* buddy() const { return fBuddy; }
  void setBuddy(IC* aBuddy) { fBuddy = aBuddy; }
  void someJob() const { if (fBuddy) std::cout << fBuddy->getC() << std::endl; }
private:
  IC* fBuddy = nullptr;
};

class A {
public:
  A() { b.setBuddy(&c); }
private:
  C c;
  B b;
}

Специально для тех, кто на Си++: в таком виде A неперемещаем из-за указателя c.fBuddy. Есть много способов исправить это — например, подправить конструктор копирования и операцию «присвоить» класса A.