Roman

Их тонны.
Вот, к примеру, используется в Яндексе https://github.com/3Hren/blackhole
Неужели так трудно набрать в Гугле: "C++ JSON logging"?

Почему не отобразился текст параметра? Тип же верен.

Потому что недостаточно просто поменять тип параметра функции. Нужно ещё поменять то как она вызывается.
В венде для этого есть другое имя для main -- wmain.

> если это буква НЕ RUS(маленькая,большая, и отдельно стоящие ё), НЕ ENG(маленькая,большая), и это НЕ пробел - то меняю boll на значение false

Здесь ты пишешь "И", а в коде почему-то стоит "ИЛИ".

вдумайся в смысл выражения (c != 32) || (c != 184), оно всегда истинно

И сравнивай стандартными функциями вроде isalpha, в крайнем случае c >= 'a' && c <= 'z', но не с числами, во первых не читаемо, во вторых нет гарантий, что кодировка ascii.

А ещё лучше упростить код так:

bool isValidChar = isAlpha(c) || isDigit(c) || isSomethingElse(c);

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

Вообще непонятно почему у вас так. Попробуйте чистый пример вроде:

QSharedPointer<QDataStream> doFoo()
{
    return false;
}

Возможно у вас что-то не то с флагами, или окружением, или компилятором, или версией Qt. Дело в том, что у QSharedPointer нет такого конструктора. Сделаю предположение, что у вас MSVC вместо компилятора :)

Советую возвращать какой-нибудь DefaultAnswer или просто nullptr.

Roman, те ссылки, что вы привели не релеванты. Они про приведение типа к bool, но не наоборот.

Гугл.

Я вовсе не шучу. Вам вопрос примерно таков "Какая существует литература по автомобилям?" Существуют дистрибы -"УАЗ-ики" и дистрибы-"спорткары", дистрибы-"грузовики" и дистрибы-"бентли"... Все начинается от задачи. Задача какова? Просто изучить? Ставите VBox (или заводите любым другим доступным способом виртуалку), выбираете нубский дистриб (минт, бубунта etc), качаете, ставите...

DevOps отличается от обычного сисадмина тем, что не может сказать "это задача программистов".

Предположим, есть общий шаблон сериализации данных для работы с абстрактными потоками ввода-вывода.
Обобщенный шаблон такой сущности может выглядеть вот так.

template< typename TValueType >
struct Serializer final
{
	static inline const bool Read( const BasicStream& stream, TValueType& value_storage );

	static inline const bool Write( BasicStream& stream, const TValueType& value_storage );
};

У этого шаблона может присутствовать набор частных инстанцирований для простых и стандартных типов.


Любой пользователь библиотеки всегда может определить частное инстанцирование сериализатора для своего типа точно в такой же манере. А можно просто отдать свой пользовательский тип на откуп обобщенному шаблону.

А теперь вкусненькое. Среди стандартных типов есть и std::string, и std::vector, и std::map. Если пользователь решит сериализовать весь контейнер своих пользовательских типов, нам не стоит обязывать его писать частное инстанцирование сериализатора для контейнера. Нам надо предусмотреть сериализацию любого стандартного контейнера с любым пользовательским типом.

Мы это делаем с помощью частичной специализации шаблона сериализатора.


И так далее.

А вот как может выглядеть внешнее определение функции при частичной специализации.

Как вариант, в современном C++ можно написать, например так:

std::system(R"_("C:\Program Files (x86)\test\test.exe")_");

Всё что в круглых скобках будет интерпретировано как написано. Разделители могу быть почти любыми. Больше примеров тут: https://en.cppreference.com/w/cpp/language/string_... .

Способ хранения такой есть.

https://ru.wikipedia.org/wiki/Двоичное_дерево_поиска

Где-то в задании у вас должно быть пояснение, зачем вам это надо. То есть другие пукнты задания - это поиск и сортировка.

Если полином степени m возвести в степень n, то результирующий полином будет иметь степень m*n.

Итак,

какие конкретно стоит почитать

1. Макконнелл, "Совершенный код". Объемная но не особо сложная книжка, можно прочитать не особо то за большее время чем такую-же книжку из художественной лит-ры.
2. Роберт Мартин, Идеальный программист. Есть ещё "Программист прагматик", вроде тоже о чем то подобном. Книжка небольшая, в принципе можно за пару тройку недель прочитать рассуждения Дяди Боба о работе программиста.
3 Роберт Мартин, Чистый Код. Весьма хорошая книжка, очень широко затрагивает тему написания поддерживаемого кода. Важно - особенно в этой книге, но так же и в любой другой - не зацикливайтесь на догмах аля "3 строчки на функцию", не обожествляйте SOLID, а рассматривайте, какие проблемы решают предложенные решения. Советую в каждом случае рассуждать о том, как описываемые вещи влияют на качество кода и архитектуры программы.
4. Роберт Мартин, Чистая Архитектура - относительно новая книжка о том, что всё новое это хорошо забытое старое. Возможно вещи описываются немножко поверхностно, впрочем, углубляться в любом случае нужно самому. Книжка годная, получше объясняет SOLID, затрагивает другие принципы, затрагивает парадигмы, принципы дизайна, архитектуру, объясняет почему то, что многие горе-разработчики нынче зовут ООП им не является. Думаю эту книжку можно даже перенести на первое место.
Дальше уж по ситуации - паттерны GoF, PoEAA, Рефакторинг Фаулера, Кента Бека про тестирование etc.

подсознательно я продолжаю выбирать именно "правильные" подходы,

Боюсь, что вы просто используете те подходы что знаете, а не выбираете исходя из требований и ситуации.
Хотя бы потому что "правильных" подходов не бывает, есть подходящие в данной ситуации, и плохо подходящие, компромиссные и откровенно вредные.

наследование — это реализовывается само собой.

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

Упомяну один момент: статейки в интернете и даже(о боги) на всеми нами любимом хабре или тостере, как и любые другие источники информации, книги и доклады любимых нами авторов представляют исключительно субъективное мнение автора, и лишь его понимание описываемой темы, сформировавшееся в силу, обычно, неизвестных нам обстоятельств. Они могут нести за собой скрытую сложность, абсолютно не подходить в ситуациях отличных от ситуации автора, и никогда не стоит принимать из за единственно-верную истину. Скорее, за пищу для размышлений и альтернативные подходы к какому-либо делу.