• CLion 2020.2: поддержка проектной модели Makefile, больше C++20 и не только

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

      У нашей команды выдалось очень насыщенное лето, результатами которого мы и спешим сегодня поделиться. Итак, встречайте новый релиз CLion 2020.2!

      CLion release

      Коротко о том, что вошло в новую версию:

      • Поддержка проектной модели Makefile.
      • Последние обновления в CMake.
      • Новые возможности C++20: explicit(bool), назначенные инициализаторы (designated initializers), циклы for на основе диапазонов с инициализаторами.
      • Обновленный статический анализатор кода: анализ на висячие указатели (dangling pointers), поиск возможностей упрощения кода, поиск неиспользуемого кода, анализ возвращаемого значения функции, ограниченной концептом.
      • Юнит-тестирование: поддержка нового фреймворка doctest, новые возможности Catch2 и Google Test. А также упрощение сбора метрик покрытия кода.
      • Обновления в плагине PlatformIO для разработки встроенных систем.
      • Улучшения в поддержке систем контроля версий.
      • Улучшения производительности редактора.
      • Исправления в отладчиках.
      Читать дальше →
    • Как можно и как нельзя использовать нулевой указатель в С++



        Некоторым этот банальный вопрос уже набил оскомину, но мы взяли 7 примеров и попытались объяснить их поведение при помощи стандарта:


        struct A {
            int data_mem;
            void non_static_mem_fn() {}
            static void static_mem_fn() {}
        };
        
        void foo(int) {}
        
        A* p{nullptr};
        
        /*1*/ *p;
        /*2*/ foo((*p, 5));                     
        /*3*/ A a{*p};
        /*4*/ p->data_mem;
        /*5*/ int b{p->data_mem};
        /*6*/ p->non_static_mem_fn();
        /*7*/ p->static_mem_fn();

        Читать дальше →
      • can_throw или не can_throw?


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


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


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


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


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

          Читать дальше →
        • Что такое LLVM и зачем он нужен?

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


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

            Читать дальше →
          • Указатели на методы классов в C++

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

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

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


              Читать дальше →
            • От комментария на Хабре к уязвимости в антивирусе Dr. Web

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

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

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


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

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

                  Достойный наследник ZIP-бомбы и PNG-бомбы (которая в своё время положила Хабр) — компиляторная бомба, которая генерирует огромный бинарник из нескольких строчек кода. Наилучший на сегодня вариант предложил в 2016 году пользователь StackExchange под ником Digital Trauma (последняя версия протестирована в 2020 году). Код на C:

                  main[-1u]={1};

                  Это 14 байт. По условиям конкурса к результату добавляется 15 обязательных байт (дополнительный параметр для компилятора).
                  Читать дальше →
                • Ох уж этот std::make_shared…

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

                    А если копнуть чуть глубже?
                    Читать дальше →
                  • Практическое функциональное программирование

                    • Перевод
                    image

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

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

                      Три недели назад на каггле прошло первое в истории платформы соревнование по «сильному» ИИ – 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:
                        ISA Размер бинарника Размер секции .text Общее число инструкций Число разных инструкций
                        AArch64   97 МБ 74 МБ 13,814,975 195
                        ARMv7A 101 МБ 80 МБ 15,621,010 308
                        i386 106 МБ 88 МБ 20,138,657 122
                        PowerPC64LE 108 МБ 89 МБ 17,208,502 288
                        SPARCv9 129 МБ 105 МБ 19,993,362 122
                        x86_64 107 МБ 87 МБ 15,281,299 203
                        В прошлом топике комментаторы упомянули, что самый компактный код у них получается для SPARC. Здесь же видим, что бинарник для AArch64 оказывается на треть меньше что по размеру, что по общему числу инструкций.

                        А вот распределение по числу инструкций:
                        Читать дальше →
                      • История архитектуры Dodo IS: путь бэкофиса

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

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

                          Читать дальше →
                        • Почему мы в $ИЗВЕСТНОЙ_КОМПАНИИ перешли на $РАСКРУЧЕННУЮ_ТЕХНОЛОГИЮ

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



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

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

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

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

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


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


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


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


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

                            Читать дальше →
                          • Спецификаторы, квалификаторы и шаблоны

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

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

                              Мы подготовили для вас текстовую версию доклада, чтобы вы могли в любой момент вернуться и изучить шпаргалки Михаила.
                              Читать дальше →
                              • +27
                              • 8,4k
                              • 9
                            • Как получить 100% зрения и даже больше

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

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


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

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

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

                                Поделюсь тем, что должен знать офтальмолог, и как правило, о чем не в курсе пациент.
                                Читать дальше →
                              • Аллокаторы памяти

                                • Tutorial
                                Всем привет! Не так давно, после очень плотного изучения аллокаторов и алгоритмов распределения памяти, а также в последующем применении их на практике мне в голову пришла идея написать статью, в которой будет максимально подробно рассказано о них. Считаю, что данная тема будет достаточно востребованной, так как в сети, особенно в русскоязычной части, на данный момент существует очень мало источников, посвященных этому вопросу.
                                Читать дальше →
                              • Я выпустил текстовый процессор, форматировавший жёсткий диск после каждого 1024-го сохранения

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

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

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

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

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