Станислав Макаров

Для чего нужны виртуальные методы?

Виртуальные методы - это реализация полиморфизма в C++.

Обычная виртуальная функция нужна для правильного вызова перегруженных функций в производных классах

Переопределённых, а не перегруженных.

Но для чего нужен виртуальный деструктор, к примеру?

Объект тоже может разрушаться полиморфно:

class shape {
public:
    virtual ~shape() { } // без virtual будет вызван деструктор класса shape
};

class circle : shape {
public:
     virtual ~shape() { } // c virtual вызовется деструктор именно того класса, объект которого вы разрушаете
....
};

shape* c = new circle();
.....
delete c; // вызов деструктора. С virtual вызовется деструктор circle, а не shape, как нам и надо.

GEOS конечно, чего тут думать.

• Координата.
  
• Точка: широта+долгота или широта+догота+высота.
  
• Линия: линия соединяющаяя две точки по кратчайшему...
  
• Многоугольник.
  
• Круг. - идеального круга скорее всего нет, т.к. его нет в спецификациях OGC.
  

• Дистанцию между точками, точкой и прямой, многоуго...
  
• Площадь многоугольника, круга...
  
• Проверка принадлежности одного объекта к другому (см. ниже).
  
• Пересечение/объединение/разность объектов.
  
• Прямая/обратная геодезические задачи. - не могу сказать, в геодезии пока не очень, вы имеете в виду преобразование координат?
  

Если не верите мне, поверьте команде PostGIS :)

GEOS for many geometry processing algorithms
Proj.4 for coordinate re-projection functions
GDAL for raster processing and format support

С jsoncpp не работал, код написан по исходникам библиотеки:

for (const auto v : jsonObject["buffer"]["data"]) {
    const std::uint8_t b = static_cast<std::uint8_t>(v.asInt());
    // пишете b в файл
}

Что вы пытались сделать в приведенном коде, я так и не понял. Касательно записи в файл - история отдельная.

1. Нужно собрать релизную версию приложения. Не распротраняйте на другие компьютеры дебажные версии. Тогда "d" требовать не будет.
2. Т.к. приложение на C++, оно будет требовать рантайм. Этот рантайм можно как слинковать статически, так и оставить динамически загружаемым. Это настраивается в свойствах проекта. Если слинковать статически - то тогда dll не потребуется, но и обновить рантайм отдельно от приложения будет невозможно.
3. Если поставлять рантайм отдельно, как динамически загружаемый (т.е. чтобы была dll), то можно либо класть его рядом с exe, либо устанавливать redistributable версию райнтайма. Второе предпочительнее, т.к. тогда рантайм можно будет обновить с помощью системной обновлялки, если в нём будут найдены критичные проблемы.
4. Чтобы точно узнать, что требует EXE для своего запуска (не считая модулей, загружаемых с помощью LoadLibrary), воспользуйтесь Dependency Walker.

Более подробную информацию вы сможете получить на MSDN в разделе деплоя C++ приложений.

Если вам нужна конкретно простейшая подсветка синтаксиса (как в вашем примере с html), то вам достаточно лексического анализа. Вам нужно выбирать токены в тексте, и в зависимости от типа токена, выбирать цвет для подсветки. В разных средах это будет реализовано по-разному - в Саблайме это делается через спец. язык описания конечных автоматов, в других редакторах могут использоваться регулярные выражения, в Visual Studio пишется лексический анализатор на ЯП общего назначения.

Поглядите на эти инструменты, С/С++: Flex, ANTLR для дотнет-языков еще FsLex хорош (правда, синтаксис у него F#-овский).

Если нужен более сложный анализ (например, подстановки в зависимости от контекста), смотрите ответ Дмитрий Макаров - это уже синтаксический анализ, следующий этап после лексического. Упомянутый Yacc - это классическая пара к Lex/Flex. Есть и более современный аналог, совместимый с Yacc - Bison. Под дотнет могу посоветовать тот же ANTLR, и FsYacc в пару к FsLex.

однако неопределенные поведения мы либо обрабатывали исключениями, либо как-то логично обрабатывали входные параметры операндов (obj1 + obj2). А как же тут обрабатывается?

А вот не поверите, есть два вида программистов: те, которые считают, что хорошо замалчивать ошибки, и те, кто УЖЕ так больше не считает. Есть даже статьи на Хабре, которые рассказывают, какой JS хороший и "надежный". Считать замалчивание ошибок надежностью - имхо это значит не стать (пока что) программистом. От ошибок можно уметь восстанавливаться, но замалчивать их нельзя.
В качестве примера посмотрите на архитектурные подходы в Эрланге. Прям погуглите по словам "erlang let it crash". Этот подход, поддерживаемый концепцией процесса в Эрланге, говорит, что тот код, который не может дальше нормально выполняться, должен "упасть". А мы напишем другой код, который будет следить за работой основного, и в случае нештатных ситуаций будет предпринимать необходимые действия (например, перезапускать процесс).
Да хотя что далеко ходить, концепция исключений в более популярных языках также есть способ научиться жить с ошибками, не бояться их генерировать, и уметь их обрабатывать там, где это возможно и удобно. Это первое.

Второе: JS это язык со слабой типизацией. Это такая штука, которая позволяет написать 1 + "1" и безо всяких перегрузок в стиле C++ транслятор сам приведёт какой-то из аргументов к такому типу, чтобы операцию можно было выполнить. Вы сейчас просто в большом удивлении от того, что это возможно и кому-то такое могло прийти в голову (вы из плюсов пришли, да?). Кстати, в PHP почти то же самое. Только правила преобразований другие немного. (Кстати, почитайте об операторах == и === в JS, узнаете много удивительного, если еще не сталкивались).

Ведь браузерные движки написаны на С++, а значит все это JS-дело определено на уровне С++, мне интересно какие внутренности определяют такое поведение.

Никакие внутренности не определяют это поведение. Все эти случаи либо явно описаны в стандарте JS и их просто реализуют в соответствии со стандартом, либо реализуют так, чтобы реализации были максимально совместимыми. Тут можете почитать про typeof null, возвращающий "object" - по сути один большой баг, который теперь поддерживают, чтобы не сломать совместимость.

Из-за этих мелочей в JS минимум системности и логичности. Этим языком правит совместимость, а не логика. Почему он такой, какой есть, вам уже ответили.

template<typename Func> void MyFunc (const Func & otherFunc);

void MyFunc (const std::function<void()> & otherFunc);

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

С другой стороны, почему-то никто не упомянул такую важную разницу:

class overloaded_functor {
public:
	bool operator()(int a) const { return a > 10; }
	bool operator()(double a) const { return a > 10.0; }
	bool operator()(const std::string& a) const { return a.size() > 10; }
};

template <typename Func>
void foo(Func f) {
	// Все варианты компилятся и работают (т.к. сама шаблонная функция foo и все применения оператора вызова к f компилятся ПОСЛЕ того как мы написали foo(overloaded_functor()) );
	f(3);
	f(5.4);
	f("Blah");
}

void bar(std::function<bool(int)> f) {
	f(3);
	// Компилится, но, как и ожидаемо, конвертит double к int, чего мы в нашем случае не хотим
	f(5.4);
	// Не компилится вовсе
	f("Blah");
}
...
foo(overloaded_functor());
bar(overloaded_functor());

std::function по-определению требует указания конкретного типа функции/функтора, которую он оборачивает, поэтому std::function не может работать с перегруженным функтором. Это не так часто нужно, но бывает, например visitor часто реализуется именно таким функтором с несколькими вариантами оператора вызова.

На всякий случай отмечу, что я ни в коем случае не говорю, что std::function недостаточно мощный вариант. Наоборот, его нужно использовать в большинстве случаев, т.к. в большинстве случаев нужно функция конкретного типа (конкретной сигнатуры и конкретного возвращаемого значения). Однако разницу следует понимать, т.к. эти варианты используются в разных ситуациях.
Ну и понятное дело, обычный указатель на функцию неудобен, т.к. не позволяет захватить контекст. В Сях для этого существует паттерн userData, и всякий разработчик библиотеки, которая использует callback-и, реализует этот паттерн. В Плюсах для этого есть std::function.