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

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

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

По большому счету, у нас в распоряжении есть только спецификатор noexcept. Штука полезная, конечно, но недостаточная.

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

Всем привет! Думаю, у многих сразу возник другой вопрос — а зачем вообще нужна ещё одна статья про LLVM, ведь на хабре их и так больше сотни? Моей задачей было написать "введение в тему" for the rest of us — профессиональных разработчиков, не планирующих создавать компиляторы и совершенно не интересующихся особенностями устройства LLVM IR. Насколько я знаю, подобного ещё не было.

Главное, что интересует практически всех — и о чём я планирую рассказать — вынесено в заголовок статьи. Зачем нужен LLVM, когда есть GCC и Visual C++? А если вы не программируете на C++, вам стоит беспокоиться? И вообще, LLVM это Clang? Или нет? И что эти четыре буквы на самом деле означают?

Привет, интернет.

Решил написать статью об указателях на методы классов. Недавно мне пришлось столкнуться с тем, как они работают изнутри, когда писал некоторые вещи ориентированные под компилятор. Эти указатели работают не совсем как обычные указатели, не имеют возможности быть приведенными в void, и часто имеют размер больше 8 байт. Информации на эту тему в интернете я нашел относительно немного, потому решил разобраться сам.

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

Относительно недавно на хабре появилась статья «Стилер паролей в антивирусном ПО Avira Free Antivirus» от пользователя Veliant. Автор обнаружил, что в стандартной поставке упомянутого антивируса присутствует компонент, который позволяет простым образом извлечь пароли из хранилища браузера Chrome.

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

нельзя ли это было реализовать например в виде DLL, которая при вызове её API проверяла бы цифровую подпись вызывающей программы?

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


Цифровая подпись файла соответствует только самому исполняемому файлу, но работающая программа это не только исполняемый файл. Существует несколько способов повлиять на работу программы, не меняя исполняемый файл: можно подменить библиотеки, которые загружаются или сделать инъекцию кода прямо в памяти.

Я посмотрел на профиль автора: «Работает в: Доктор Веб». А что если посмотреть, не используется ли в продуктах этой компании проверка, о которой говорит автор? Я решил посмотреть и, спойлер, нашел уязвимость, которая позволяет повысить свои привилегии до системных пользователю Dr.Web Security Space для Windows.

C++ Core Guidelines содержат правило R22, предписывающее использовать std::make_shared вместо вызова конструктора std::shared_ptr. В Core Guidelines приводится всего лишь один аргумент за такое решение — экономия на аллокации (и деаллокации).

А если копнуть чуть глубже?

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

40 лет назад, 17 октября 1977 года, премия Тьюринга была вручена Джону Бэкусу за его вклад в разработку систем программирования высокого уровня, прежде всего языка программирования Fortran. Всем лауреатам премии Тьюринга предоставляется возможность выступить с лекцией по выбранной ими теме в течение года, в котором они получили премию. Как создатель языка программирования Фортран, можно было ожидать, что Бэкус выступит с лекцией о преимуществах Фортрана и будущих разработках в этом языке. Вместо этого он прочитал лекцию под названием «Можно ли освободить программирование от стиля фон Неймана»? в котором он критиковал некоторые из основных языков того времени, включая Фортран, за их недостатки. Он также предложил альтернативу: функциональный стиль программирования.

Три недели назад на каггле прошло первое в истории платформы соревнование по «сильному» ИИ – Abstraction and Reasoning Challenge. Чтобы проверить способность моделей к обобщению и решению абстрактных задач, все участники суммарно решили только чуть менее половины задач. Решение-победитель справляется приблизительно с 20% из них — и то девятичасовым перебором вручную захардкоженных правил (ограничение в девять часов установили организаторы).

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



Кто-то с ужасом, а кто-то с нетерпением ждет ИИ как в произведениях фантастов. С личностью, эмоциями, энциклопедическими знаниями и главное – с интеллектом, то есть способностями к логическим выводам, оперированию абстрактными понятиями, выделению закономерностей в окружающем мире и превращению их в правила. Как мы знаем, именно такой ИИ теоретики называют «сильным» или ещё AGI. Пока это далеко не мейнстримное направление в машинном обучении, но руководители многих больших компаний уже считают, что сложность их бизнеса превысила когнитивные способности менеджеров и без «настоящего ИИ» двигаться вперёд станет невозможно. Идут дискуссии, что же это такое, каким он должен быть, как сделать тест чтобы уж точно понять, что перед нами AGI, а не очередной blackbox, который лучше человека решает локальную задачу – например, распознавание лица на фотографии.

Месяц назад я попытался сосчитать, сколько разных инструкций поддерживается современными процессорами, и насчитал 945 в Ice Lake. Комментаторы затронули интересный вопрос: какая часть всего этого разнообразия реально используется компиляторами? Например, некто Pepijn de Vos в 2016 подсчитал, сколько разных инструкций задействовано в бинарниках у него в /usr/bin, и насчитал 411 — т.е. примерно треть всех инструкций x86_64, существовавших на тот момент, не использовались ни в одной из стандартных программ в его ОС. Другая любопытная его находка — что код для x86_64 на треть состоит из инструкций mov. (В общем-то известно, что одних инструкций mov достаточно, чтобы написать любую программу.)

Я решил развить исследование de Vos, взяв в качестве «эталонного кода» компилятор LLVM/Clang. У него сразу несколько преимуществ перед содержимым /usr/bin неназванной версии неназванной ОС:

1. С ним удобно работать: это один огромный бинарник, по размеру сопоставимый со всем содержимым /usr/bin среднестатистического линукса;
2. Он позволяет сравнить разные ISA: на releases.llvm.org/download.html доступны официальные бинарники для x86, ARM, SPARC, MIPS и PowerPC;
3. Он позволяет отследить исторические тренды: официальные бинарники доступны для всех релизов начиная с 2003;
4. Наконец, в исследовании компиляторов логично использовать компилятор и в качестве подопытного объекта :-)

Начну со статистики по мартовскому релизу LLVM 10.0:
В прошлом топике комментаторы упомянули, что самый компактный код у них получается для SPARC. Здесь же видим, что бинарник для AArch64 оказывается на треть меньше что по размеру, что по общему числу инструкций.

А вот распределение по числу инструкций:

Хабр меняет мир. Больше года мы ведём свой блог. Где-то полгода назад нам прилетел вполне логичный фидбэк от хабровчан: «Додо, вот вы везде говорите, что у вас своя система. А что это за система? И зачем она нужна сети пиццерий?».

Мы посидели, подумали и поняли, что вы правы. Мы пробуем объяснить всё на пальцах, но выходит рваными кусками и нигде нет полноценного описания системы. Так начался долгий путь сбора информации, поиска авторов и написания серии статей про Dodo IS. Погнали!

Благодарности: спасибо, что делитесь своим фидбэком с нами. Благодаря ему мы наконец описали систему, составили технорадар и скоро выкатим большое описание наших процессов. Без вас так бы и сидели ещё 5 лет.

Прим. перев.: эта шуточная статья, которую по праву охарактеризовали как иллюстрацию «SEO-driven development», нашла очень большой отклик на Reddit и других ресурсах. Соглашаясь с актуальностью той истории, что пародируется автором оригинала, мы рады поделиться её переводом с русскоговорящим сообществом.



Сразу после своего основания в 2010 году $ИЗВЕСТНАЯ_КОМПАНИЯ вполне помещалась в $ГАРАЖЕ_БРАТАНА_ОСНОВАТЕЛЯ. С тех пор мы росли как на дрожжах, чему способствовали постоянные вливания средств венчурными капиталистами. Сегодня сотни миллионов ежедневно активных пользователей (DAUs) изо всех уголков мира пользуются нашими продуктами в мобильных приложениях и на сайте $famouscompany.com.

За это время мы уже несколько раз в панике чинили бэкенд, чтобы уменьшить свой технический долг (как правило, сразу после очередного масштабного сбоя) и наши серверы не навернулись. Имевшийся технологический стек верой и правдой служил нам все эти годы. Но со временем стало очевидно, что, переписав приложение «с нуля», мы сможем выжать из пользователей дополнительные 2 млрд долларов в год.

"Кто ни разу не ошибался в индексировании цикла, пусть первый бросит в деструкторе исключение."

— Древняя мудрость

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

В конце концов, это просто некрасиво.

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

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

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

template<class T>
static inline thread_local constexpr const volatile T x = {};

Такое количество ключевых слов введет в ступор любого неподготовленного разработчика. Но на C++ Russia 2019 Piter Михаил Матросов (mmatrosov) разложил по полочкам квалификаторы и спецификаторы при объявлении переменных и функций.

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

Практика показывает, что далеко не каждый человек знает, что такое острота зрения. Например, если вы узнаете, что курица видит на 300%, то есть точно лучше каждого из нас, и глаза у нее видят по-разному — то вы удивитесь.

В древние времена остроту зрения проверяли по созвездию Большой Медведицы в ночном небе. Это созвездие напоминает «ковш с ручкой» и практически всегда видно на ночном небе. Так рядом со второй звездой от конца «ручки ковша» (Мицар) находится малозаметная небольшая звезда Алькор («забытая, незначительная»). Способность видеть эту малозаметную звезду считалась традиционным способом проверки зрения, условной нормой. То есть, система была бинарная – «вижу» и «не вижу».


Эра починки зрения началась несколько столетий назад, использовать для этого лазер стали всего пару десятилетий назад и совершили технологический скачок до эндоскопической коррекции зрения ReLEX SMILE, о ней писала здесь.

В мире с 1985 года выполнено более 60 миллионов процедур по лазерной коррекции зрения! И все эти люди счастливы, что получили 100% зрение, спросите вы? А теперь самое интересное – нет, не все счастливы. И уж точно не у всех 100%.

Что может быть причиной не 100% зрения, почему люди «щурятся», как оценивать показатели приборов, которые измеряют параметры глаза, в том числе после лазерной коррекции, можно ли им доверять, как избежать багов при тестировании, какие исследования, зачем и когда необходимы, чтобы прояснить картину?

Поделюсь тем, что должен знать офтальмолог, и как правило, о чем не в курсе пациент.

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

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

Это был, наверное, 1984-1985 год. Тогда я был 25-летним подающим надежды программистом с пятилетним стажем. Я и ещё один программист писали и поддерживали набор приложений, похожих на сегодняшний Office: электронные таблицы, текстовый процессор, база данных, плоттер и т.п. Мы настраивали всю эту систему для трёх-четырёх вертикальных рынков [бизнес-клиентов узкоспециальной направленности / прим. перев.].

Большую часть текстового процессора писал я сам. Писал я на Форте, и для различных вариантов комбинаций операционок и процессоров. Молодёжи невдомёк, но в те времена новые микрокомпьютеры со своей особой ОС и одним из нескольких вариантов процессоров выходили раз в несколько месяцев.

Форт использовал обмен блочными данными с диском. Каждый блок имел длину в 1 кб, и чтобы сохранить что-нибудь больше 1 кб, нужно было работать с мастер-блоком файла, где хранились смещения всех блоков с данными – по сути, это была пара списков, занятых и незанятых блоков.

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

Долгое время Rust позиционировался исключительно как язык для системного программирования. Попытки использовать Rust для высокоуровневых прикладных задач зачастую вызывали усмешку у значительной части сообщества: зачем использовать инструмент в том качестве, на которое он не рассчитан? Какая польза от возни с типами и анализатором заимствований (borrow checker), если есть Python и Java со сборкой мусора? Но другая часть сообщества всегда видела потенциал Rust именно как языка прикладного, и даже находила его удобным в использовании для быстрого прототипирования — во многом благодаря его особенностям, а не вопреки им.

Взаимосвязь технологий. Полная версия результатов опроса тут.

Краткие выводы

• 65 000 разработчиков было опрошено.
• Python спустился с 2 на 3 место среди самых любимых технологий, будучи побитый TypeScript. Rust на первом месте пять лет подряд.
• Инженеры по надежности сайта и специалисты DevOps остаются среди самых высокооплачиваемых. 80% респондентов считают, что DevOps важен, а 44% работают в организациях с хотя бы одним выделенным сотрудником DevOps.
• 52% респондентов думают «Привет, старина», когда ищут в сети решение для кодирования, и обнаруживают, что первая ссылка на результат фиолетового цвета, потому что они уже посетили эту ссылку.
• 90% респондентов ответили, что посещают Stack Overflow, когда сталкиваются с трудностями и застревают в написании кода.
• 0,3% респондентов никогда не посещали Stack Overflow до начала этого опроса.
• Респонденты из Австралии сообщили о самом высоком среднем уровне опыта написания кода (16,9 лет), за ними следуют разработчики из Великобритании и США.
• Респонденты из Соединенных Штатов и Соединенного Королевства показывают самый высокий средний возраст — 33,7 и 33,1 года соответственно.
• Более 40% респондентов сообщили, что они являются членами других сообществ онлайн-разработчиков, помимо Stack Overflow.
• Более 75% разработчиков работают сверхурочно, по крайней мере, время от времени — один-два дня в квартал. 25% работают сверхурочно 1-2 дня в неделю и более.

Некоторые любопытные результаты опросов.

Продолжение рассказа «Карьера программиста».

Я не притрагивался к книге “Карьера программиста” ровно год, и видимо не зря. За последние месяцы, со мной произошло много трансформаций, которые позволят дополнить эту историю материалами о том, как создать и развивать IT-компанию. Это кажется закономерным. Если вы амбициозный программист или фрилансер, то рано или поздно задаетесь вопросом: «А что дальше?». Вот, я уже старший разработчик — а что дальше? Назначили архитектором — а что дальше?..

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