Прим. Wunder Fund: В статье описаны базовые подходы к работе с корутинами в 20м стандарте С++, на паре практических примеров разобраны шаблоны классов для промисов и фьючеров. По нашему скромному мнению, можно было бы реализовать и поизящнее. Приходите к нам работать, если имеете сильные мнения о корутинах хе-хе.

Возникает такое ощущение, что тема реализации корутин в C++20 окутана серьёзной неопределённостью. Полагаю, это так из-за того, что в проекте технической спецификации C++20 сказано, что работа над механизмами корутин всё ещё ведётся, в результате в данный момент нельзя ожидать полной поддержки этих механизмов компиляторами и стандартной библиотекой.Множество проблем, вероятно, возникает из-за отсутствия официальной документации по работе с корутинами. Нам дали синтаксическую поддержку корутин в C++ (co_yield и co_return), но не всё то, что я счёл бы признаками их полной библиотечной поддержки. В стандартной библиотеке имеются хуки и базовый функционал поддержки корутин, но нам приходится самостоятельно встраивать всё это в наши собственные классы. Я ожидаю, что полная поддержка корутин-генераторов появится в C++23.

Если вы — Python- или C#-разработчик и ожидаете увидеть в C++ простую механику работы с корутинами, то вас ждёт разочарование, так как фреймворк общего назначения C++20 недоработан. Учитывая это, можно отметить, что в интернете имеется множество публикаций, в состав кода, обсуждаемого в которых, входит шаблонный класс, поддерживающий корутины-генераторы. В этом материале вы найдёте шаблон корутины, применимый на практике, а также примеры кода. Всё это предваряется общими сведениями о корутинах.

В этой статье мы подробно разберем понятие сопрограмм (coroutines), их классификацию, детально рассмотрим реализацию, допущения и компромиссы, предлагаемые новым стандартом C++20.

В этом году на C++ Russia я рассказывал про API дизайн. Эта статья — пересказ и переосмысление моего доклада.

То, что я здесь расскажу, основано на моем личном опыте — про API дизайн я думаю уже лет 15, с того момента как в 2008м начал читать ревью библиотек на входе в boost (кстати, всем рекомендую).

В первой части я сфокусируюсь на базовых вещах, которые применимы практически к любому императивному языку программирования, не только к C++. Будет также часть 2, более приближенная собственно к C++, в которой я расскажу о некоторых фичах языка и стандартной библиотеки, которые помогут вам сделать ваши API еще лучше.

Здравствуйте, меня зовут Дмитрий Карловский и я… люблю гнать всякую странную дичь. Осторожно, после этого доклада у вас может появиться странное, но непреодолимое желание удалить все модульные и e2e тесты из вашего проекта, ибо они требуют много ресурсов, но дают мало профита.

Это — расшифровка выступления на TechLead Conf 2020. Вы можете посмотреть видео, прочитать как статью или открыть в интерфейсе проведения презентаций.

Представьте идеальный мир с бесконечными ресурсами, в котором можно сколько угодно линейно масштабироваться под нагрузку: просто доставлять серверы, диски, видеокарты, как только потребуется больше мощностей. Звучит хорошо? Только оказывается, что когда серверов 5 000 и дисков 100 000, то несколько из них обязательно находятся в состоянии maintenance или repair, куда их привели обстоятельства непреодолимой силы. И главная задача здесь — обеспечить доступность сервиса в условиях постоянных сбоев. 

В статье разберём, как построить отказоустойчивую платформу, с какими неочевидными corner cases может столкнуться сервис с UGC-контентом, а ещё — как жить в реальном, а не идеальном мире и оптимизировать железо. Чтобы раздавать 4 Тбит/с можно, конечно, использовать 400 серверов по 10 Гбит/с, но гораздо интереснее грамотно всё потюнить и выжать 100 Гбит/с с Java-сервера.  

На протяжении всей жизни мне приходится экономить вычислительные и сетевые ресурсы: сначала были компьютеры с 300 кГц (кило — не гига!) и 32 Кбайт RAM, интернет по dial-up. Потом я решал олимпиадные задачки. Теперь имею дело с терабайтами трафика и 50 млрд событий в сутки. И хотя современные телефоны в 1 000 раз мощнее любого оборудования двадцатилетней давности, я до сих пор оптимизирую. Думал даже, что это со мной что-то не так. Но потом понял, что все постоянно что-нибудь оптимизируют. 

Эта статья в меньшей степени о том, почему нужно бороться за производительность, и в большей о том, на что сейчас стоит заменить устаревший стек из JPEG, JSON, gzip и TCP — и как это сделать. 

Спойлер: у нас есть решение и мы его не только показываем — ссылки на open source в конце статьи.

Выбор правильной архитектуры для вашего веб-продукта — это важнейший вопрос, который необходимо решить, продумывая его разработку. Прежде всего, он должен быть масштабируемым и выдерживать высокие нагрузки. Особенно если вы делаете функциональный веб-сайт, сервис онлайн-бронирования или решение для электронной коммерции.

Помните "Черные Пятницы", которые так популярны среди людей? Знаете ли вы, что иногда сайты и веб-приложения не выдерживают такого огромного наплыва пользователей и в результате этого нередко теряют много денег?

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

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

На днях я наткнулся на одно любопытное видео.

Моей первой реакцией было Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще? отрицание и усталость, потому что всё это я уже слышу на протяжении лет пяти с разной интенсивностью в зависимости от текущих объектов хайпа. В этом посте я попытаюсь разобраться, что из сказанного в видео является правдой.

Утверждения:

1. Закон Мура больше не выполняется из-за фундаментальных физических ограничений ⇒ масштабирование нейросетевых моделей по вычислительному бюджету невозможно.

2. Нейросетевые модели внедряются слишком медленно.

3. Ответы нейросетевых моделей неконтролируемы и неинтерпретируемы.

Дальше обсудим каждое из них.

Это объект Pizza, там хранится инфа о латте, а заказали его в Restaurant или в Pizzeria? Неудобно? Максимально. Мы читаем код существенно больше, чем пишем. И хочется сразу понимать, что происходит, не играя в квесты «что имел в виду автор», «да как это работает» и «я снова ничего не понял». Без навыка давать хороший нейминг невозможно писать качественный и поддерживаемый код. Про нейминг говорят заодно, в рамках архитектуры и общих инженерных практик. В статье поговорим про него отдельно.

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

На сегодняшний день существует несколько тысяч языков программирования, каждый из которых создавался с определенной целью, пытаясь изменить и улучшить недостатки своих предшественников. Так, например, появился язык Kotlin, который был нацелен на замену Java в мобильной разработке. В 2010 году увидел свет язык Rust, разработчики которого пытались создать быстрый и безопасный язык, который закрывал бы многие недостатки C/C++.

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

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

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

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

За подробностями о сканировании пакетов npm и PyPI добро пожаловать под кат.

При поиске работы программистам часто приходится сталкиваться с алгоритмическим интервью. По моему опыту общения с людьми из индустрии ИТ я заметил, что многие считают, что алгоритмическая секция бинарна: либо алгоритм написан корректно за отведенное время, либо нет. На самом деле всё немного сложнее и во время интервью собеседующий обращает внимание на многие другие аспекты.

Я за свою карьеру имел возможность быть по обе стороны баррикад. С одной стороны я провёл сотни алгоритмических интервью в компаниях, где работал. С другой стороны сам успешно проходил такие интервью и получал оффер в Google, Facebook, Amazon, Uber, Yandex и Mail.Ru.

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

• std::mdspan
• std::flat_map
• std::flat_set
• freestanding
• std::print("Hello {}", "world")
• форматированный вывод ranges
• constexpr для bitset, to_chars/from_chars
• std::string::substr() &&
• import std;
• std::start_lifetime_as
• static operator()
• [[assume(x > 0)]];
• 16- и 128-битные float
• std::generator
• и очень много другого

Я думаю, не стоит никому объяснять, что такое выгорание, большинство периодически ходят по краю, рискуя упасть и окунуться в это состояние с головой. В двух словах выгорание — это поломка системы восстановления энергии в условиях продолжительного стресса.

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

У нас есть задача постоянно компилировать тонны плюсового кода. Наш проект — почти 200 000 cpp- и h-файлов, множество Git-веток, сотни разработчиков, десятки билд-агентов: его нельзя единожды скомпилировать, приходится перекомпилировать постоянно, параллельно, разные версии.

Наш проект необычный. Потому что эти 200 000 файлов — это результат автогенерации. Потому что пишем мы на PHP, а потом через KPHP все PHP-исходники превращаются в плюсы. Именно так разрабатывается бэкенд ВКонтакте.

Компилировать тысячи объектников долго. Локально это занимает много часов. Мы использовали distcc — но всё равно медленно. Мы даже пропатчили distcc для поддержки precompiled headers — но даже тогда медленно. И решили написать своё — чтоб стало, наконец, быстро.

В итоге мы написали замену distcc — компилятор nocc. Он не имеет никакого отношения к PHP и даже к KPHP, а просто предназначен для компиляции .cpp → .o в промышленных масштабах.

Это техническая статья про параллелизацию, демоны и специфику С++. Ссылки на GitHub и видео приложу в конце статьи.