dreamer-dead

V624 The constant 3.14159265 is being utilized. The resulting value could be inaccurate. Consider using the M_PI constant from <math.h>

Amazon Lumberyard разрабатывается как кроссплатформенный движок. Поэтому разработчики стараются поддерживать как можно больше компиляторов.

Вы имеете ввиду простоту маршалинга данных между другим языком и С?
Конечно, Python или JS не знают о std::string, никто не спорит.

Тут никто не отрицает низкоуровневые плюсы языка С.
Однако, выставить интерфейс для биндинга можно и на С++ (никто не мешает в публичном API принимать const char*).
Например, в ICU примерно так и сделано: внешний API по сути на С, а внутри он оперирует С++ объектами.

В случае С++ вы можете быть поставлены перед выбором: использовать std::vector или писать свой код на malloc + realloc.
Если не хочется использовать Boost\STL — так не используйте, никто же не заставляет.
В случае С вы даже выбора не имеете, ни шаблонов ни деструкторов (RAII), ни move семантики.
Так что разработчик вынужден тратить кучу времени на колупание с указателями, удалением и прочей рутиной.
Основной принцип С++: Вы не платите за то, что не используете.

В том то и вопрос, что сообщество не будет переписывать по сути весь проект, профитов недостаточно, а багов можно таких наделать, что огого.
При этом одиночные энтузиасты будут потом мучительно мержить свой форк с мастером.
Так что без поддержки это просто не выгорит и в лучшем случае просто не будет получать обновления из основного репозитория.

Довольно неожиданно, но интересно.
Для этого нужна определенная смелость.
Вы не подскажете, это некая официальная инициатива, или просто пет-проджект энтузиаста без какой либо поддержки сообщества?

Грустно, конечно, видеть что очень много усилий разработчиков в таких проектах тратятся на то, что в С++ компилятор сделал бы сам.
Например, большую часть кода из патча можно было бы заменить на std::vector<> и пару шаблонных функций. При этом получили бы type safety.
Но понятно, что никто никогда не станет переписывать такие проекты на другом языке.

То, что код компилируется, ничего не значит.
Массивы нулевой длины разрешены в C99, но не в С++(любого стандарта).
И в GCC и в Clang это реализовано через расширение языка, например -Wzero-length-array у Clang.
См. код http://coliru.stacked-crooked.com/a/810283a668408e8a

Использовать это понятно как, например принять по сети пакет с данными переменной длины, но с фиксированным заголовком и указанной длиной буфера.

Не буду ничего говорить про код, не писал на шарпе уже несколько лет.
Но мне не совсем понятна задача утилиты.
У Вас бывает так, что работаете над кодом, затем переключаетесь без коммита и потом забываете, в какой стадии находится работа?
Попробуйте делать небольшие коммиты почаще.
Иначе, вот через неделю я вижу что репозиторий "грязный". Но как понять, нужно ли коммитить, или продолжить разработку? Что должно быть в commit message, если я толком не помню, что делал?
Разве не придется все равно делать git status или запускать утилиту, чтобы понять все это?
Опять же, Ваша утилита даже имя текущей ветки не показывает.

Но мне кажется, если начнете углубляться, то окажется, что копируете GUI вроде того же Tortoise.

When it becomes useful is when the first operand does, or may (if it is a macro argument), contain a side effect

SomeType* z = CallSomeFunctionWithSideEffects();
if (!z) z = SomeOtherFunction();

SomeType* z = CallSomeFunctionWithSideEffects() ? : SomeOtherFunction();

AVFrame *frame; //кадр YUV420P
AVFrame *_frame; //кадр RGB32

AVFrame *yuv_frame;
AVFrame *rgb_frame;

blob initial(100500);
blob copy1(initial);
blob copy2(copy1);
// Что тут делать?

const std::string FONT_PATH = "c:\\Componentality\\Fonts";