Зачем всё это нужно?

Когда чайник, уперевшись в необходимость отойти от простой последовательности действий, задаёт на хабре вопрос типа "как сделать вот это?", ему с вероятностью 70% отвечают "погугли конечные автоматы" и 30% "используй finite state machine" в зависимости от страны работодателя профессионала. На следующий вопрос "а как?" отправляют в гугл. Идёт такой чайник, что только закончил мигать светодиодом и вытер пот со лба, что учил в школе немецкий и всю жизнь работал бульдозеристом в этот гугл и видит там статьи типа Википедия про конечные автоматы с формулами и в которых понятны только предлоги.

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

Наша команда специализируется на C++ проектах. И нам время от времени приходилось создавать HTTP-точки входа в C++ компоненты. Для чего использовались разные инструменты. Тут были и старые-добрые CGI, и различные встраиваемые библиотеки, как сторонние, так и самописные. Все это работало, но всегда оставалось ощущение, что следовало бы делать такие вещи и проще, и быстрее, и производительнее.

В итоге мы решили, что пора прекращать смотреть по сторонам и нужно попробовать сделать что-то свое, с преферансом и куртизанками кроссплатформенностью, асинхронностью, производительностью и человеческим отношением к конечному пользователю. В результате у нас получилась небольшая C++14 библиотека RESTinio, которая позволяет запустить HTTP-сервер внутри C++ приложения всего несколькими строчками кода. Вот, например, простейший сервер, который на все запросы отвечает «Hello, World»:

#include <restinio/all.hpp>

int main()
{
   restinio::run(
      restinio::on_this_thread()
         .port(8080)
         .address("localhost")
         .request_handler([](auto req) {
            return req->create_response().set_body("Hello, World!").done();
         }));

   return 0;
}

В реализации RESTinio активно используются C++ные шаблоны и об этом хотелось бы сегодня немного поговорить.

Представляю, Вам, перевод статьи одного из разработчиков PHP, в том числе версии 7 и выше, сертифицированного инженера ZendFramework. В данный момент работает в SensioLabs и большую часть занимается низкоуровневыми вещами, в том числе программированием в С под Unix. Оригинал статьи здесь.

Ошибка Сегментации: (Компьютерная верстка памяти)

Несколько слов, о чем эта запись в блоге

Я планирую в будущем писать технические статьи о PHP, связанные с глубоким пониманием памяти. Мне нужно, чтобы мои читатели имели такие знания, которые им помогут понять некоторые концепции дальнейшего объяснения. Для того, чтобы ответить на этот вопрос, нам придется перемотать время назад в 1960-е года. Я собираюсь объяснить вам, как работает компьютер, а точнее, как происходит доступ к памяти в современном компьютере, а затем вы поймете, из-за чего происходит это странное сообщение об ошибке — Segmentation Fault.

То, что вы будете читать здесь, краткое изложение основ дизайна компьютерной архитектуры. Я не буду заходить слишком далеко, если это не нужно, и буду использовать хорошо известные формулировки, так что, кто работает с компьютером каждый день может понять такие важные понятия о том, как работает ПК. Существует много книг о компьютерной архитектуре. Если вы хотите углубиться дальше в этой теме, я предлагаю вам достать некоторые из них и начать читать. Кроме того, откройте исходный код ядра ОС и изучите его, будь то ядро Linux, или любое другое.

В предыдущей статье из серии по IL2CPP мы рассмотрели вызовы методов в генерируемом коде C++. Теперь мы поговорим об одной из самых важных особенностей кода IL2CPP – обобщенной реализации методов, позволяющей существенно уменьшить размер исполняемого файла IL2CPP. Стоит отметить, что обобщенная реализация также используется в средах выполнения Mono и .NET. В IL2CPP она изначально не поддерживалась и была добавлена только со временем.

Предыстория

CLion — это среда для разработки на С/С++, близкий родственник IntelliJ IDEA и, соответственно, Android Studio.

Я представляю вниманию сообщества перевод моего блог поста, в котором по шагам описано, как использовать эту IDE для написания прошивок микроконтроллеров.

Статья поддерживается здесь:
[3] Caterpillar Implementation Based on Generated Code

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

Дамы и господа, здравствуйте.

Мы как раз закончили перевод интересной книги Яцека Галовица о STL С++ 17, которую надеемся выпустить чем раньше, тем лучше.


Сегодня же мы хотим предложить вашему вниманию перевод статьи Джулиана Темплмана с сайта «O'Reilly» с небольшим анонсом возможностей стандартной библиотеки нового стандарта С++.

Всех — с наступающим новым годом!

Спотовые инстансы могут сэкономить вам много денег. Но что если вы работаете с сервисами с сохранением состояния, например, базами данных NoSQL? Основная проблема заключается в том, что в таком случае каждая нода в кластере должна сохранять некоторые параметры — IP, данные и другие конфигурации. В этом посте мы расскажем об опенсорсной NoSQL БД Scylla и о том, как ее можно использовать в спотовых инстансах EС2 для непрерывной работы — с помощью предиктивной технологии SpotInst, а также расширенной функциональности сохранения состояния.

Эта статья является продолжением статьи из далекого 2014 года. Напомню, о чем шла речь в прошлой статье.

Какую задачу будем решать

Мы пишем ПО на языке С++, в среде Visual Studio 2015. У нас в проекте, естественно, есть пользовательские типы данных. В качестве примера таких типов могу привести класс MbSolid. Этот класс входит в состав математического ядра C3D и является абстракцией твердого тела. Тело описывается гранями, грани какими-то поверхностями и т.д. Т.е. структура класса довольно сложная, и в процессе отладки собственных алгоритмов хотелось бы визуально прикинуть, какое тело получилось на данный момент.

Приближается 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 нужны для того, чтобы организовывать взаимодействие между агентами. Общение между агентами строится посредством асинхронных сообщений и эти самые сообщения нужно куда-то отсылать. Возникает вопрос: «Куда именно?»

Привет, Хабр! Представляю вашему вниманию перевод статьи Adventures in osu! game hacking.

Не так давно я начал играть в OSU! и она мне понравилась. Со временем захотелось немного поковыряться во внутренностях этой игры.

Основной анализ beatmap

Итак, как мы будем разбирать beatmap? Мы можем разобрать все, начиная от названия песни, заканчивая настройками сложности. (Мы будем держать вещи простыми и анализируем только моменты времени, объекты попадания и некоторые значения, относящиеся к слайдеру.)

В стандартном режиме игры мы имеем дело с тремя типами объектов: кругом попадание, ползунком и счетчиком. В документации для формата файла .osu указано, что все объекты имеют такие составляющие: X, Y, время, тип. Все они будут включены в нашу структуру.

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

Мощный функционал скриптового языка Tcl в сочетании с виджетами Tk/TTK позволяет создавать в этой среде серьезные приложения. Этому способствует также его кросплатформенность и прекрасная интеграция с языками программирования C/C++.

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

Оффтоп

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

Введение

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

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

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

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

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

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

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

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

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

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

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

Данная статья является расшифровкой (с небольшими правками) доклада Антона 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}