Mercury13

?language=russian недавно исчезло и никто не знает, что дальше. Вероятно, теперь личные настройки пользователя перебивают то, что поставил автор.
Ссылка на время — #t=1h23m34s.

Массовый INSERT всегда лучше multi_query. Хотя multi_query из нескольких таких INSERT’ов имеет право на жизнь.
Выигрыш по времени незначителен и сводится к тому, что разбор выражения происходит единожды. Сервер всё равно выполнит запросы один за другим.
Но multi_query может быть хорош, когда надо запустить несколько модифицирующих запросов (INSERT, UPDATE, DELETE) один за другим. Просто код смотрится лучше.
Когда в SQL-коде много подстановок, стоит обратить внимание на prepare. Это безопаснее и позволит использовать кэш компилированных запросов.

К сожалению, нет. Звуковой нужно ОЗУ, чтобы брать участки волны, и процессор, чтобы вызывать прерывания. Другими словами, переходник будет небольшим компьютером.
Может, в режиме низкой задержки всё не так страшно (не знаком с ним), но системная шина и последовательная шина для периферии — слишком разные интерфейсы.

Скорее всего, нет, однако стоит посмотреть, какое отношение эта самая линейная алгебра имеет к векторам, прямым и плоскостям в 2D и 3D. Это будет важно в вашей дальнейшей прогерской жизни.

Такой механизм называется «одна единица компиляции» и вполне имеет право на жизнь: на одном процессоре время полной сборки будет наименьшим, потому так распространяют некоторые библиотеки (SqLite, Google Test). Правда,
игра — обычно масштабный проект, и чем больше будет кода, тем дольше нужно компилировать, чтобы проверить изменения.

Потому код обычно разбрасывают по единицам компиляции (*.cpp) в соответствии с его внутренней логикой, и к каждой единице (кроме точки входа) приписывают хедер (*.h), который показывает, что эта единица делает. Повторяю, только описывает, что делает — весь код в CPP. И в большинстве случаев самый длинный этап сборки — линковка (особенно с оптимизацией по ходу линковки aka LTO).

Единственное, что в 80% случаев не получается закинуть в CPP — это шаблоны.

Чтобы один хедер не подключался несколько раз — есть include guard. Правда, если вы не продумали зависимость между хедерами, может попасться циклическое включение — это вредно, но лишь потому, что программа может не скомпилироваться.

Чтобы не было циклических включений, для сохранения скорее всего потребуются два хедера: один отвечает за собственно процедуру сохранения и подключается к одному-единственному модулю — системе меню. Второй — за какие-то общие функции, которые позволяют сохраняться в абстрактный поток плиточному фону, снаряду, монстру… Называется как-нибудь SaveUtils.h и подключается повсюду.

(Примечание. И SqLite, и Google Test разрабатывались по традиционной схеме, с проектом из кучи CPP. SqLite собирается в один большой *.c автоматикой, и я даже качал традиционный код — на 5-метровом файле некоторые версии Embarcadero вылетали с нехваткой памяти. В Google Test есть файл all.cpp или что-то подобное, в котором #include остальных CPP — пользователь подключает в проект all.cpp, и библиотека отнимает минимум его времени.

Аксиомы доказать невозможно. Но можно сделать одну классную вещь. А именно — построить модель теории. Другими словами: найти в соседней теории, которой вы «доверяете» (например, теории действительных чисел или евклидовой геометрии) такие «точки» и «прямые», чтобы они отвечали всем аксиомам. И эти аксиомы нужно доказывать, чтобы показать, что, например, R² с «точками» (x,y) и «прямыми» ax+by+c=0 — действительно модель евклидовой геометрии.

Да, и математики часто, но некорректно говорят: «Векторное пространство — это совокупность из основного множества X, числового поля K, операций x+y и x·k такая, что отвечает аксиомам…» Вообще-то, требованиям, а не аксиомам, и эти «аксиомы» нужно доказывать, чтобы доказать, что, например, R² — векторное пространство над полем R.

Да, а что же Евклид? А Евклид, вероятно, сам не догадывался, какую классную штуку он придумал. К тому же исчерпывающую аксиоматику евклидовой геометрии придумали ≈1900. Страшна, как чёрт, шесть базовых понятий… Но это зачастую и не требуется, чтобы решать задачи — надо как-то определить объект изучения и начать доказывать теорему за теоремой. Большинство из нас, даже выпускники вуза, не знают ни теорию действительного числа, ни аксиоматику Пеано для арифметики, ни аксиоматику для теории множеств…

example.com — это домен = доменное имя
https://example.com — это уже URL, состоящий из…

• схемы URL’а (протокола, типа ресурса) https:
  
• и специфичных для протокола HTTP(s) вещей, к коим относятся
  
  • знак домена //
    
  • домен example.com

Когда мы пишем в браузере example.com/path, система понимает, что надо добавить схему и знак домена, но упаси бог такое писать в HTML — получится что-то типа http://local.example.net/example.com/path.

Это другая штука, имеющая опосредованное отношение к keep-alive. Это загрузка информации в несколько потоков.

Почему шесть соединений, а не пять — другой вопрос. Я бы предположил вот что. Браузер разобрал index.html и увидел там картинку. Создаём новое HTTP-соединение (нешифрованное) — два пинга спустя поехали данные. Задействуем имеющееся — один пинг спустя. С небольшим пингом браузер просто подумал, что быстрее будет вот так. А может, браузер просто туп и если мы укладываемся в количество соединений с одним сервером — создаём новые, да и всё.

А вот то, что все картинки в разных потоках — это верно. Если считать скорость сети «бесконечной», для каждой из них информация пойдёт с запозданием в два пинга. Работай мы в один поток — первая пришла бы с запозданием в 2 пинга, вторая в 3 пинга, третья в 4 пинга… А вот протоколы SPDY и HTTP/2 позволяют сказать: «Дай мне картинки А, Б и В»,— и они все, ОДНИМ СОЕДИНЕНИЕМ, придут с запозданием в два пинга.

Другими словами:
HTTP (все метки времени — когда они были посланы с клиента/приняты клиентом):
К: SYN: (+0 пингов)
С: SYN+ACK (+1 пинг)
К: ACK (+1 пинг)
К: Запрос 1 (+1 пинг)
С: Ответ 1 (+2 пинга)
К: Запрос 2 (+2 пинга)
С: Ответ 2 (+3 пинга)

HTTP2:
К: SYN: (+0 пингов)
С: SYN+ACK (+1 пинг)
К: ACK (+1 пинг)
К: Запросы 1, 2 (+1 пинг)
С: Ответы 1, 2 (+2 пинга)

На реальных «не очень быстрых» соединениях играют роль не только пинги, но и скорость передачи. Тогда картинки начнут появляться не по одной, а по восемь (или сколько там соединений) — это тоже может повлиять на впечатление от браузера. К тому же если случился затор на шлюзе локальной сети — тогда, если одно соединение забарахлит, другие что-то привезут. А если сеть не очень хорошо сконфигурирована — это ещё и ввосьмеро увеличит скорость передачи (реально в начале 2000-х качал в универе 10-мегабайтный драйвер за перемену в 100 потоков).

Я бы посоветовал сделать штук двадцать картинок — и тогда начнётся повторное использование имеющихся соединений.

Главная причина: int — ключевое слово Си++, а string — нет.
Система программирования может подсвечивать стандартные контейнеры STL другим цветом. Вот, например, скриншот Code::Blocks.

Видите, ключевое слово char синее, а стандартный объект STL std::string — зелёный.
(Да, специалисты, вижу, что на экране результат не слишком удачного рефакторинга. Для специализированной утилиты в шестьсот строк, думаю, покатит.)

Си++ и Qt сделаны кроссплатформенными, то есть скрывают разницу между платформами где-то у себя внутри.

Компиляторы перестают поддерживать ту или иную ОС последними. Процессор-то остаётся тем же — ну и норма. Думаю, скомпилированное MinGW (без Qt) даже на 98 запустится.

Так что разницы не будет, если весь наш софт будет работать на хост-ОС и все наши библиотеки будут запускаться на целевой ОС. А вот с поддержкой беда, версия 5.6 объявлена последней, которая официально поддерживает XP как хост-, и 5.7 — XP как целевую. Работает всё-таки? Вот и классно!

Да. Раз уж в Qt есть три системы сборки — могут возникнуть вопросы, когда нужно редактировать руками pro-файл. Большинство руководств предполагают QMake. Я держусь на нём, потому что так и не выяснил, как QBS работает с многоядерными процессорами. Двести файлов в проекте — сами понимаете.

Движок можно даже самописный. Считается, что движок — дело тяжёлое, но для таких игр это не так.
Начать надо со среза механики и предельно упрощённого движка на чём угодно (хоть в консоли, хоть на Java AWT).

UPD. Раз у нас нормальное распределение — надо построить нормальное распределение, оцененное по методу наивысшего правдоподобия.
А затем вычислить F⁻¹(0,05), F⁻¹(0,1), …, F⁻¹(0,95).

Будет подставлено ИМЯ ПЕРЕМЕННОЙ b, а чему она равна — это уже другой вопрос. Никаких проблем не должно быть.

#include <iostream>

#define CHECK(a,b) \
   if ((a) == (b))     \
      std::cout << "Equal" << std::endl;  \
      else std::cout << "Inequal" << std::endl;

int main()
{
    for (int i = 0; i < 5; ++i) {
        CHECK (i, 2)
    }
    return 0;
}

После препроцессирования программа превратится вот во что…

int main()
{
    for (int i = 0; i < 5; ++i) {
        if ((i) == (2))
           std::cout << "Equal" << std::endl;
           else std::cout << "Inequal" << std::endl;
    }
    return 0;
}

Вывод в консоли

Inequal
Inequal
Equal
Inequal
Inequal

Разумеется, нехороши ситуации, когда в макрос подставляется код с побочными эффектами, но это другой вопрос.

Без DirectX или OpenGL никуды, это самые низкоуровневые API, дающие как скорость, так и мало-мальскую совместимость.
Советую использовать тонкую обёртку над всем этим добром вроде SDL: думаю, интереснее будет писать игру, чем решать проблемы с Alt-Tab.
А так, если задаться целью, можно небольшой движок сделать за неделю-две. Остальное лучше оставить на багофиксы и наполнение.
Не советую работать с гексами, и вот почему. Гексы сразу же подразумевают, что игра пошаговая. ИИ замучитесь писать!

И ещё. Систему анимации-то можно за это время написать, но сделать хороший редактор анимаций сложнее. Каждый кадр — отдельная картинка, и всё?