C++ *

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

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

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

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

Один из основных моментов в интерфейсе ленивых операций над диапазонами — это возможность следующей записи

burst::merge(std::tie(range1, range2, ...));

То есть возможность работать с произвольным набором исходных диапазонов.

В коде это будет выглядеть как-то так:

const auto odd = std::vector{1, 3, 5, 7};
const auto even = std::list{0, 2, 4, 6, 8};

const auto merged_range = burst::merge(std::tie(odd, even));

const auto expected = {0, 1, 2, 3, 4, 5, 6, 7, 8};
assert(merged_range == expected);

Почему же это так важно, и что стоит за этой записью?

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

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

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

Сравнить точность алгоритмов можно прямо сейчас на этой странице.

В конце будет краткая памятка по тому, где и когда лучше применять какой из методов. При правильном выборе можно добиться увеличения скорости вычислений в 5 раз при погрешности ~1%, а иногда и вовсе без неё.

В своих предыдущих постах я описывал задачи, которые были решены скорее в академических целях. Сегодня я хочу поделиться реальным примером, который работает в продакшене. Речь пойдет о написании сопрограмм, которые можно прервать извне. Изначально мне это понадобилось для реализации механизма deadline или timeout (кому как больше нравится). Согласитесь, довольно часто возникающая задача. На этом примере я продемонстрирую использование еще нескольких возможностей, предоставляемых С++. Речь пойдет об await_transform и конструкторе объекта promise_type.

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

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

Всем доброго времени суток! Это моя история о том, как я портировал исходный код одной фанатской Windows-игры о Марио с Visual Basic 6 на C++, и с какими трудностями я столкнулся в процессе создания порта.

Эта статья рассказывает о портировании Super Mario Bros. X, фанатской игры Эндрю Спинкса, созданную им в 2009 году, которую он затем бросил 2011 году в пользу более серьёзного и масштабного проекта в лице Terraria.

Задача коммерческих статических анализаторов выполнять более глубокий и полный анализ кода, чем компиляторы. Давайте посмотрим, что смог обнаружить PVS-Studio в исходном коде проекта LLVM 13.0.0.

Тема сетевого программирования является для разработчиков одной из важнейших в современном цифровом мире. Правда, надо признать, что большая часть сетевого программирования сосредоточена в области написания скриптов исполнения для web-серверов на языках PHP, Python и им подобных. Как следствие - по тематике взаимодействия клиент-сервер при работе с web-серверами написаны терабайты текстов в Интернете. Однако когда я решил посмотреть, что же имеется в Интернете по вопросу программирования сетевых приложений с использованием голых сокетов, то обнаружил интересную вещь: да, такие примеры конечно же есть, но подавляющее большинство написано под *nix-системы с использованием стандартных библиотек (что понятно – в области сетевого программирования Microsoft играет роль сильно отстающего и менее надежного «собрата» *nix-ов). Другими словами все эти примеры просто не будут работать под Windows. При определенных танцах с бубнами код сетевого приложения под Linux можно запустить и под Windows, однако это еще более запутает начинающего программиста, на которого и нацелены большинство статей в Интернете с примерами использования сокетов.

Ну а что же с документацией по работе с сетевыми сокетами в Windows от самой Microsoft? Парадоксальность ситуации заключается в том, что непосредственно в самой документации приведено очень беглое описание функций и их использования, а в примерах имеются ошибки и вызовы старых «запрещенных» современными компиляторами функций (к примеру, функция inet_addr() - https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen ) - такие функции конечно же можно вызывать, заглушив бдительность компилятора через #define-директивы, однако такой подход является полным зашкваром для любого даже начинающего программиста и категорически не рекомендуется к использованию. Более того, фрагмент кода в примере от Microsoft по ссылке выше.

Как вы думаете, многие люди используют дома холодильники и стиральные машины? Наверное практически все. А ломается эта техника? Еще как! А всегда ли ее потом чинят? Наверное кто-то чинит. А кто-то не чинит, а хочет от нее избавиться. А как проще всего избавиться? Вынести на помойку? А если вы живете на 3…5 этаже без лифта? Может быть выкинуть в окно? ;-) Нет, гораздо проще дать бесплатное объявление типа «Отдам даром старый холодильник. Морозит кое как самовынос  и самовывоз». Объявление можно дать на авито или юлу. Указать свой номер телефона и всегда найдутся желающие взять технику. Что-то можно будет сдать в прием лома, что-то пустить на запчасти, а что-то может и починить, если есть навыки.

Только вот есть интересные моменты: сколько может найтись таких желающих и как быстро они найдутся?

Забегая вперед скажу: желающих может найтись много, и найдутся они очень быстро. В СПб, в среднем, холодильник в любом состоянии находит нового владельца за 1…2 минуты. Время очень короткое, неправда  ли? А теперь я расскажу мою историю по порядку.

Несколько лет назад, мне по работе приходилось мотаться по городу. Причем ездил я в основном на метро и на маршрутках. Сидел и копался на сайтах объявлений в поисках чего-то интересного из компьютерных раритетов и прочих штуковин. И случайно напоролся на объявление об отдаче то ли газовой плиты, то ли еще чего-то похожего. И отдавали рядом с моим домом. Решив, разжиться на халявку этой техникой я дождался станции (чтобы не так шумно было) и позвонил, но мне ответили, что все, уже отдано. А прошло минуты 3…4. Ого-го, что-то быстро. И я стал уже целенаправленно искать подобные объявления, и да, они находились, только реально что-то взять уже не выходило. Я всегда опаздывал.

Накопилось у меня некоторое количество радиоуправляемых игрушек, из тех, которые покупать своим двум детям нельзя: один пульт управляет всем в округе, никакого разделения ни по частотам, ни по кодам. Одновременно играть не получится. У меня эти игрушки работают на частоте 27mhz, но аналогичные могут работать на частотах 35, 40, 49 mhz по тому же простейшему протоколу, о котором и пойдет речь дальше.

Моя идея заключалась в том, чтобы сделать USB девайс, на который можно передавать с компьютера коды команд, а это устройство каждую команду закодирует и выдаст в эфир RC-машинке.

В связи с техническим прогрессом рынок мониторов постоянно обновляется моделями с повышенным разрешением, плотностью пикселей и/или размером экрана. Году в 2010 стандартным монитором можно было считать экземпляр 19’’ c разрешением WXGA++ (1600*900) и фактической плотностью пикселей 97 DPI (dots per inch). Сейчас (2021 год) стандартным монитором, думаю, можно признать экземпляр 24’’ c разрешением Full HD (1920*1080) и плотностью пикселей 92 DPI. Под «стандартным» я понимаю тот монитор, который стоит на рабочем месте у большинства работающего люда: инженеры, бухгалтеры, переводчики и т.д. (при этом, конечно, «стандартность» — это субъективная и приблизительная оценка). Относительно новые и отчасти нишевые модели (для фотографов, видеографов, геймеров) имеют характеристики: 4K UHD (3840*2160) и 28’’ (157 DPI) или UWQHD (3440x1440) и 34" (109 DPI) или QHD (2560x1440) и 27" (109 DPI) или UWHD (2560x1080) и 29" (96 DPI). Таким образом, наблюдается рост в связанных группах признаков: разрешение+размер экрана, или разрешение+плотность пикселей, или даже разрешение+плотность пикселей+размер экрана. На рынке ноутбуков в плане экранов похожая ситуация – растет разрешение+плотность пикселей.

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

Что касается высокой чёткости (большой плотности пикселей), то в ОС Windows давно есть такие настройки, как масштабирование шрифта и изображений (масштаб экрана), которые применяются для увеличения слишком малых элементов GUI на мониторах с высокой чёткостью (High DPI). Также есть поддержка в платформе Qt (с нюансами, об этом далее). Однако способно ли Ваше, конкретное ПО их адекватно учитывать, применять?

• operator[](int, int, int)
• монадические интерфейсы для std::optional
• std::move_only_function
• std::basic_string::resize_and_overwrite
• больше гетерогенных перегрузок для ассоциативных контейнеров
• std::views::zip и zip_transform, adjacent, adjacent_transform

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

У constexpr с каждым годом становится больше возможностей. Сейчас использовать в compile-time вычислениях можно почти всю стандартную библиотеку. Пример вычисления числа до 1000 с наибольшим количеством делителей: ссылка на код.

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

Эта статья подходит как тем, кто еще не знает, что такое constexpr, так и тем, кто уже долгое время его использует.

Недавно мне задали задачку, в обсуждения всё свелось к следующему: - есть объект, в нём есть методы. Каждый метод/ы требует загрузки какой-то логики в рантайме. Мы хотим точно знать - какие методы мы вызвали, после в рантайме затребовать загрузки только нужной функциональности.

От переводчика. Данный текст является переводом документа Safer Usage Of C++, выложенного в общий доступ командой Chromium/Chrome из компании Google. Текст активно обсуждался на Reddit, и команда PVS-Studio решила, что аудитории Habr-а может быть интересно познакомиться с его русскоязычным вариантом. Для перевода использован текст от 20 сентября 2021, и на момент его чтения он может отличаться от текста по ссылке.

В разговоре с Маршаллом Клоу на подкасте CppCast #300 ABI Stability была затронута достаточно давняя новость о поддержке компиляторами Visual Studio инструмента AddressSanitizer (ASan). Мы уже достаточно давно внедрили ASan в свою систему тестирования и хотим рассказать о паре интересных ошибок, которые он помог найти.

Здравствуйте, дорогие друзья. Продолжаю Вас знакомить на Хабре с новостями проекта Haiku.

В предыдущей статье я описал простой путь создания генераторов на корутинах С++. На мой взгляд генераторы неплохо демонстрируют работу с такими объектами как coroutine_handle и promise_type. На этот раз речь пойдет об awaitable объектах — еще одной неотъемлемой части поддержки корутин в С++. А рассматривать мы их будем на примере реализации каналов, аналогичных каналам в GoLang. Как С++ разработчик, я не в восторге от многих решений принятых в GoLang, но в их каналы влюбился с первого взгляда. Итак, приступим!