Вопрос «Что происходит, когда пользователь вводит URL в браузере?» мы на собеседованиях больше НЕ задаём.

Кандидат сегодня был очень напористый. Он поставил себе цель рассказать вообще всё!

За первые 20 минут он рассказал, как сигналы с клавиатуры передаются в операционную систему и как происходит парсинг url в браузерах. Я пытался его остановить, но он всё же прочитал небольшую лекцию по модели OSI. И даже для наглядности обжал витую пару прямо во время собеседования. Ещё час он рассказывал про устройство DNS и детали работы WiFi сетей...

Собеседование закончилось 3 часа назад. А он продолжает писать нам на почту: про SSL/TLS Handshake, DOM, рендеринг, кеш, CSSOM, алгоритмы сжатия.
#найм

#game #meme про DOOM

#prog #article

Memory Unsafety is an Attitude Problem

<...>

That’s not to say memory safety isn’t important, it is. But lacking security is ultimately an attitude problem. If developers don’t care about it, forcing onto them a memory safe language will not accomplish anything. They’ll screw up some other way.

First make them care, then make it easy for them to do the right thing.

Впрочем, попенять статью можно за методику для подкрепления некоторых аргументов (комментарии на реддите? Серьёзно?)

— Я тебе кинул ссылку в запрещённой соцсети.
— В которой из?

Парашут було винайдено в 1783-му
Люди до 1783-го:

#prog #cpp

В стандартной библиотеке C++ есть unordered контейнеры, которые для проверки принадлежности элементов контейнеру используют хэш-функции (помимо равенства, разумеется). Для того, чтобы хэшировать значение, нужно знать, как это делается.

В C++ операции хеширования можно переопределять для конкретных контейнеров (это один из шаблонных параметров), но по умолчанию используется std::hash. Для того, чтобы определить операцию хеширования для своего типа, нужно написать специализацию std::hash для своего типа (обязательно в пространстве имён std) и написать свою реализацию operator(), которая будет принимать хэшируемый объект и возвращать std::size_t в качестве результата.

Пусть у нас вот такой простой тип:

struct Point {
    int x;
    int y;
};

Попробуем сделать его хешируемым:

#include <cstddef>
#include <functional>

template <> struct std::hash<Point> {
    std::size_t operator()(const Point& p) {
        // а как...
    }
};

И вот тут мы сталкиваемся с проблемой: при условии, что у нас все поля хэшируемые, как нам получить хэш от всех них? Увы, std тут вообще никак не помогает. Максимум, что могут предложить на просторах интернета — это использовать boost::hash_combine (это даже рекомендуют на cppreference.com). Мало того, что тащить буст ради этого не хочется, так ещё и комбинирование происходит на уровне готовых хэшей. Это фактически приводит к двойному хэшированию, что обычно на качестве хэш-функции сказывается не в лучшую сторону.

В теории можно было бы организовать разделение на саму хэш-функцию и на описание того, какие и в каком порядке поля типа хэшируются... То есть сделать так, как в Rust. И это даже предлагали сделать для C++ в предложении N3980 aka Types Don't Know #. И подано это предложение было... 24 мая 2014 года. То есть десять лет назад, да. А воз и ныне там.

Я написал очень длинный и очень интересный текст про Юникод. Поскольку в Telegram пост такого размера не помещается, выложил на сайт:

https://blo.gepar.do/v0/unicode.html

Все бегом читать :)

Однажды ты спросишь меня, что у меня на первом месте: ты или программирование. Я отвечу "программирование". И ты уйдёшь, так и не узнав, что я допустил ошибку на единицу и на первом месте — ты.

А программирование — на нулевом.

#лингво

Серия постов про изменение лексики в новостях России.

t.iss.one/anthro_fun/2882

#prog

GPU — вещь своеобразная, из-за отличной от CPU архитектуры преобразования кода имеют не самые очевидные последствия.

На странице Check if your performance intuition still works with CUDA перечислено несколько вопросов, каждый из которых демонстрирует два куска кода и предлагает угадать, насколько отличаются их производительность. Догадку потом можно проверить.

Учтите, изменения могут быть в обе стороны.

#prog #cpp

doctest is a new C++ testing framework but is by far the fastest both in compile times (by orders of magnitude) and runtime compared to other feature-rich alternatives. It brings the ability of compiled languages such as D / Rust / Nim to have tests written directly in the production code thanks to a fast, transparent and flexible test runner with a clean interface.

Советую также посмотреть, чем отличается от прочих фреймворков для тестирования в C++.

TIL что для #cpp есть предложение закрепить в стандарте тот факт, что в байте ровно 8 бит. Сейчас это не так: стандарт (и сишный тоже) требует, чтобы в char было минимум 8 бит, но точное их количество может быть больше, и это количество записано макросом CHAR_BIT из limits.h/climits.

https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to-hundreds.html

Ну и в догонку очень быстрый апдейт. Включить bound checks отразилось всего в 0.3% регрессии по всему C++ гугла в среднем. Чтобы было так мало, мы ждали пока FDO (feedback driven optimizers) возьмут новые профили. В итоге кто-то меньше, кто-то больше, но я был доволен результатом. Количество сегфолтов в проде стало на 30% меньше. Сегфолты по разным причинам бывают и из-за тестовых бинарей в том числе (другой метрики у нас нет, поэтому репортим что есть).

Мифические существа:

* Единороги
* Йети
* Пришельцы
* Модули в C++