C++ *

Это будет наиболее короткая и понятная статья, на LeetCode довольно много задач, которые гораздо проще и лучше получится решать с использованием обоих этих классов, не уверен что обоих сразу, но по-отдельности получается отлично.

Статья получится очень короткой, если я просто перечислю pop, top, front поэтому добавлю по-небольшому разбору некоторых задач с LeetCode.

Почему адаптивные контейнеры?
Дело в том, что любой из этих классов довольно просто повторить при помощи любого последовательного(VECTOR, LIST, DEQUE). Из этого и термин адаптивный контейнер - он подстраивает под себя некоторый функционал классов контейнеров, что в определенной комбинации решает задачи максимально красиво и быстро.

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

Некоторое время назад в Интернете ходила статья о неопределённом поведении, просто бесившая коренную аудиторию Rust. Завсегдатаи С и C++ в ответ только бурчали, что кто-то просто не понимает Всех Тонкостей и Нюансов Их Светлейшего Языка. Как обычно, пришло время и мне постараться изо всех сил и вставить мои пять копеек в эту застарелую дискуссию.

Готовьтесь поговорить об Основной Проблеме языков C и C++, а также о Принципе Лома.

«Время — это единственная вещь, которую все хотят иметь, но которую нельзя купить или продлить» — Харви Маккей

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

Уже как минимум пару лет формат быстрого найма сотрудников, или One day offer, набирает популярность в ИТ-компаниях. У него есть неоспоримые плюсы для всех участников: всего за один день работодатель закрывает вакансию (а то и несколько), а кандидат получает ответ (и, возможно, предложение о работе). 17 июня этого года мы провели ряд онлайн-собеседований c C++ разработчиками уровня middle и senior — и в итоге пополнили команды сразу нескольких отделов. В этом посте делимся ценными наблюдениями по итогам проекта и важными инсайтами — если вы нанимающий менеджер, вы точно найдете здесь немало полезного.

Привет, Хабр! Сегодня я хочу вам представить подборку интересных новостей и материалов из мира C++ за последние две недели.

Приятного чтения!

Всем привет! Меня зовут Нурислам aka tonitaga, данная статья является продолжением статьи Базовые алгоритмы на графах.

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

• Задача коммивояжера является NP-полной, то есть нет известного эффективного алгоритма для ее решения, который работал бы для всех вариантов. Вместо этого применяются различные приближенные алгоритмы. В данной статье мы рассмотрим Муравьиный алгоритм и его реализацию на С++

Мы продолжаем цикл статей, посвящённых теме undefined behavior. Ранее мы исследовали предпосылки неопределённого поведения в C++, предоставили формальные определения и рассмотрели несколько примеров. Сегодня углубимся в проблему: сосредоточимся на случаях UB при многопоточности и неправильном использовании move-семантики.

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

• улучшенный static_assert,
• переменная _,
• оптимизация и улучшение для std::to_string,
• Hazard Pointer,
• Read-Copy-Update (так же известное как RCU),
• native_handle(),
• целая вереница классов *function*,
• множество доработок по constexpr,
• std::submdspan,
• и прочие приятные мелочи.

Это история о баге, который бы заставил вас рвать на себе волосы. Из-за такого бага вы можете подумать: «Но это невозможно, должно быть, компилятор сломался, других вариантов нет!»

А баг компилятора — это серьёзно: за двенадцать лет программирования на C++ я обнаружил (и написал отчёт) всего... об одном. И могу сказать, что перед отправкой отчёта о баге GCC, я максимально тщательно протестировал и проверил его, чтобы не выглядеть идиотом.

Впрочем, ладно, вот моя история.

Мы все привыкли к старому-доброму С++ вместе с его старыми-добрыми погрешностями и милыми недостатками. Мы с ними как-то сжились, научились игнорировать, а самые умные-даже избегать. 

Но тяжелая поступь прогресса неостановима.

Прогресс принес нам современный С++ и вместе с ним новые, современные способы стрельбы себе по ногам - просто потому что стрелять по-ногам по-стариковски это фу.

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

По-одному из пунктов знающие люди (тм) прижали меня к стенке уничтожающим вопросом: а чего ж ты псишь на авто, мил человек?

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

И вот в доказательство своей правоты я решил нырнуть немного глубже в тему и посмотреть, как еще можно неправильно приготовить (что непременно произойдет) этот чудесный подарок миру С++.

Данная статья создана с ознакомительной целью и служит рекомендацией по работе с Raspberry Pi 4 Model B ("Ягода"), WEMOS WiFi & Bluetooth ESP32 ("ESP32") при настройки Serial Peripheral Interface (SPI).

В интернете невероятное количество статей о том "как написать свой генератор на С++20", но почти все они сводятся к новичковым хело вордам и почти ни одной статьи о том как написать хороший генератор. Что ж, это нужно исправлять!

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

Два года назад взялся писать программу, что помогает выставлять счета за аренду ковров. Прежде бухгалтер держал текст договоров в Word, расписание в Excel, а три дня каждого месяца убивал на подсчеты. Теперь программа сама рассчитает суммы и загрузит счета в 1С.

Компания такая не одна: защищу программу - продам ключи.

Защита программы - трудное дело. Исследую защитные алгоритмы на практике: вытащу из готовых программ, а чтобы никому не вредить, исследую программы, что специально написаны для взлома - crackme или keygenme.

Жребий пал на q_keygenme_1.0 by quetz.

Поиск контактных точек коллизии

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

Давайте же посмотрим как это сделать!

Я исследовал некоторые open-source фреймворки — кандидаты на платформу для опорной сети пятого поколения операторского уровня, и хочу поделиться своими выводами. Под катом я сравню Seastar, mTCP, Boost.Asio, userver и ACE, расскажу, почему примитивы синхронизации — это плохо, а затем погружу вас в глубины Seastar.

Это ещё один маленький домашний DIY (апгрейд гирлянды) на, практически, самом младшем из младших микроконтроллеров из линейки ATtiny - на ATtiny10. Классический ЛУТ с ошибками любителя, и написание взрослой прошивки, для серьёзного мигания светодиодами. Все результаты доступны на гитхабе.

Привет, Хабр!

В данной статье сделан обзор на фреймворк планирования движения BMPF.

На данный момент подавляющее большинство средств планирования движения работает по одному и тому же принципу: вся сцена описывается как один робот, после чего выполняется планирование на сетке (чаще всего A*, подробнее можно прочитать здесь).

У такого подхода есть две основных проблемы:

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

2) для сцены из нескольких роботов размерность пространства планирования получается слишком большой (алгоритмическая сложность планирования растёт как показательная функция).

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