• PVS-Studio 2018: CWE, Java, RPG, macOS, Keil, IAR, MISRA

      PVS-Studio 2018: CWE, Java, RPG, macOS, Keil, IAR, MISRA

      Приближается 2018 год и пора подумать о новых направлениях развития нашего статического анализатора PVS-Studio. Сейчас наибольший интерес для нас представляет поддержка языка Java. Дополнительно мы рассматриваем возможность поддержки языка IBM RPG. Не менее интересно развить анализ C, C++ C# кода в направлении выявления потенциальных уязвимостей. Ещё нам хочется поддержать анализ C и C++ кода на платформе macOS, и, наконец, доделать поддержку компиляторов от компаний Keil и IAR. Никуда мы не денемся и от поддержки стандарта MISRA. Перечислено много, и на всё одного 2018 года нам не хватит. Поэтому давайте вместе с нами пообсуждаем наши планы и выберем самые приоритетные направления.
      Читать дальше →
    • Почтовые ящики, которые и не ящики вовсе…

        Когда летом 2016-го года создавалась первая статья про SObjectizer мы говорили, что со временем будем рассказывать и о деталях его реализации, дабы заинтересованные читатели могли заглянуть «под капот». Сегодняшняя статья будет как раз про потроха SObjectizer-а. Про механизм mbox-ов («почтовых ящиков»), который используется для организации взаимодействия акторов (агентов в нашей терминологии).

        Почему речь именно про mbox-ы?


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

        Зачем нужны mbox-ы?


        Почтовые ящики в SObjectizer нужны для того, чтобы организовывать взаимодействие между агентами. Общение между агентами строится посредством асинхронных сообщений и эти самые сообщения нужно куда-то отсылать. Возникает вопрос: «Куда именно?»
        Читать дальше →
      • Ускорение сборки C и C++ проектов

          Многие программисты не понаслышке знают о том, что программа на языке C и C++ собирается очень долго. Кто-то решает эту проблему, сражаясь на мечах во время сборки, кто-то — походом на кухню «выпить кофе». Это статья для тех, кому это надоело, и он решил, что пора что-то предпринять. В этой статье разобраны различные способы ускорения сборки проекта, а также лечение болезни «поправил один заголовочный файл — пересобралась половина проекта».

          Picture 1
          Читать дальше →
        • Самая быстрая и энергоэффективная реализация алгоритма BFS на различных параллельных архитектурах

            Оффтоп


            В названии статьи не поместилось — данные результаты считаются таковыми по версии рейтинга Graph500. Также хотелось бы выразить благодарность компаниям IBM и RSC за предоставленные ресурсы для проведения экспериментальных запусков во время исследования.


            Введение


            Поиск в ширину (BFS) является одним из основных алгоритмов обхода графа и базовым для многих алгоритмов анализа графов более высокого уровня. Поиск в ширину на графах является задачей с нерегулярным доступом к памяти и с нерегулярной зависимостью по данным, что сильно усложняет его распараллеливание на все существующие архитектуры. В статье будет рассмотрена реализация алгоритма поиска в ширину (основного теста рейтинга Graph500) для обработки больших графов на различных архитектурах: Intel х86, IBM Power8+, Intel KNL и NVidia GPU. Будут описаны особенности реализации алгоритма на общей памяти, а также преобразования графа, которые позволяют достичь рекордных показателей производительности и энергоэффективности на данном алгоритме среди всех одноузловых систем рейтинга Graph500 и GreenGraph500.

            Нажми и прочитай про самый быстрый BFS в мире!
            • +13
            • 3,6k
            • 1
          • Learnopengl. Урок 4.3 — Смешивание цветов

            • Перевод
            • Tutorial
            OGL3

            Смешивание цветов


            Смешивание в OpenGL (да и других графических API, прим. пер.) является той техникой, которую обычно связывают с реализацией прозрачности объектов. Полупрозрачность объекта подразумевает, что он не залит одним сплошным цветом, а сочетает в себе в различных пропорциях оттенок своего материала с цветами объектов, находящихся позади. Как пример, можно взять цветное стекло в окне: у стекла есть свой оттенок, но в итоге мы наблюдаем смешение оттенка стекла и всего того, что видно за стеклом. Собственно, из этого поведения и возникает термин смешивание, поскольку мы наблюдаем итоговый цвет, являющийся смешением цветов отдельных объектов. Благодаря этому, мы можем видеть сквозь полупрозрачные объекты.

            Читать дальше →
          • Rust vs. C++ на алгоритмических задачах

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

            Язык Rust позиционирует себя, как язык системного программирования, поэтому основным его vis-à-vis следует называть C/C++. Сравнивать же молодой и мультипарадигмальный Rust, который поддерживает множество современных конструкций программирования (таких, как итераторы, RAII и др.) с «голым» C я считаю не правильно. Поэтому в данной статье речь пойдет об сравнении с C++.

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

            Статья построена следующим образом: в первой части я опишу основные плюсы и минусы, на которые я обратил внимание, работая с Rust. Во второй части я приведу краткое описание алгоритмических задач, которые были решены в Rust и C++, прокомментирую основные моменты реализации программ. В третьей части будет приведена таблица замера производительности программ на Rust и C++.
            Читать дальше →
          • AdBlock похитил этот баннер, но баннеры не зубы — отрастут

            Подробнее
            Реклама
          • Скриптуем на WebAssembly, или WebAssembly без Web


              Представлять WebAssembly не нужно — поддержка уже есть в современных браузерах. Но технология годится не только для них.


              WebAssembly — кроссплатформенный байткод. Значит, этот байткод можно запустить на любой платформе, где есть его виртуальная машина. И для этого вовсе не нужен браузер и Javascript-движок.


              Далее — проверка концепции на прочность, инструментарий и первый скриптовый модуль.

              Читать дальше →
            • Learnopengl. Урок 4.2 — Тест трафарета

              • Перевод

              image


              Как только, фрагментный шейдер обработал фрагмент, выполняется так называемый тест трафарета, который, как и тест глубины, может отбрасывать фрагменты. Затем оставшиеся фрагменты переходят к тесту глубины, который, может отбросить еще больше фрагментов. Трафаретный тест основан на содержимом еще одного буфера, называемого трафаретным буфером. Мы можем обновлять его во время рендеринга для достижения интересных эффектов.


              Читать дальше →
              • +17
              • 2,2k
              • 2
            • Рефлексия в C++14

              Данная статья является расшифровкой (с небольшими правками) доклада Антона antoshkka Полухина — “Немного магии для C++14”.

              Я тут недавно ковырялся с C++ и случайно открыл пару новых приемов метапрограммирования, которые позволяют делать рефлексию в C++14. Пара мотивационных примеров. Вот у вас есть какая-то POD структура, в ней какие-то поля:

              struct complicated_struct {
                  int i;
                  short s;
                  double d;
                  unsigned u;
              };
              

              Количество полей и их имена не имеют значение, важно то, что с этой структуры мы можем написать следующий кусочек кода:

              #include <iostream>
              #include "magic_get.hpp"
              
              struct complicated_struct { /* … */ };
              
              int main() {
                  using namespace pod_ops;
                  complicated_struct s {1, 2, 3.0, 4};
                  std::cout << "s == " << s << std::endl; // Compile time error?
              }
              

              Функция main, в ней создаем переменную нашей структуры, как-то ее инициализируем через aggregate инициализацию, а потом эту переменную пытаемся вывести в std::cout. И в этот момент у нас, по идее, должна быть ошибка компиляции: мы не определили оператор вывода в поток для нашей структуры, компилятор не знает как все это скомпилировать и вывести. Однако, оно скомпилируется и выведет содержимое структуры:

              antoshkka@home:~$ ./test
              s == {1, 2, 3.0, 4}

              Читать дальше →
            • Двуликая локаль в преобразовании из строки в дробное



              Каждый разработчик С++ рано или поздно сталкивается с особенностями конвертации дробного числа из строкового представления (std::string) в непосредственно число с плавающей точкой (float), связанными с установленной локалью (locale). Как правило, проблема возникает с различным представлением разделителя целой и дробной частей в десятичной записи числа ("," или ".").

              В данной статье речь пойдет о двойственности локалей С++. Если Вам интересно, почему преобразование одной и той же std::string("0.1") с помощью std::stof() и std::istringstream во float может привести к различным результатам, прошу под кат.
              Читать дальше →
            Самое читаемое