Любая программа состоит из данных и алгоритмов их обработки. Для написания программ на C++ в начале 90-х годов прошлого века Александр Степанов с коллегами разработал библиотеку STL. Я, Михаил Полукаров из команды разработки VK Teams, заглянул под капот этой библиотеки чтобы разобраться, как правильно ей пользоваться, в каких случаях лучше использовать другие библиотеки, а в каких стоит написать что-то своё. 

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

Я хотел бы кратко рассказать о таких форматах данных, распространенных в ИТ-индустрии, в том числе в области инфраструктур открытых ключей (ИОК), смарт-картах, включая документы нового поколения на базе смарт-карт, в мобильной связи. Хотя рассматриваемые форматы и связаны с ASN.1, но некоторые из них ушли далеко за пределы этой области. О некоторых из них многие знают, но не все знают настолько, чтобы, допустим, уметь отличать BER от DER, а некоторые варианты типа PER вообще являются экзотикой.

Глубоко в тему погружаться не буду. Просто познакомлю с главными особенностями, чтобы понимать, что это такое и с чем это едят. Досконально и в полном объеме всё это описано в соответствующих стандартах ITU-T X.690 и ISO 7816.

Одна из моих мотивирующих задач — это уложить тему в своей голове по полочкам.

Правила абстрактной нотации (ASN.1) используются, когда надо специфицировать формат некой структуры данных. Сами правила описаны в стандартах ITU-T X.680–X.683. Пожалуй, что наиболее распространенный вариант применения — это форматы сертификатов X.509 и всего, что имеет к ним отношение. Пример текстовой нотации может выглядеть как-то так:

В Go 1.18 добавлена поддержка дженериков. Это самое большое нововведение с момента первого Open Source выпуска Go. Не будем пытаться охватить все детали, затронем всё важное. Подробное описание со множеством примеров смотрите в документе с предложением по улучшению языка. Материалом делимся к старту курса по Backend-разработке на Go.

Скрипты на Bash. Как много в этом слове. Любому разработчику рано или поздно приходится их писать. Почти никто не скажет "да, я люблю писать bash-скрипты", и поэтому этой теме уделяют мало внимания.

Я не буду пытаться сделать из вас эксперта в Bash, а просто покажу минимальный шаблон, который поможет сделать ваши скрипты более надежными и безопасными.

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

Хорошо, если есть поддержка концептов или рефлексии. А что делать, если их ещё нет, или они не в полной мере поддерживаются?

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

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

Это руководство содержит общий обзор и конкретные приемы написания сложной Rust обёртки для звукового движка FMOD с помощью парсера pest и квази-цитирования.

Для большинства стандартных контейнеров перебор элементов можно осуществлять просто с помощью цикла for с диапазоном прямо во время выполнения. Но что насчет кортежей (std::tuple)? В этом случае мы не можем использовать обычный цикл, так как он не «понимает» список аргументов кортежа во время компиляции. В этой статье я покажу вам несколько приемов, которые вы можете использовать для итерации по элементам кортежа.

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

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

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

Итак, рассмотрим ситуацию, когда в команду разработки (или в командЫ разработки) приходит новый руководитель, о котором самим участникам команды ничего не известно. И этот руководитель — вы.

В марте 1869 года была опубликована первая версия периодической системы Менделеева. Систематический вид из рядов и групп она приобрела через пару лет – вот так выглядел вариант от 1871 года. Как известно (о чем я уже упоминал в статье про пределы таблицы Менделеева и элемент фейнманий). Дмитрий Иванович Менделеев (1834-1907) принципиально превзошел своих учителей и коллег, в частности, Роберта Бунзена, Жана Лекока Буабодрана и Лотара Майера в том, что пытался не только классифицировать уже известные к тому времени химические элементы, но и расположить их в соответствии с увеличением атомного веса и периодическим паттерном химических свойств. Поэтому он не только оставил в своей таблице пустые клетки, но и сделал два исключения из периодического закона на материале известных ему элементов. Тем не менее, Менделеев весьма превратно представлял себе варианты заполнения «краев» таблицы. Ошибки Менделеева, в которых он даже упорствовал, были связаны с двумя неверными исходными посылками. Во-первых, Менделеев всерьез воспринимал концепцию мирового эфира (написал о нем серьезную аналитическую статью в 1902 году), хотя, еще в 1887 году был неоднократно поставлен эксперимент Майкельсона-Морли, фактически доказавший, что эфир не существует. Кроме того, на момент составления таблицы еще не была известна внутренняя структура атома (атом считался неделимым), а также Менделеев не предусмотрел в таблице 8-й группы, то есть, столбца с благородными газами.

Когда речь заходит об асинхронных операциях в Unity, на ум первым делом приходит coroutine. И это не удивительно, так как большинство примеров в сети реализованы именно через них. Но мало кто знает, что Unity поддерживает работу с async/await еще с 2017 версии.

Так почему же большинство разработчиков до сих пор использует coroutine вместо async/await? Во первых, как я уже упомянул, большая часть примеров написана с использованием coroutine. Во вторых, async/await кажется очень сложным для начинающих разработчиков. Ну и в третьих, когда речь заходит о коммерческих проектах, где основным из критериев является стабильность, предпочтение отдается проверенному годами подходу.

Но технологии не стоят на месте и появляются библиотеки, которые делают работу с async/await в Unity удобной, стабильной и самое главное высокопроизводительной.

Мой интерес к дизайну языков программирования приводит меня иногда к интересным, но почти неизвестным в широких кругах проектам. Один из таких проектов - язык C∀ (CForAll), разрабатываемый Университетом Ватерлоо. C∀ является расширением ISO C и обеспечивает обратную совместимость с C. Помимо исправления некоторых недостатков Си (которые можно исправить без нарушения обратной совместимости), в C∀ есть некоторые весьма интересные и оригинальные фичи: некоторые расширения классических управляющих операторов, альтернативный синтаксис объявления квалификаторов, кортежи и множественные операции, оригинальное расширение ссылок, своя реализация полиморфизма, сопрограммы и т.д.

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

When talking about high-performance software we probably think of server software (such as nginx) which processes millions requests from thousands clients in parallel. Surely, what makes server software work so fast is high-end CPU running with huge amount of memory and a very fast network link. But even then, the software must utilize these hardware resources at maximum efficiency level, otherwise it will end up wasting the most of the valuable CPU power for unnecessary kernel-user context switching or while waiting for slow I/O operations to complete.

Thankfully, the Operating Systems have a solution to this problem, and it's called kernel event queue. Server software and OS kernel use this mechanism together to achieve minimum latency and maximum scalability (when serving a very large number of clients in parallel). In this article we are going to talk about FreeBSD, macOS and kqueue, Linux and epoll, Windows and I/O Completion Ports. They all have their similarities and differences which we're going to discuss here. The goal of this article is for you to understand the whole mechanism behind kernel queues and to understand how to work with each API.

Молчи – за умного сойдешь! Эта установка крепко сидит в голове людей, прошедших советскую школу обучения. Понимание, которое застряло внутри, что не нужно высовываться, если ты не уверен на 250% в том, что  хочешь сказать. В учебе это очень вредный совет, особенно в английском. 

Что же нам поможет заговорить на английском?

Наверняка у читателя есть свои любимые сайты и блоги, посвящённые программированию на языке С++. Сегодня ваша коллекция пополнится.

Можете ли вы уверенно сказать, что будет выведено на консоль в результате выполнения следующего кода?