Adamos

если вам нужно чистое c++, то любая os предоставляет api: просто вбиваете в поисковик что-то вроде
"c++ windows create window" и получаете пачку ссылок на официальные мануалы и популистические статьи.

но это на самом деле путь в бездну. от себя могу порекомендовать фреймворк qt (он кроссплатформенный и его интерфейсы гораздо более соответствуют языку c++ (интерфейсы OS слииишком сишные))

а иконка на рабочем столе -- это просто специальный файл, говорящий выполнить определённую команду (как правило -- запуск экзешника) можете поэкспериментировать и руками посоздавать иконки на рабочем столе к вашим консольным играм.
Если же вас интересует, как сделать установщик -- то именно такие слова и рекомендую вбить в поисковик.
Я для своих плюсовых проектов обычно использую InnoSetup.

Есть вариант хранить как строку "1,2,3,4"

JSON

мне надо 100 записей в бд для 10 id'шников

И что? В чем проблема?

как-то не правильно это все

Читаем https://habr.com/ru/post/64524/

Однажды я на подобный вопрос уже отвечал, правда там вопрос был о кроссплатформенности, а не о трансляторах.

Какая разница между clang и GCC.
Разница большая. GCC обладает обширной поддержкой наследия идиом и конструкций из языка C, которые, вынужденно или по своей воле, поддерживает в современном C++.
VLA, тип по умолчанию, всевозможные изыски синтаксиса C. Это все GCC не глядя принимает за C++ код и позволяет трансляцию.
GCC даже сегодня многократно нарушает стандарты C++ просто потому что выбрал стратегию поддержки экзотической функциональности C в коде C++. Так же GCC не хвастается и скоростью поддержки стандартов C++.
В 2016 году Google полностью отказались от поддержки GCC в Android NDK из-за слишком плохой поддержки стандартов и слишком свободного следования стандартам C++. В этот момент GCC стал неконкурентоспособным относительно оставшихся двух самых широко используемых трансляторов.
Clang же, наоборот, сегодня считается, буквально, бастионом идеального следования стандартам C++. Clang точно поддерживает стандарты во всех деталях, максимально быстро интегрирует изменения и добавления стандартов, позволяет в самых первых рядах поиграться с функциональностью из драфтов следующего стандарта C++.
Clang обладает обширной системой статической и динамической проверки кода: богатый статический анализ, возможность подключения санитайзеров, поддержка C++ Core Guidelines, очень качественные отчеты об ошибках трансляции, хорошая скорость трансляции.
Это все ставит clang в предпочтение перед GCC на третьих для GCC платформах.

О полной совместимости между трансляторами.
Полная совместимость между трансляторами есть. Иначе я бы не мог делать то, что я делаю. А дело мое заключается в создании полностью кроссплатформенного кода, который однозначно собирается на всех целевых платформах и на всех них выполняется так же однозначно.
Полная совместимость между трансляторами заключается в строгом соответствии кода выбранному стандарту C++. Всё, точка. На этом к трансляторам требования заканчиваются.
Только тут есть небольшая проблема. Каждый транслятор по-своему поддерживает стандарт и по-своему реализует неоговоренные стандартом механики. Каждый транслятор имеет свои ошибки трансляции. И вскрывается это все именно в процессе работы над кроссплатформенным кодом.

Я в своей работе видел многое. Я видел как при смене GCC на clang люди хватались за голову и отказывались от последнего просто потому что он нашел горы нарушений стандарта, которые молча принимал GCC. Я видел как группа из 5 человек 3 месяца рефакторила код при переходе с MSVS2015 на MSVS2017 (т.е. просто при смене версии транслятора) просто потому что разработчики из рук вон плохо знают используемый ими стандарт C++.
Я видел ошибки в clang, приводящие к неверной генерации кода. Я видел ошибки в GCC, не позволяющие использовать его для кроссплатформенной сборки. Я видел ошибки в MSCL, в результате которых последний явно нарушает стандарт, а команда его разработки отказывается это исправлять потому что "иди нафиг".

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

/index.php?url=$1

$_GET['route']

Если вы что-то положили в левый карман штанов, бесполезно пытаться достать это из правого.

создадим тестовую площадку:

mkdir -p /tmp/TEST && touch "/tmp/TEST/backup-name-back-"{01..05}"-название_на_русском,_могут,_встречаться_(скобки,_точки,_запятые.)-"{10..13}-{100..104}".bak" && tree /tmp/TEST

получим 100 файлов бэкапа

теперь несколько однострочников
прописываем полный путь к папке где хранятся бэкапы и заодно закинем список для сравнения в переменную Т

DIR="/tmp/TEST"; T=$(ls $DIR/* |awk -F'[-.]' '{print $4" "$(NF-2)$(NF-1)";"$0}')

показать что останется после удаления

echo "$T" |sort -nr |sort -un |awk -F';' '{print $2}'

показать что удалиться

comm -3 <(echo "$T" |sort -n) <(echo "$T" |sort -nr |sort -un) |awk -F';' '{print $2}'

!!! удаляем !!!

rm $(comm -3 <(echo "$T" |sort -n) <(echo "$T" |sort -nr |sort -un) |awk -F';' '{print $2}')

по итогу получим:

$ tree /tmp/TEST
/tmp/TEST
├── backup-name-back-01-название_на_русском,_могут,_встречаться_(скобки,_точки,_запятые.)-13-104.bak
├── backup-name-back-02-название_на_русском,_могут,_встречаться_(скобки,_точки,_запятые.)-13-104.bak
├── backup-name-back-03-название_на_русском,_могут,_встречаться_(скобки,_точки,_запятые.)-13-104.bak
├── backup-name-back-04-название_на_русском,_могут,_встречаться_(скобки,_точки,_запятые.)-13-104.bak
└── backup-name-back-05-название_на_русском,_могут,_встречаться_(скобки,_точки,_запятые.)-13-104.bak

0 directories, 5 files

Фундаментальная проблема - в игрострой стоит очередь фанатов с горящими глазами. Людей, которые пишут игры, играют в игры, моддят игры, хакают игры..., начиная с возраста, когда они смогли дотянуться до клавиатуры (как ваш покорный слуга). При этом, у них столько мотивации, что они могут сами поставить себе задачу, сами нагуглить все, что нужно (Спасибо дяде Немнюгину за его учебник. Это все что нужно знать о DOS, чтобы закодить dOOm) и сами все напишут и нарисуют (работая над этим сутками. Не потому что над душей стоит босс с воплями о лишении премии, а потому что им это интересно).

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

В играх есть много специализаций программирования - хотите графику, придется учить одно (причем на 2d и 3d это одно будет разное), хотите игровую логику и скриптинг - это номер два, хотите системную часть и бэкенд - это будет третье.

Для универсального развития, нужно начинать с простых фиговин вроде тетриса, арканоида, бильярда и прочего (в которых однако есть все столпы игростроя - графика + логика + системный движок, можно и добавить сеть, если подумать) и потом наращивать сложность - делать платформер или RTS.

Любая, какую осилите.

Универсальный способ удаления программ в linux, установленных с помощью пакетного менеджера
1. определить как называется пакет (его настоящее название а не то что подменяет отвратительный Центр Приложений)
можно посмотреть в самом центре приложений снизу в описании будет написано что то типа

GHex is a hex editor for the GNOME desktop.

можно забить в поиск synaptic или консольной apt свое название gnome hex editor и в полученном списке ищем что то похожее
p.s.

либо смотрим свойства ярлыка запуска, там будет команда, что то типа
ghex %F
это имя приложения не обязательно будет совпадать с именем пакета, поэтому для гарантии можно поискать среди установленных
определяем путь к запускаемому приложению если в ярлыке не указан

# whereis ghex
ghex: /usr/bin/ghex /usr/share/man/man1/ghex.1.gz

затем определяем имя пакета по имени файла (не обязательно запускаемого)

# dpkg -S /usr/bin/ghex
ghex: /usr/bin/ghex

тут слева имя пакета, справа имя файла (может быть что один и тот же файл есть в разных пакетах
p.s. если поиск пакета по файлу не сработал, значит данный пакет не установлен, если не говорить в разрезе задачи удаления а просто определить в каком пакете нужный файл, нужно установить утилиту apt-file, она загрузит базу всех пакетов и позволит искать по ним (так же на сколько я знаю при установке bashcompletion при запуске неизвестного приложения будет выдаваться список пакетов где есть похожие по имени)

2. узнав имя пакета его можно удалить либо synaptic либо в консоли

apt remove ghex
или
apt purge ghex

вторая команда не только удалит пакет но и файлы настроек которые пользователь или программа за время работы понасоздавала

если что то идет не так, то нужно смотреть сообщения об ошибках
p.p.s. есть мощный консольный GUI для пакетного менеджера - aptitude, умеет много проблем разруливать

Lorem это латинский текст. Если сайт для русскоязычной категории можно взять Яндекс Рефераты. Там тоже текст бессмысленный, но на русском языке и выглядит как настоящий. Можно выбрать тему.

Заголовки можно придумать тематические.