Mercury13

Мы обычно привыкли к порядку байтов в слове. Однако в криптографии и телекоммуникациях также играет роль порядок битов в байте — обычно у младшего бита номер 0, а у старшего 7. Это упрощает произвольный доступ к любому биту, передачу информации в порт по одному биту — я писал самодельные низкоуровневые коммуникационные протоколы, правда, давно и под DOS. Но тут, по-видимому, наоборот — байт начинается со СТАРШЕГО бита. Вижу в этом две причины.
1. Межплатформенный стандарт двоичной передачи данных — передавать длинные числа, начиная со старшего байта, просто для удобства ручного исследования протоколов. Тут ручное исследование доведено до предела: байт делится на биты, которые также записываются от старшего к младшему — как мы бы записывали на бумаге.
2. Криптографию по-чёрному оптимизируют, чтобы она оперировала не байтами, а самыми длинными единицами, доступными процессору: 64-битный — значит, блоками по 8 байтов.

0x80 = 0b1000'0000. Вот вам и единичный бит и куча нулей.

SET_RESTORE_ROUND_53BIT (FE_TONEAREST);
Настройка сопроцессора. Это какая-то магия, имеющая две задачи: производительность и повторяемость.

Дальше мы залезаем в устройство числа (причём для краткости имеем дело с 32-битными командами!) и проверяем на «малость» — если получилось малое, то sin x ≈ x.

Дальше идёт проверка на |x|≲45° — идёт вычисление настоящего синуса. Опять-таки, проверка по верхним 32 битам числа (синус вычисляем по всем 64 битам ☺️).

Если число не очень большое, мы загоняем его в диапазон ±45° и вычисляем синус или косинус.

Если число побольше — идёт более злой загон в диапазон ±45° и то же самое.

И последнее, что осталось,— ∞/NaN.

Внутренние функции обозревать не буду, но что мы тут видим?
1. Какие значения бывают чаще, какие реже?
2. Для очень маленьких значений sin x ≈ x, cos x ≈ 1.
3. Ещё одно — залезание во внутренний формат компьютерного дробного, причём даже на x64 имеем дело с 32-битными целыми.
4. Даже функция приведения в ±45° есть в двух видах — упрощённом и «злом» в зависимости от абсолютной величины числа.

Не использую просто потому, что модули плохо устаканились. Посмотрел по MinGW — всё ещё экспериментальная функциональность.
Для стандартных модулей: если поддерживаете Си++23, то пожалуйста. Это обычно главный источник медленной компиляции. Мой проект пока только 20.
Для сторонних библиотек: можно прямо сейчас, если они собраны в модуль. Ни одной такой пока не видел, тем более в G++, как я сказал, это пока эксперимент.
Для собственных модулей: убедитесь, что их поддерживает система сборки. В Си++26 усилят требования к модулям, потому что взвыли разработчики этих самых систем. И, как я сказал, в G++ модули — всё ещё эксперимент.

Похоже на некорректные DLL. И, по-моему, виноваты DLL Си++ — обычно это творится, если используют сторонний компилятор (свежий Си++ дорогого стоит), а библиотеки из Qt.

Простите, что пишу с опозданием.
Потому что в Qt есть два «родителя».
Родитель, отвечающий за уничтожение, и родитель в иерархии окон.
Это вы объявили, кто автоматически уничтожит окно. А тут ещё надо someParent->addWidget(someChild);.

В Delphi это названо owner и parent соответственно.

Разрешите вмешаться. Штатное процессорное выравнивание — 8 на x64.

Выравнивания ниже штатного иногда увеличивают, чтобы одним махом обрабатывать несколько полей. Например, для умножения цветов в формате RGB на x86 кто-то одним махом множил R и B, а вторым — G. Но при этом для производительности цвет должен иметь выравнивание 4.

Выравнивания выше используют только для хитрых системных целей: выйти за строку кэша, работать с железом, которому такое выравнивание нужно, иногда для оптимизации: улучшенный Doom грузил таблицы преобразования цветов по адресам, кратным 64K, и собственно в EDX грузил адрес, в DH цвет фона, в DL цвет изображения — и получал в EDX указатель на новый цвет.

Касательно SDL — они в этой функции хотели абстрагироваться от формата цвета (RGB или BGR).

С enum — всё больше зависит от архитектуры проги: например, вы можете абстрагироваться от реальных значений цветов и иметь цвета «фон», «передний план», «рамка таблицы», «хороший», «плохой». Разница в производительности невелика.

Да, работа с сегментом данных и стеком значительно легче для процессора, и потому их используют везде, где можно. Куча используется в четырёх основных сценариях.
1. Выделение большого количества данных, которые стек вместить не может. Пример: матрица на много-много мегабайт.
2. Выделение не известного заранее количества данных. Обычно «не известное заранее» = «возможно, большое», но и тут есть интересный пример: даже если 1000 символов на строки нам хватает за глаза, строки используются настолько часто, что слишком уж расточительно на каждую строку пускать по килобайту.
3. Сложное время жизни объекта, не ограниченное рамками функции. Примеры могут быть в играх: функцией Spawn объект появляется, функцией Kill уничтожаем.
4. Использование виртуального полиморфизма (см. ООП). Игровые позиции, как ни странно, плохо совместимы с ООП, так что давайте будет так: функция CreateStream может создать поток, работающий с отрезком памяти или файлом.

Указатель может иметь такие значения.
• Единственная «ниточка», ведущая к объекту в куче. Все указатели перенаправили, а объект не уничтожили — всё, кусочек памяти «висит».
• Некие «стрелочки», налаженные между объектами, чтобы устроить связный список, дерево или что-то ещё. Независимо от того, какие объекты: мы вполне можем в небольшой игре создать кучу объектов с запасом, скажем, в сегменте данных или даже стеке, и налаживать между ними такое же взаимодействие, как будто они в куче.
• Просто «стрелочка» на кусок памяти, которую принимает или отдаёт функция. Причём эта стрелочка может указывать и в пустоту (nullptr). Всё, что функция изменяет по этой стрелочке, будет видеть и вызывающая программа — в отличие от передачи по значению. Или просто объект такой большой, что его копировать бессмысленно. Или архитектурно некопируемый (системный ресурс вроде открытого файла).
• Арифметика указателей позволяет работать с кучей объектов, которые сидят рядом в памяти. В Си++ есть понятие «итератор» — объект, похожий на указатель и обладающий арифметикой указателей, но позволяющий пробежаться, например, по дереву поиска.
• Опять-таки, виртуальный полиморфизм приводит к тому, что к нам приходит не-знамо-что не-знамо-какого устройства (мы лишь знаем, что этот объект, скажем, умеет читать данные как из файла) — обращаться к таким объектам можно только через указатели. В отличие от предыдущего примера с итераторами, мы не понимаем даже самых основ объекта — сколько он байтов занимает, как его создавать, копировать и уничтожать (часто в интерфейс объекта входят столь же виртуальные команды «сделать копию» и «уничтожить», но это отдельный вопрос).

На ссылку смотрите как на указатель, который 1) не может указывать в пустоту; 2) надо обязательно сразу же присвоить и дальше не перенаправлять. Самое то, когда функция принимает или отдаёт «стрелочку» на кусок памяти, и стрелочка никогда не может указывать в пустоту.

Что значит «подключить файл»?
Загрузить файл данных? std::ifstream.
Загрузить динамическую библиотеку? Ищи системные функции вроде LoadLibrary в Windows и dlopen в Linux. (Кроссплатформенных библиотек загрузки DLL/SO мало, а стандарт за этим даже не гонялся.) Но в любом случае потребуются заголовки функций в препроцессорном файле.

Си++ компилирует в машинный код и не таскает за собой компилятор, и потому динамически подключить файл исходника, как это делает какой-нибудь PHP, не может. Только динамическую библиотеку — какие-то исходники, скомпилированные в машинный код.

Файл исходника подключается не препроцессором, а системой сборки (потому что так работал ассемблер, и потому что разделение компилятора, линкера и системы сборки позволяет соединять вместе код, написанный на разных языках, и потому что хорошая система сборки позволяет включать в сборку нестандартные шаги). Да, существует устройство кода «одна единица трансляции» — у неё кратчайшее время полной перекомпиляции, но невозможна компиляция по частям и на многих процессорах, и одну единицу обычно берут для среднего размера библиотек (SqLite), где-то до минуты — время немалое, но любая значимая программа перебьёт, и один хрен библиотеку пересобирают только целиком. Препроцессором обычно подключаются заголовки типов и функций.

Если нужна поддержка скриптов в проге — смотри на Lua. В последнее время очень любят Python. но я не в курсе и один хрен пригодно только для больших прог, готовых таскать с собой дистрибутив Питона.

Символ Ландау g(x) = O(f(x)) при x→y означает: g(x)⩽kf(x) при x, достаточно близких к y. В данном случае y=∞.
То есть с точностью до константы. А как Wataru сказал, основание логарифма — это умножить на константу.

А я попытаюсь сказать, почему удобны символы Ландау.
1. Математическим исследованием сложно выяснить, сколько операций займёт одна итерация цикла — две или тысячу. Этим пусть занимаются микрооптимизации.
2. Зато в любую программу загонят столько данных, что она сломается. И как правило — если не доказано обратное — асимптотическая сложность быстро пересилит эту самую константу, и программа большей сложности сломается первой.
3. Ну вот прога сломалась, и мы занялись микрооптимизациями и заменили процессор, и получилось, скажем, вдвое — насколько более крупные задачи мы теперь можем решать? Если O(N), то вдвое более крупные. Если O(N log N), то несколько меньшие, чем вдвое. А если O(N²), то в 1,4 раза.

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

Если работаем на чистом WinAPI, надо пробовать перенаправление потоков ввода-вывода.

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

Никакого. int32_t — это из Си, std::int32_t — стандартное пространство имён Си++.

А какой код генерации этих данных? Я пока вижу, что 8 байтов длины в формате Motorola (58), после этого 58 байтов данных. Мне интересно узнать, откуда взялся qword длины, и откуда — dword 6 в начале, тоже в формате Motorola?

UPD. Пока подозреваю, что дело в SendBufferSizeSocketOption.

Это НЕ синтаксический разбор, а семантика языка.
В большинстве случаев играет роль ближайший идентификатор. Но в инициализаторах снаружи скобок поле объекта (больше ничего там быть не может, только поле)

#include <iostream>

class Obj {
public:
    Obj(std::string x)
        : x(std::move(x))
        // 1. Поле, больше ничего быть не может
        // 2. Параметр, как ближайший идентификатор
    {
        std::cout << '[' << x << ']' << '\n';  // Параметр, как ближайший идентификатор
    }
private:
    std::string x;
};

int main()
{
    Obj obj("Habr");
    return 0;
}

Итак, задача — сгенерировать случайные числа по закону Гаусса.
Если есть Си++11, копай модуль <random>.
Если нет, простейший способ сгенерировать — F⁻¹(ξ), для этого есть бэ-мэ качественные приближения обратного распределения Гаусса.
Есть также более «лёгкий» способ генерировать такие числа по два сразу, гугли.