Максимально простая игра на C++ (в консоли)

Можно узнать зачем? Я такого стиля ни разу не видел до этой статьи и, честно, не вижу ни одной причины так писать. Это усложняет чтение и заставляет читающего думать, зачем автор добавил пару лишних скобок

Бардак в GNOME — это не случайность

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

Максимально простая игра на C++ (в консоли)

На будущее: лучше так не делать, потому что так никто не пишет.

Бардак в GNOME — это не случайность

Я бы ещё кое-что добавил к вашему списку:

Если в системе недоступен OpenGL 3.0, то GNOME работает в режиме
программного рендеринга, а mutter полностью отключает все оконные
анимации, что может быть проблематично, ведь юзабилити GNOME сильно
зависит от его анимаций. Почему mutter не может откатиться к OpenGL 2.0
или даже к режиму CPU для обработки этих простых анимаций? Сложно
поверить, что их анимации сложнее, чем в Quake 2 или Unreal Tournament —
играх, работавших в программном рендеринге на CPU конца 90-х.

Почему разработчики ради 2.5 динозавров с видеокартами из 2008 должны тратить время на поддержку двух версий OpenGL или вообще использовать только вторую?

Бардак в GNOME — это не случайность

Надо будет приглядеться, а то неоднородность я не особо заметил (кроме диспетчера устройств ничего в голову не приходит).

Бардак в GNOME — это не случайность

А что не так с виндовым интерфейсом? Я не особо часто им пользуюсь, но когда пользуюсь, проблем обычно не возникает (только приходится горячие клавиши вспоминать)

Максимально простая игра на C++ (в консоли)

Не заметил, что комментарий создался фигово:

        {
            for(int m = 6; m < 14; m++)
            {
                SetXY(15,m); cout <<"*";
            }
        }
        {
            for(int m = 6; m < 14; m++)
            {
                SetXY(30,m); cout <<"*";
            }
        }

Не понятно, только, для какого порядка. Или это была шутка?

UPD: хабр заглючил, у меня предыдущий коммент был в одну строку, я поэтому новый создал.

Максимально простая игра на C++ (в консоли)

_kbhit() и _getch уже не переносимы, собственно остальные функции по работе с консолью тоже

Максимально простая игра на C++ (в консоли)

Кстати, а в чём смысл оборачивать циклы for в фигурные скобки?

{ // я про эти
    for(int m = 19; m < 26 ;m++)
    {
        SetXY(m,6); cout <<"_";
    }
}

Бардак в GNOME — это не случайность

В целом да, но надо учитывать, что GUI тулкитов не так много (Gtk, Qt и WxWidgets), если Gtk испортится в будущем (пока не замечал существенных багов в Gtk приложениях, которые использую), будет печально, ибо придётся искать аналоги куче приложений или авторам этих приложений придётся всё переписывать

Почему проверять результат вызова malloc c помощью assert плохая идея

Go и Kotlin точно не являются альтернативами Си, т.к. у них есть GC. Rust вполне можно использовать, как замену.

То есть - это по большей части проблема Си и чуть меньше C++ (где правильно выделять память через оператор new.

Насколько знаю, сейчас уже принято использовать unique_ptr и shared_ptr вместо чистого new, так что даже об освобождении думать не нужно. В целом некоторые чисто сишные проблемы в C++ уже решили, так что я бы его выбрал, но там всё равно есть свои заморочки с UB, такие же, как в си

Бардак в GNOME — это не случайность

Мышки плакали, кололись, но продолжали страдать, чтобы быть нетакусями

Максимально простая игра на C++ (в консоли)

Или ImGui. Он как раз на C++ написан, в отличие от nuklear, который на си.

Интерпретатор Brainfuck на Brainfuck

На эту роль больше whitespace подходит, там в отличие от bf стековая машина.

Почему проверять результат вызова malloc c помощью assert плохая идея

Я оспорил факт, что можно попортить данные других приложений или даже ОС. То, что можно испортить данные приложения, в котором нет проверки на NULL (при условии, что его не убьёт oomkiller) я не оспаривал

Почему проверять результат вызова malloc c помощью assert плохая идея

Может быть и так, но какие есть альтернативы?

Почему проверять результат вызова malloc c помощью assert плохая идея

А с чего вы взяли, что именно я вам минус поставил? Ну а так за то, что ложную информацию распространяете

Почему проверять результат вызова malloc c помощью assert плохая идея

Но тут дело в том, что даже простое приложение без какой-либо проверки
не упав сразу может нанести вред другим компонентам и приложениям ОС
изменив их память!

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

Почему проверять результат вызова malloc c помощью assert плохая идея

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

Кодер умеет в пыху. Какие словечки бесят айтишников

Дико бесит, когда Android называют «Андрюшей». Особенно учитывая, что меня зовут Андрей.

Меня тоже. Все же знают, что правильно называть Android ведром