Один из участников моего семинара в рамках CppCon 2018 спросил меня: «Может ли std::thread быть прерван (interrupted)?». Мой ответ тогда был - нет, но это уже не совсем так. С C++20 мы можем получить std::jthread (в итоге все таки получили - прим. переводчика).

Позвольте мне развить тему, поднятую на CppCon 2018. Во время перерыва в моем семинаре посвященному параллелизму я побеседовал с Николаем (Йосуттисом). Он спросил меня, что я думаю о новом предложении P0660: Cooperatively Interruptible Joining Thread. На тот момент я ничего не знал об этом предложении. Следует отметить, что Николай является одним из авторов этого предложения (наряду с Хербом Саттером и Энтони Уильямсом). Сегодняшняя статья посвящена будущему параллелизма в C++. Ниже я привел общую картину параллелизма в текущем и грядущем C++.

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

Система, описанная в статье, перевернет ваше представление об изучении языков. Я на это надеюсь. Но это случиться только если не спешить, читать внимательно и вдумчиво и связывать все тезисы между собой. Используйте систему 2 на полную катушку.

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

Мне в голову пришла идея: а что если получать доступ к элементам по индексу, не известному на этапе компиляции?

В C++ нет понятия "множество". Есть std::set, но это всё-таки конкретный контейнер. Есть функции для работы с упорядоченными диапазонами: merge, inplace_merge, includes, set_difference, set_intersection, set_symmetric_difference, set_union, но это алгоритмы, они не ленивые, и при вызове сразу вычисляют результат. К тому же они предназначены для работы строго с двумя диапазонами.

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

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

В публикации Ленивые итераторы и диапазоны в C++ я разбирал, что такое ленивые диапазоны.

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

Однако есть и классическая, более распространённая техника для борьбы с циклами — использование итераторов и диапазонов для ленивых операций над последовательностями. Всё это уже сто лет есть в Бусте и других сторонних библиотеках (к примеру, range-v3) и постепенно просачивается в стандартную библиотеку.

Хотя, в некотором смысле, и в стандартной библиотеке ленивые итераторы уже есть давно (см. std::reverse_iterator).

Данная публикация — это краткий ликбез о том, что такое ленивые итераторы и диапазоны, зачем они нужны и как ими пользоваться.

Динамический полиморфизм (или полиморфизм времени выполнения) обычно связан с v-таблицами и виртуальными функциями. Однако в этой статье я покажу вам современную технику C++, которая использует std::variant и std::visit. Этот метод C++17 может предложить вам не только лучшую производительность и семантику значений, но и интересные паттерны проектирования.

Git – очень мощный инструмент, который практически каждый разработчик должен использовать ежедневно, но для большинства из нас git сводится к нескольким командам: pull commit push. Однако, чтобы быть эффективным, продуктивным и обладать всей мощью git, необходимо знать ещё несколько команд и трюков. Итак, в этой статье мы исследуем функции git, которые просто запомнить, применять и настроить, но которые могут сделать ваше время с git гораздо более приятным.

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

Программистам на C++ хорошо (надеюсь!) известно, что во время компиляции можно производить разнообразные вычисления. Лишь бы эти вычисления были "чистыми", без побочных эффектов. Это делается на шаблонах и на constexpr функциях.

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

Для стресс-тестирования возьмём наивную формулу чисел Фибоначчи:

f(n) = (n < 2) ? 1 : f(n-1) + f(n-2)

К сожалению, концепция криптовалют, несмотря на своё изящество, не нашла понимания у основной массы пользователей. "Среднему пользователю" неважно, лежат ли его деньги в распределённом блокчейне или на каком-то конкретном сайте. Для него это всё равно "где-то в сети". Когда деньги на сайте - даже спокойнее, потому что понятно, кто за него отвечает, в случае чего можно поругаться или написать в соцсети о том, какие они негодяи, или даже подать в суд, а если деньги "потерялись" в блокчейне, то и пожаловаться некому. Пользователи, покупающие биткоины, не хранят приватные ключи у себя, а в основном делегируют это посторонним сайтам, потому для них разницы действительно нет. А даже если хранят у себя - сначала ведь этот ключ они где-то генерируют, и потом скачивают. Понятно, что это уже не полностью их ключ. В результате распространяются слухи о "взломе биткоина", когда деньги уходят хакерам, и подобные байки. С другой стороны, умные и авторитетные люди объясняют, что блокчейн и построенные на нём криптовалюты - это надёжно и правильно, и не верить им нет оснований.

Это закономерно привело к появлению муляжей криптовалют, которые якобы используют те же технологии, но при этом дают преференции их создателям, т.е. не такие уж децентрализованные. Для пользователей всё равно, а создателям профит. Самый распространённый из таких муляжей - Ethereum.

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

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

Эта статья посвящена разным инструментам, которые можно с той или иной степенью успешности применять для отлова утечек памяти в С++/Qt приложениях (desktop). Инструменты будут рассмотрены в связке с IDE Visual Studio 2019. В статье будут рассмотрены не все возможные инструменты, а лишь наиболее популярные и эффективные.

Наша команда давно и пристально изучает подобные инструменты и использует их в своей работе. Объем кода, на котором есть возможность проверить подобные инструменты, составляет около 1.5 миллиона строк. Опираясь на большой практический опыт, мы расскажем о плюсах и минусах разных инструментов, расскажем, что они способны найти, а что не по зубам, расскажем о неочевидных нюансах и, главное, составим сводную сравнительную таблицу по реальному примеру. Мы постараемся максимально быстро и просто ввести в курс дела (показать быстрый старт), потому даже если ты, читатель, никогда не занимался поиском утечек памяти, эта статья поможет за пару часов разобраться и найти свою первую утечку. Поехали!

Сегодняшняя статья написана по следам недавнего вопроса, который можно сформулировать следующим образом: "Можно ли в SObjectizer написать обработчик, который бы обрабатывал сразу нескольких типов сообщений?"

Вопрос интересный.

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

Если изображения передаются в виде SObjectizer-овских сообщений, а блоками обработки являются SObjectizer-овские агенты, то можно ли сделать как-то так:

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

Несмотря на то, что это искажение восприятия успешно эксплуатируется большую часть человеческой истории, широкая публика обратила на него внимание после суда над О. Джей Симпсоном, известным в России по роли в культовой комедии «Голый Пистолет». На КДПВ он сбоку.

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

Это расшифровка-перевод доклада Саши Гольдштейна, признанного лучшим на конференции DotNext 2016 Piter. С годами этот доклад стал лишь актуальнее прежнего: появление Mac на ARM-процессорах — еще один пример, почему разработчикам сегодня нужно думать не только о x86-архитектуре.

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

То, что подходит процессорам Intel на архитектурах x86 и x86-64, может не подойти другой архитектуре. Как только вы перенесете свой код на другой процессор, например, на ARM для iPhone и Android, есть вероятность, что он перестанет работать как надо. Проблемы могут быть как очевидными (воспроизводиться с первого-второго раза), так и не очень (возникать только раз в миллион итераций). Вполне вероятно, что такие баги могут добраться до продакшна. Сегодня .NET и, конечно, C++ можно использовать не только на Windows и Intel, но и на других платформах, так что доклад будет полезен многим разработчикам.

Дисклеймер: статья предназначена для продвинутых читателей. Смотрите на свой страх и риск. За частое упоминание барьеров памяти и изменения порядка исполнения инструкций она получила возрастное ограничение 18+.

Всем привет. Не сразу, но я полюбил Rust. И эта любовь привела меня в бескрайние моря лоулевельного кода. О том, что мне удалось найти - под катом.

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

Ведь не может одно слово иметь противоположные значения, верно? Оказывается, может. К примеру, «проглядеть». Одно из значений — «рассмотреть», а второе — «не заметить». 

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

Прим. перев.: автор этой статьи — Ben Nadel, сооснователь и главный инженер InVision App Inc. Миссию своей команды, поддерживающей серверную инфраструктуру компании, он сам характеризует как «advocate for the users», т.к. её главная цель — гарантировать пользователям InVision «получение опыта, который они заслуживают». Его опыт — яркая иллюстрация того, что микросервисы не серебряная пуля.

Если вы следите за мной в Твиттере, то наверняка заметили, что периодически я публикую победные твиты о возвращении одного из наших микросервисов в InVision обратно в монолит. Обычно эти твиты сопровождаются гифкой, в которой Танос вставляет последний Камень бесконечности в Перчатку бесконечности. Нахожу ее вполне уместной, поскольку воссоединение камней придает Таносу невероятную силу — так же, как воссоединение микросервисов придает силу мне и моей команде. Меня много раз спрашивали, почему я избавляюсь от микросервисов. Настало время поделиться своими мыслями по поводу этого путешествия в мире разработки веб-приложений…

- Добрый день, я на интервью на позицию старшего разработчика.

- Здравствуйте, давайте начнем с небольшого теста, пока я ваше CV смотрю. Напишите программу, которая выводила бы числа от 1 до, скажем, миллиарда, притом если число кратно трем, то вместо числа выводится Fizz, если кратно пяти, то Buzz, а если и трем, и пяти, то FizzBuzz.

Серьезно, FizzBuzz? Задачка для начальной школы, на сениорскую позицию? Ну ладно.