Mercury13

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

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

Если f(n) ≡ 0 (неотрицальна → асимптотически неотрицательна), то вполне срабатывает, что 0=Θ(0).
То есть по нашему определению множества Θ, если оно непустое, то g обязана быть асимптотически неотрицательной — но не обязательно асимптотически положительной.

Разрешите вмешаться. Штатное процессорное выравнивание — 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) надо обязательно сразу же присвоить и дальше не перенаправлять. Самое то, когда функция принимает или отдаёт «стрелочку» на кусок памяти, и стрелочка никогда не может указывать в пустоту.

1. Умножим наш point на r.
2. Повернём (rx, ry, 1) так, чтобы (0,0,1) → d. Ищите эту матрицу где-то в движке: вы имитируете разброс оружия — так что это будет матрица поворотов камеры. Если прицел не в центре экрана (бывает для всяких там гранатомётов) — применяем ту же самую поправку. Если видовая матрица и матрица наводки развязаны (бывает в сетевой игре) — то брать матрицу наводки, понятно.
3. Снова нормализуем.

Должно — если, конечно, Type-C даёт HDMI-видеовыход. Глючья в этом плане столько, что переходник HDMI→VGA, например, на одном мониторе работает и на другом нет. Но это именно глючьё непредсказуемое.

DVI+, как я его называю — потому что на цифровом DVI виден минус и на полном плюс — может, сделан, потому что попался такой разъём, и аналоговые штыри никуда не подключены. Ниже вероятность, что и VGA тоже поддерживается.

Что значит «подключить файл»?
Загрузить файл данных? 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.

Программа туда не уместится, если не предусмотрено способа разбить её пополам. Перемещение происходит, если её адрес по умолчанию чем-то не нравится: или занят, или надо утрамбовать адреса плотнее (было важно в эпоху DOS), или…

А пока — три важных ремарки.
1. В пользовательском пространстве у нас 2 гигабайта или больше виртуальной памяти, и она условно «пуста»: в любых адресах этой памяти можно разместить что угодно. Но если мы обратимся к отсутствующей странице, получим аварийный останов — такова уж издержка виртуальности. Сначала надо обратиться к системному менеджеру памяти, и он выдаст рабочий диапазон адресов.
2. Программа перемещается посегментно.
3. Есть два главных способа перемещения программы: адресация от IP и relocations.

Адресация от IP работает, понятное дело, если исходный и целевой адрес в одном сегменте. По какому адресу ни располагай сегмент — адреса от IP менять не надо. В x86, НЯЗ, она работает в одном-единственном случае: короткие переходы (±127 байтов). Ветвления все короткие, а если нужно ветвиться далеко — ответвляется на безусловный переход, который уносит далеко-далеко.

В x64 режим адресации от IP есть во всех обращениях к памяти, переходах и вызовах, но только на ±2Г (точно не в курсе).

Во всех версиях x86 базовый адрес при адресации от IP — это конец текущей команды, не начало.

Relocations — это ремарки: сегмент 1 рассчитан на базовый адрес 12. Если он другой — подкорректируй адреса 34 и 56. Независимо от метода адресации — от IP или абсолютного. Если сегмент загрузился не по штатному адресу — например, 23 — к числам по адресам 34 и 56 прибавляем разницу 11. Скажем, было 78, стало 89.

В архитектурах с сегментной памятью (x86-16) эта самая сегментная память — также метод перемещения программы. Старый добрый COM-файл имел абсолютные адреса, но только от начала текущего сегмента — и представлял собой исключительно машинный код, загружаемый по адресу не то 128, не то 256 (вот не помню). А перемещение его по памяти сводится к установке нужных значений в сегментные регистры SS/CS/DS/ES.
(Да, *.COM не имел вообще никакого формата, это просто куча кода и данных, которая 1:1 грузится в память.)

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

#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;
}

Если заработает — программных не должно быть. Из аппаратных — только шум на определённых режимах/изображениях, но это уже вопрос качества питающей обвязки. Чаще такое бывает на настольных мониторах, чем на ноутах.
Просто прописывают список поддерживаемых режимов — в VGA на это пустили неиспользуемый штырь, где на ноутах, не знаю. Просто лень: или совместимые 60, или максимальные 360, на что нужны промежуточные?