megorit

armhf (hard float) код может выполняться только на процессорах с аппаратной поддержкой вычислений с плавающей точкой.
armel (emulation) код включает в себя эмулятор соответствующих операций. Выполняется медленнее, но на большем количестве процессоров.
armv7 по идее должен работать с armhf. Подробнее ищите по ключевым словам «ARM floating point»

std::any позволяет сохранить в себя объект любого типа, после чего через any_cast вытащить значение, если оно такого типа, как мы предполагаем. Проверка осуществляется через RTTI. Если поддерживается много конкретных типов, вы должны писать здоровенную цепочку if-else-if. В таком случае лучше уж идти через наследование.

1.Вместе со значением передавайте информацию о типе в каком-нибудь виде
2.Определяйте тип по содержимому, если это возможно.

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

Основная функция git checkout это перемещать указатель HEAD, т.е. то куда смотрит ваша локальная копия. Вы можете переместить его на вершину ветки: git checkout <branch> или на отдельный коммит: git checkout <sha>Ну а вспомогательные это создание веток:git checkout -b, отмена изменений в файле:git checkout -- <file>

Kernel - относится больше к операционной системе.
Сore - Применимо к прикладным программам, процессорам
PS - тапками можете не кидаться, это мое личное мнение.

Google: "postfix. подробное руководство pdf"
Первая ссылка ваша, на русском. Там всё с низов. Построите фундамент, поймёте принципы работы SMTP и любой почтовик ваш.

Да, как бы, ничего не мешает писать один С++ код для множества платформ. Почти весь мой трудовой стаж связан именно с разработкой кроссплатформенных игр. Я работал с несколькими (самодельными и не очень) движками и имею свое собственное детище, прекрасно и однозначно собирающееся на 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 адрес и там уже разбирается

Вам необходимо задеплоить приложение, для этого я использую утилиту
сqtdeployer

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

Вы можете установить из github выпусков (Windows)

или

из snapstore(Linux)

sudo snap install cqtdeployer

Вы можете использовать следующим образом:

* Windows:

%cqtdeployer% -bin myApp.exe -qmake path/to/Qt/5.x.x/build/bin/qmake.exe -qmlDir path/to/my/qml/files/dir

* Linux:

cqtdeployer -bin myAppю -qmake path/to/Qt/5.x.x/build/bin/qmake -qmlDir path/to/my/qml/files/dir

• path/to/Qt/5.x.x/build/bin/qmake- это путь к qmake с помощью которого было собранно ваше приложение. в сборках с cmake нужно так же указать путь к qmake того qt с которым вы собирались. Это связанно с тем что qmake отдает cqtdeployer-у необходимое для сборки окружение.
  
• path/to/my/qml/files/dir - это путь непосредственно к вашим qml файлам (который вы написали).
  
• -qmlDir path/to/my/qml/files/dir - данный флаг можно исключить если вы не используете qml.
  

Запускать приложение нужно с помощью скрипта sh (Linux) или exe (Windows)

Если вы будете использовать версию из оснастки, убедитесь, что у вас есть все разрешения.



Если вам нужно использовать версию Windows, просто установите приложение из installer

Отличная книга по алгоритмам это Кормен `алгоритмы построение и анализ`.
Лучшего не найти и не надо. На хабре была соответствующая статья
Книга можно сказать основа:-)

Кнут это конечно перебор:-) тем более у него не 3 тома, а 4 и делится на а, б и тд.

В общем смысле, инициализация может быть выполнена тремя основными способами. std::initializer_list участвует в двух из трех.

Foo bar = {...};
Foo bar{...};

В обоих случаях выполняется List Initialization, в первом - copy list-initialization, во втором - direct list-initialiaztion.

Тут важно отметить что принятие решения о использовании std::initializer_list выполняются только на этапе трансляции. В обоих случаях сперва транслятор попробует придумать std::initializer_list. Если у аргументов типы разные (а приведение типов при такой записи не делается), то попробовать создать std::initializer_list у транслятора не получится. Но если получилось, то транслятор уже итак знает число аргументов, переданных в конструктор.

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

Egorithm, Отлично, теперь у вас есть файл библиотеки *.a, include-файлы *.h и разделяемая библиотека *.so.
Задачи, в порядке приоритета.
1. Заставить прогу компилироваться, для этого надо в проекте прописать доступ к include-файлам *.h.
2. Заставить прогу линковаться, для этого надо в проекте прописать доступ к *.a (-lmuparser -L$$PWD).
3. Заставить прогу запускаться, закинув куда надо *.so.

Он в каталоге Release вашего проекта.

UPD: И ещё вопрос, можно ли будет запускать этот файл на любом дистрибутиве Линукса?

Да, если там установлены библиотеки Qt.