Андрей Капров

Все уже изучено

Коротко - используйте везде префиксный, тогда отладочный код будет работать чуточку (или даже существенно) быстрее, а сам код будет выглядеть крепко, основательно - как будто сениор писал.

В самую первую очередь - это будет документация языка. Ее очень удобно использовать как справочник. Это - твой самый первый источник информации по любому вопросу.
isocpp поддерживается создателем языка и содержит море полезной информации.
C++ Core Guidelines является манифестом пользователя C++. Его знать обязательно. Документ регулярно дополняется.

More C++ Idioms. Шаблоны проектирования имеют свою собственную многомерную классификацию. Идиомы - это функциональные шаблоны проектирования, применимые, как правило, или для конкретного языка, или для некоторого семейства языков. Эта открытая книга помогает ориентироваться в некотором начальном наборе идиом конкретно для языка C++.
C++ Patterns - еще один полезный ресурс для изучения применимых к C++ шаблонов проектирования.
С Fluent C++ ты уже знаком.
Безусловно, блог создателей PVS-Studio.
Habr, конечно же.
Блогов очень много, их можно просто найти по релевантной фразе "C++ blog".

Помимо этого есть большое количество каналов от разных конференций, доклады на которых всегда помогают понять язык лучше.
С++Russia,
C++Now,
Pacific C++,
CppCon,
code::dive,
Meeting C++.

Так же будет полезно изучить книги авторов:
Андрея Александреску,
Герба Саттера,
Девида Вандервуда,
Скотта Мейерса,
Роберта Мартина.
Есть и другие очень полезные авторы. Тут у меня, пожалуй, только самый основной список.

Последим, и самым важным, источником будет текущая рабочая версия стандарта языка, а так же пара лабораторий для практики: Compiler Explorer и C++ Insights.

Привет! Я дизайнер компании PVS-Studio и обычно этих единорогов рисую я :D

На самом деле, технологически процесс несложный. Как и сказали выше, я рисую их на бумаге или в фотошопе, зачастую с нуля, а потом получившуюся иллюстрацию отрисовываю в Adobe Illustrator, чтобы получить легко масштабируемое изображение с ровными векторными линиями. На это уже уходит немного больше времени, но результат того стоит. У нас есть только одна деталь, которая не отрисовывается и не изменяется, переходит от картинки к картинке - это его рог!

По одной из картинок в примерах мы писали небольшую статью, как она создавалась. А вот еще одна статья о том, как мы создаем весь наш иллюстрированный и не только мерч :)

Да, как бы, ничего не мешает писать один С++ код для множества платформ. Почти весь мой трудовой стаж связан именно с разработкой кроссплатформенных игр. Я работал с несколькими (самодельными и не очень) движками и имею свое собственное детище, прекрасно и однозначно собирающееся на 5 целевых платформ (Win, Mac, Linux, ios, Android), к которым без труда можно добавить и консоли, и новые платформы.

Нет, вру, не без труда. Попотеть над слоем абстракции придется. Но попотеть придется только над ним, все остальное заведется само, т.к. изначально написано в стандарте C++, без расширений под конкретные компиляторы, и с применением ряда очень важных для кроссплатформенности подходов.

Кроссплатформенность подразумевает решение ряда вопросов, которые и выливаются в слой абстракции над операционной системой. Эти вопросы, зачастую, решать никто не хочет. Несколько раз встречал такое сам и еще мне рассказывали о том, как тот или иной движок сперва был только под конкретную ###, а потом решили портировать на @@@. Оказалось, что компилятор, которым всегда и собирали движок, нашпигован расширениями языка, которые конечно же все пользовали на 100%, и при смене компилятора ни один файл исходников не остался без доброй сотни ошибок. Т.е. переписывать надо было ВСЁ.

Mercury13 хорошо рассказал про Unicode пути к файлам. Drakonoved правильно подметил про разделители путей к файлам. Максим Гришин очень хорошо напомнил про порядок следования байт. Это все и есть часть этого ряда вопросов.
У каждой платформы есть свой API, которого не будет на другой платформе. Но на другой платформе будет свой API, со своими именами и схожей функциональностью. И работу с API надо абстрагировать от универсального кода.
Еще, на одной платформе у тебя может быть разомкнутый главный цикл обработки сообщений (Win), а на другой - замкнутый (Android). Надо подстраиваться. GUI везде разный, надо подстраиваться. Сама структура приложения на одной платформе может быть монолитной, а на другой - композиционной. Графические и звуковые API могут быть и кроссплатформенными, однако простоты использования это им не прибавляет. Инициализация все равно будет платформозависимой.
На самом деле даже в рамках работы на одной платформе надо соблюдать ряд правил, чтобы иметь возможность из одного кода получать и 32-битное приложение, и 64-битное тоже. Об этом неплохо написано на сайте разработчиков PVS-Studio.

И все это решается. От части - с помощью архитектурных приемов. Один из таких я уже показывал в другом своем ответе.
И еще эти вопросы можно не решать.
ДубльГИС, например, уже давно работает на базе Qt, что сильно упростило им кроссплатформенную жизнь. Qt решает ряд проблем кроссплатформенности.

У вас 1/4 и 1/3 - целочисленное деление, соответственно равны 0. Используйте 1/4. и 1/3.
И ещё лишние sqrt.

rez = pow(2, -x) * sqrt(x + pow(abs(y), 1/4.)) * pow(exp(x - 1 / sin(z)), 1/3.);