Mercury13

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

Если работаем на чистом 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⁻¹(ξ), для этого есть бэ-мэ качественные приближения обратного распределения Гаусса.
Есть также более «лёгкий» способ генерировать такие числа по два сразу, гугли.

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

1. ОС-зависимые ресурсы (например, ресурсы Windows). Поскольку тут у вас и так WinAPI, этот способ вполне катит.
2. Обёртка Qt или чего-то другого над этими ресурсами: где они есть, ресурсы, а где нет, простые массивы. Использовать, если и без того используете Qt.
3. Склеить EXE-файл с MP4. Главное — придумать способ разделить их обратно (например, добавить четыре байта длины в конце).
4. Преобразовать MP4 в байтовый массив, вставить в какой-то CPP.
5. Вариант 4, но более быстрый в компиляции: Использовать ожидаемую функцию Си #embed.

Если отбросить в сторону общую упоротость кода (облом делать ревизию), проблема вот в чём.
Работая с коллайдером (фигурой, которая участвует в проверке столкновений, она же хитбокс), вы выбрали диапазон клеток
[y / 16; (y + h) / 16).

Например, y = 1, h = 16, (y+h)/16 = 1, диапозон [0,1), и проверяется только клетка 0. А надо 0 и 1.

Так что надо [y / 16; (y + h - 1) / 16]. ВКЛЮЧАЯ СПРАВА.

Вариантов много.
1. Непрозрачные указатели, которые нельзя разыменовывать.

struct OpaqueAddress;
using Address = OpaqueAddress*;

2. void*, const void*.
3. uintptr_t.
4. Жёсткие int’ы, если работаем с конкретной посторонней прогой под конкретную архитектуру (например, пишем чит к игре).
using Address = uint32_t;
5. Enum class, основанный на соответствующем int’е.
enum class Address : uintptr_t { NUL = 0 };

Уровень 1. Чёрно-белое.
R, G, B = round((x−min)·255 / (max − min))

Уровень 2. Градиент между цветом X и цветом Y.
t = (x−min) / (max − min)
R = round(R1·t + R2·(1−t))
G и B аналогично.

Уровень 3. Учёт гамма-кривой монитора. Тут работаем сразу в двух цветовых пространствах: линейном от 0 до 1, и sRGB от 0 до 255.
gamma = 2,2 — sRGB состоит из линейного и степенного участка, но неплохо приближается real_brightness = channel_%^gamma
invGamma = 1/gamma
функция toLinear(v) := (v/255)^gamma
функция toSrgb(q) := (q^invGamma)·255 — в общем, обратная
linR1 = toLinear(R1)
linR2 = toLinear(R2)
t = (x−min) / (max − min)
R = round(toSrgb(linR1·t + linR2·(1−t)))

Уровень 3.1. 16-битная аппроксимация (если важна скорость). В общем, линейное цветовое пространство — не дробные от 0 до 1, а целые от 0 до 65535.
функция toLinear(i) := round(((i/255)^gamma)·65535)
массив toSrgb(q) := ((q/65535)^invGamma)·255 — записывается в виде массива на 65536 величин
linR1 = toLinear(R1)
linR2 = toLinear(R2)
K = (65535 / (max − min)
t = round((x−min) * K)
R = toSrgb(((linR1·t) + linR2·(65535−t) + 127) >> 16)

Уровень 4. Сложный градиент из нескольких цветов.
Для этого например, t=0 — синий, t=⅓ — зелёный, t=⅔ — жёлтый, t=1 — красный.
Тогда прикидываем, в какой промежуток попадает t, получаем, например, t1=(t−⅓)·3, и дальше по уровню 3.

Debug-версия библиотеки может помочь отлаживать какую-то дичь на границе вашего и библиотечного кода. Я лично не пользовался ни разу, всюду подключал release-версию.
UPD. Я не работал с MSVC, но этот самый MSVC имеет разные runtime-библиотеки для отладки и выпуска. И они не хотят соседствовать друг с другом. Это уже внутренние разборки MSVC; две библиотеки MinGW, статическую и динамическую, но обе release, вполне себе позволяет и для некоторых целей (упрощение отладки на той самой границе) очень даже помогает. SDL2, как и большинство открытых библиотек, имеют минимальные зависимости и ему просто не нужна библиотека MSVC.

Если считать, что прога верная, а блок-схема нет.

1. Непонятно, почему ввода нет, вывод есть.
2. Начальное присваивание smallest опущено.
3. Очень креативно изображён двойной цикл. Не знаю, верно ли это — но пару вложенных циклов, если рамки внутреннего не зависят от того, что творится во внешнем и не нужно прерывать один внутренний, я бы написал оба в одном шестиугольнике.
4. Условие внутреннего цикла я бы написал i=[0..n)
5. В программе сначала выводим сообщение, потом матрицу. На БС наоборот.

PS. Чёртов препод, ну не годится тут блок-схема, и точка. Может, она больше годилась, когда не было структурного программирования…

Гуглите GRISU2 — и, возможно, переделайте этот код под свои нужды.
Он работает на целой арифметике и делает вот что: находит самое круглое десятичное число, переводимое в компьютерное дробное x.

Допустим, мне приходилось добавлять такое.
1. В случае не очень большого числа, большего 1/относительная_погрешность — поднять точность до единиц.
Например, переходить в экспоненциальный формат, когда у нас больше 5 цифр, а точность 3 цифры — то 0,00123, 0,0123, 0,123, 1,23, 12,3, 123, 1234, 12345, 1,23e5.

2. Большее из абсолютной и относительной погрешности.
Если у нас ещё две цифры абсолютной погрешности — то 0, 0,01, 0,12, 1,23, 12,3…

3. Формат с фиксированной длиной дробной части по принципу «всё или ничего».
С теми же двумя цифрами абсолютной погрешности — 0, 0,01, 0,12, 1,23, 12,34, 123…

4. Работу с локалями.

Выяснилось, что на компьютерах с разрядностью 16 и более бит минимальной единицей памяти стоит делать всё равно 8-битный байт: это сильно упрощает работу с узкими типами данных, как в памяти, так и на вводе-выводе. Например, канал RGB8 или кодовая единица UTF-8 — байт. Считаем для простоты, что разрядность 16, порядок Intel.

Чтобы загрузить 2-байтовое число в 2-байтовый регистр, есть ДВА варианта.
1. ОЗУ, кэш и другие устройства хранения передают нижний байт данных на нижний байт шины, верхний, соответственно, на верхний.
2. Байты, чьи номера кратны двум, соединяются только с нижним байтом шины, не кратные — только с верхним. А уж процессор как-то разбирает, что делать, если двухбайтовое число сидит по нечётному адресу и считывается за два обращения к шине.

Более простым оказался второй подход: он упрощает схемотехнику всех сидящих на шине, кроме процессора. В частности, дешифраторы становятся на 1 бит меньше, и упрощается топология. А процессор — в нём и так микропрограммное управление, и в нём и так до хрена соединений, и если обратился к байту (!) по адресу условно 4, вероятно, скоро потребуется адрес 5 и его один хрен стоит закэшировать.

Но это значит, что доступ к 2-байтовым числам по нечётному адресу (1-2, 3-4, 5-6) будет медленнее, чем по чётному (0-1, 2-3, 4-5). И потому по умолчанию двухбайтовые числа располагаются именно по ЧЁТНЫМ адресам, и структура { char a; short b; char c; } будет иметь длину 6 байт (0 — a, 1 — выравнивание, 2,3 — b, 4 — c, 5 — выравнивание), а структура { short b; char a; char c; } — всего 4 байта (всё упаковано плотно).

Но это приводит к двум вещам.
1. Если нужно сочетать скорость и компактность, надо чётко выравнивать структуры данных. Обычно подобная ручная оптимизация делается для мелких частых структур.
2. Если кусок памяти подготавливается в памяти, а потом отправляется на устройство, надо принудительно отключить выравнивание. Если в предыдущем примере формат файла так устроен, что байт 0 — a, байты 1 и 2 — b, байт 3 — c, то можно написать

#include <iostream>

struct Q1 { char a; short b; char c; };
struct __attribute__ ((packed)) Q2 { char a; short b; char c; };

int main()
{
    std::cout << sizeof(Q1) << ' ' << sizeof(Q2) << '\n';   // 6 4
}

Q1 (или более оптимизированную short-char-char) использовать для хранения в памяти, а Q2 — для записи в файл, раз уж у него такой формат.

Да, почему компилятор сам этого не делает? Это нарушает совместимость компиляторов. В Си++ до 20 включительно он имел право кое-что переставить, если в struct/class были поля с разными правами доступа (но никто по факту не делал), в 23+ больше не имеет права.

Ну а алгоритм прост.
1. Длина := 0, выравнивание := 1
2. Для каждого поля: позиция := длина, округлённая по выравниванию[i]; длина := позиция+длина[i]; выравнивание := max{выравнивание; выравнивание[i]}
3. Общая длина := длина, округлённая по общему выравниванию

Существует очень простой способ уменьшить выравнивание: отсортировать поля по убыванию выравнивания.

Для того же Q1:
0. Длина = 0, выравнивание = 1
1. char a: длина округляется до 0, затем 1, выравнивание = 1
2. short b: длина округляется до 2, затем 4, выравнивание = 2
3. char c: длина округляется до 4, затем 5, выравнивание = 2
4. Общая длина округляется до 6. Ну а выравнивание = 2