The Saboteur! (ZX Spectrum, 1985). История создания

ниндзя прибывает на надувной лодке

Стоп, он же с дельтаплана спрыгивает!! Как сейчас помню, самый выгодный прыжок - 2 экрана пролетаем, на третьем спрыгиваем.

Играл в эту игру в детстве на ZX Spectrum, кучу времени убил, не умел нихрена играть конечно. Против охранников дрался всегда одинаково: сидел и в приседе долбил удар ногой, ничего другого не умел)) Сейчас когда детям прохожу все эти тройные четверные прыжки над шипами в Ori and the Blind Forest, только угораю над собой малолетним конечно.

«Чистый» код, ужасная производительность

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

Сказал человек, которому при изменении иерархии классов придётся руками искать и дополнять все эти гениальные switch statements в каждом подобном методе))

Как получать стипендию Тинькофф, зная лишь ChatGPT?

Значит закрыть существенные или иным способом закрыть возможность получать бесконечный фидбек. Я не считаю "успешной" систему, для получения правильного ответа в которой надо перебирать правдоподобные варианты бесконечно и бесплатно.

Как получать стипендию Тинькофф, зная лишь ChatGPT?

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

Делаем тесты закрытыми и до свидания "успешность" нейросети.

Meta* представила систему сборки Buck2

Все носятся с этой корректностью зависимостей (что изменение в файле должно стриггерить пересборку всего, что от него зависит), но на практике это может приводить к огромному оверхеду. Типичный случай: работаешь над небольшой библиотекой, непрерывно делая в ней много мелких изменений. Почти на каждое изменение компилируешь и запускаешь юнит-тест, чтобы убедиться в его правильности. Тест обычно маленький и собирается/запускается быстро. Но проблема, когда в масштабе всей системы сборки от этой библиотеки также зависит гигантский бинарник (основной продукт). "Корректные" системы сборки, вроде tup или buck2, будут пересобирать основной бинарник и вообще пол-проекта на каждое изменение библиотеки.

Почему десктопные приложения работают на веб-платформе?

Знать топовые термопопасты, знать как ее наносить, знать хорошие кулеры, корпуса , хорошие вентиляторы, хорошие видеокарты (и где их достать недорого), модели оперативки (и ее возможности разгона), модели блока питания (вы еще не устали) хренова туча проводов, которые мешаются постоянно. если системник на полу, то он отлично собирает пыль (а то и шерсть, если нет пылевых фильтров).

Пугалка какая-то неадекватная. А что будет, если я не топовую термопасту возьму, а обычную? Если не собираюсь ничего гнать? Если возьму любой массовый бренд? Что надо знать такого секретного по БП, кроме его мощности, разъёмов, формфактора, и что производитель не совсем полный китай? То же по памяти, знать что у памяти есть объём, тайминги и формфактор это прямо запредельно сложно?

Я года 4 назад собрал игровой ПК на базе китайской материнки Kllisre. Всё купил на Aliexpress. Никогда не разбирался особо в железе, просто погуглил гайды по китайскому железу. Вышел прекрасный бюджетный игровой комп, никаких нареканий.

Свой язык, или как я устал от ассемблера и С

но компа (тем более с виндой) пока что нет, делаю всё с телефона

ШТО

Флаги командной строки в C++

Тем не менее, если верить интернету, для обработки этих скромных флагов требуется как минимум один платформоспецифичный фреймворк или один заголовочный файл, скопированный у доктора Доббса (Dr. Dobb) где-то в 2003 году.

В glibc есть getopt

ChatGPT настолько плох в написании эссе, что преподаватели почти сразу замечают отсутствие смысла в тексте при проверке

что эссе, посвященное критике одной из работ Джудит Батлер, было резким, лязгающим

Статья тоже сгенерирована ChatGPT?

Как я приложение с Go на Rust переписывал

Стесняюсь спросить, зачем здесь асинхронщина с tokio? Если я правильно понял сценарий, то выполнить все запросы в цикле последовательно vs распараллелить никак не повлияет на результат теста, тк меряется сумма времён обработки запросов.

Rust быстрее всех, Miiao сделал замеры

Безотносительно проблем с адекватностью бенчмарка - вы всё это на калькуляторе что ли запускаете? oO
Ваша версия на C у меня выполняется за 0.3-0.4 сек а не за 10 секунд, на довольно слабой машине (Chromebook).

Дайте в глаз тому кто вам помогал оптимизировать C. Выигрыш от обращения по индексу вряд ли большой, зато о том чтобы over 9000 раз не делать puts в stdout никто не озаботился. Вот немного дополненный вариант с буферизацией, на моей машине он быстрее вашего примерно в 4 раза. Можно и ещё быстрее

#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <string.h>
#include <stdbool.h>

char* FB[] = {"", "Buzz\n", "Fizz\n", "FizzBuzz\n"};

char buffer[BUFSIZ];

char *buffer_tip = buffer;

void fb(int x) {
    bool fizz = x % 3 == 0;
    bool buzz = x % 5 == 0;
    unsigned int len;

    if (!fizz && !buzz) {
        len = sprintf(buffer_tip, "Other(%d)\n", x);
        buffer_tip += len;
    } else {
        len = (fizz && buzz) ? 9 : 5;
        memcpy(buffer_tip, FB[fizz << 1 | buzz], len);
        buffer_tip += len;
    }
}

int main() {
    clock_t start = clock();
    memset(buffer, 0, BUFSIZ);
    setvbuf(stdout, 0, _IOFBF, BUFSIZ);

    for (int i = 1; i <= 100000; i++) {
        fb(i);
        if ((buffer_tip - buffer)>= BUFSIZ - 20) {
            *buffer_tip = 0;
            puts(buffer);
            buffer_tip = buffer;
        }
    }
    printf("100000 iterations in %f seconds\n", (float) (clock() - start) / CLOCKS_PER_SEC);
}

Упрощённое руководство по работе с памятью Си

сам пол интернета прогуглил в их поиске, находя только призрачные объяснения, которые больше рассказывают о работе ПК, чем о программировании

Да в жизни не поверю, в интернете десятки, сотни учебников по си разного уровня, от фундаментальных до быстрого старта.

Я учил по книге Подбельский, Фомин "Программирование на языке Си", полностью ей доволен, но это было почти 20 лет назад, с тех пор могло появиться что-то получше.

Упрощённое руководство по работе с памятью Си

Убрать приветствие в начале? Убрать заключение?

Возможно проблема в середине поста, а не в его начале или конце?))

А также мб в том, что ваш пост это косноязычный пересказ первой главы про указатели практически любой книги и ценность её для аудитории равна примерно нулю?

Как написать 2D игру на C++ и чистом STL для терминала в Linux

Я знаю, что терминал не поддерживает изображения и канвас.

Это не совсем так. Как вам пингвинов в консоли рисуют при старте Linux. https://en.wikipedia.org/wiki/Linux_framebuffer

Можно было попробовать с xdg-open или fim

Нерелевантно. Xdg-open - это просто приложение-прослойка, запускающее просмотрщик файла (выбираемый юзером). Как правило этот просмотрщик не консольный, а графический, например feh или Eye of Gnome. Самостоятельной способности открывать изображение в терминале итд у xdg-open нет. Fim - уже ближе, это приложение для вывода графики в POSIX терминал через пресловутый framebuffer, но вам в любом случае нужно не приложение, а библиотека (API), тк вы пишете свою программу. Но ок, вы ниже говорите что будете выводить только текст и псевдографику.

Как получить событие нажатия на клавишу, я не смог разобраться (если кто знает поделитесь в комментариях)

Если вы пишете код не ядра, а прикладной программы (пространство пользователя), самый низкий уровень работы с клавиатурой, доступный вам, - это /dev/input. Это i/o устройство, предоставляемое ядром линукс и являющееся абстракцией над устройствами ввода. Там отражаются и все нажатия клавиш. Взаимодействовать с ним из кода на Си можно через заголовочный файл ядра линукс, linux/input.h, примерно так:

#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <linux/input.h>
#include <stdio.h>

int main(void)
{
    const char *dev = "/dev/input/event0";
    struct input_event ev;
    ssize_t n;
    int fd;

    fd = open(dev, O_RDONLY);
    if (fd == -1) {
        fprintf(stderr, "Cannot open %s: %s.\n", dev, strerror(errno));
        return EXIT_FAILURE;
    }

    while (1) {
        n = read(fd, &ev, sizeof ev);
        if (n == (ssize_t)-1) {
            if (errno == EINTR)
                continue;
            else
                break;
        } else
        if (n != sizeof ev) {
            errno = EIO;
            break;
        }

        if (ev.type == EV_KEY)
            printf("%d 0x%04x\n", ev.value, ev.code);
    }

    return 0;
}

Но на настолько низком уровне взаимодействовать с клавиатурой не стоит (если вы только не пишете кейлоггер или ещё какой низкоуровневый специальный софт), по следующим причинам:

• Право чтения /dev/input напрямую - это весьма неслабая привилегия. Простой юзер в линукс её лишён по соображениям безопасности (программу выше возможно запустить только от рута) тк иначе он сможет считывать с /dev/input ввод других юзеров.

• В приложении обычно важно знать не физическую нажимаемую клавишу, а её символ (keysym), интерпретируемый из скан-кода клавиши. Например если вы жмёте "я" в русской раскладке, то в /dev/input это то же самое событие, что и нажатие "z".

По приложению - имхо вы зря пишете цикл чтения клавиатурного ввода с нуля.
Упражнение в чём-то полезное, но проще воспользоваться консольным фреймворком. Канонический - ncurses, правда это C а не C++. Он берёт на себя создание event loop, диспетчеризацию событий от клавиатуры, отрисовку итд. Клавиатурный ввод будете читать через Ncurses API.

если кто знает как увеличить шрифт в терминале через C++ напишите в комменты

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

Стрёмное собеседование в Яндекс

Кастовать требуется так как указатель нельзя умножать на bool

Bool по стандарту при касте к целому даёт 0 или 1, так что умножать его на uintptr_t безопасно. И в любом случае длинное целое, отличное от 0 и какого-то из входных указателей, будет невалидным возвращаемым значением, а значит и нет смысла расширять тип.

Из условия не следует что изначальные списки не отсортированы.

В условии ничего не сказано про отсортированность, значит в общем случае входные данные не сортированы.

Стрёмное собеседование в Яндекс

Адовое оперирование условиями через целочисленную арифметику. Если у вас за спиной стоит мужик с пистолетом, который выстрелит если вы используете if, дайте знак.

Зачем кастовать все указатели к ull?

Приведена функция, сливающая 2 уже отсортированных списка. Это не всё решение, а только его часть.

Про Vim " Горячие клавиши

Зря заморачиваетесь совместимостью с вимом на чужих и новых машинах. Колбасьте конфиг как хотите, если видите что назрела в этом необходимость.
Говорю как автор раскладки модальных команд, совпадающей со стандартным конфигом Vim только по hjkl.

Полезен ли темный режим для глаз?

+1. Ожидал в теме упоминания важного вопроса контрастности темы и не увидел. Автор разобрался в вопросе весьма поверхностно, авторы исследования видимо тоже

Rust в стартапе: поучительная история

Странные ребята. Переходят на экзотический язык во имя личных пристрастий. Бизнес за такое бьёт по рукам очень сильно. У меня на работе есть определённая свобода в выборе стека технологий для команды, но даже при своём пристрастии к Rust я никогда не выберу его для прода вместо например C++ в команде, пишущей на плюсах, потому что это означает гемор с обучением, наймом разработчиков в будущем, плюс непрерывные траты усилий в код-ревью "чтобы люди с опытом в C++ не писали на Rust как на C++", плюс ряд прочих проблем, по большей части нетехнических.

Но раз уж команда авторов взялась делать всё на расте, непонятно откуда эти проблемы с возросшим временем разработки. Не знаю как в крудостроении, но у нас 90% времени занимают бесконечные обсуждения поведения, и только 10% написание кода, причём кода в стиле достаточно туповатого ООП, который будет выглядеть плюс-минус одинаково что на C++ что на Rust что на Python, и потребует примерно одинакового времени реализации на различных языках. Возможно они полезли в асинхронщину.

По сравнению, скажем, с Go, библиотеки и экосистема документаций Rust невероятно незрелы. Преимущество Go заключалось в том, что его разрабатывала и поддерживала целая специальная команда

Всё там прекрасно документировано. У Rust Foundation тоже выделенная команда тех. писателей и та же std и ряд стандартных крейтов документированы ими вдоль и поперёк. Подозреваю, что автор в основном пользуется крейтами и продуктами третьей стороны, тем же Actix, он хочет чтобы всё было документировано на том же уровне?

Возможности современного клавиатуростроения (программные)

Что такое autoshift и typedancing?