C++ *

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

Ни один из известных нам сервисов не строил маршрут из точки А до точки Б там, где нет тропинок и тротуаров, зато полно заборов и домов причудливых очертаний.

2ГИС решил эту проблему. Мы научились строить маршруты для пешеходов по растеризованной карте местности. Карта формально представляется графом с вершинами на регулярной решётке в местах, где пешеход может находиться физически.

Принято считать, что такой способ строить маршруты неприемлем, потому что съедает много ресурсов. Под катом — как мы с этим справились.

Преамбула

Использование динамически связываемых библиотек (DLL), как известно, предполагает один из двух способов подключения: связывание во время загрузки (load-time linking) и связывание во время выполнения (run-time linking). В последнем случае нужно использовать предоставляемый операционной системой API для загрузки нужного модуля (библиотеки) и поиска в нем адреса необходимой процедуры. Существует множество оберток, но, к сожалению, все встречавшиеся мне сильно усложнены и перегружены лишним кодом. Предлагаемое решение изначально предназначено для вызова функций, хранящихся в DLL из исполняемых модулей (EXE), отличается относительной простотой реализации, и (что гораздо более важно) простотой использования в клиентском коде.

В преддверии Дня программиста и по следам Дня тестировщика хочу рассказать о том как упростить жизнь и тем и другим в их общем деле — разработке и отладке ПО.
А именно — расскажу о том как сделать исключения С++ более информативными, а логирование ошибок — более компактным.

В этой статье рассказывается, как писать синтаксические анализаторы с помощью этой небольшой библиотеки на с++.

Обычно, текст на машинном языке состоит из предложений, те — из подпредложений, а те, в свою очередь, из подподпредложений, и так вплоть до символов.

Например, элемент xml состоит из открывающего тега, содержимого и закрывающего тега. —> Открывающий тег состоит из '<', имени тега, возможно пустого списка атрибутов и '>'. —> Закрывающий тег состоит из '</', имени тега и '>'. —> Атрибут состоит из имени, знаков '=', '"', строки символов и снова '"'. —> Содержимое в свою очередь тоже может содержать элементы. —> И т.д. Таким образом, после разбора получается синтаксическое дерево.

Такие языки удобно описывать формой Бэкуса-Наура (БНФ), где каждый нетерминал соответствует некоторому предложению языка. Когда мы пишем программы, мы обычно разбиваем их на функции и подфункции, и раз мы собрались писать синтаксический анализатор, пусть каждому нетерминалу БНФ соответствует одна функция нашего анализатора, и пусть каждая такая функция:

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

Например для БНФ вида expr ::= expr1 expr2 expr3 будем писать такую функцию:

Два года подряд во время международного форума Positive Hack Days проходил конкурс WAF Bypass по обходу межсетевого экрана PT Application Firewall. Мы публиковали в блоге разбор заданий этого соревнования (2014 год и 2015 год).

За год популярность соревнования значительно выросла: этой весной для участия зарегистрировалось 302 человека (годом ранее — 101), которые за время конкурса отправили 271390 запросов (вдвое больше, чем в предыдущем году).

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

Навеяно вот этой статьей.

Существует три мнения относительно производительности C++ и C#.

Те кто знают (или думают что знают) C++ считают, что C++ в разы или даже на порядки быстрее.
Те кто знают C++ и C# знают, что для обычных задач быстродействие C++ не нужно, а там где нужно — можно и C#-код заоптимизировать до невозможности. Верхний предел оптимизации у C++ выше, чем у C#, но такие рекорды никому не нужны.
Те кто знают только C# — никогда не испытывали проблем с его быстродействием.

Люди из первой категории все время пытаются доказать свою правоту. При этом приводят примеры оптимизированного кода на C++ и самого пессимизированного кода на C#.

Мне 16 и я школьник. Не так уж давно меня посетила идея написать бота… Нет, не PHP-поделие, уныло висящее на никому не нужном сайте. И даже не бесполезный ответчик на фразы типа "! Погода".

Бот задумывался для развлечения как «говорилка» на десктоп. Ужасно, правда? Но мне хочется узнать свои ошибки, ведь я ни разу не показывал свой код кому-либо, в школе только паскаль. Итак, следуя ненавидимому некоторыми чистому структурному подходу я написал первоначальный вариант на C++.

Задумка такова.

Всем привет!

В конце августа в Новосибирске прошла конференция C++ Siberia. Это отчётный пост с мыслями о конференции срывом покровов и анонсом следующих событий. Также присутствует обзор мотивации посещения конференции и первое видео с конференции: открывающий доклад Эрика Ниблера о библиотеке Ranges, которая войдет в STL v2.

Добро пожаловать!

Существуют различные мнения относительно производительности С++ и C#.

Например, сложно поспорить с тем, что код C# может работать быстрее за счет оптимизации под платформу во время JIT компиляции. Или например с тем, что ядро .Net Framework само по себе очень хорошо оптимизировано.

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

Встречаются и мнения о том, что производительность кода измерять не правильно, ибо микро уровень не характеризует производительность на макро уровне. (я конечно соглашусь с тем что на макроуровне можно испортить производительность, но вряд ли соглашусь с тем что производительность на макро-уровне не складывается из производительности на микро-уровне)

Попадались и утверждения о том, что код на С++ примерно в десять раз быстрее кода на С#.

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

Сейчас дополненная реальность – это одно из самых интересных направлений. Поэтому я и взялся за ее изучение, а результатом этого стала собственная реализация кроссплатформенной безмаркерной дополненной реальности на Qt. Речь в этой статье пойдет о том, как это было реализовано (или же как это реализовать самому). Под катом можно найти демку и ссылку на проект на гитхабе.

В своей статье я бы хотел поделиться технической частью игры, которую сделали два человека. Будут рассмотрены основные архитектурные шаблоны (design patterns) и приёмы, дополнительные библиотеки, особенности портирования при работе с движком cocos2dx. Исходный код здесь.

В деле удалённого вызова процедур дела уже давно обстоят в точности как в известном комиксе «14 стандартов» — чего только тут ни напридумано: древние DCOM и Corba, странные SOAP и .NET Remoting, современные REST и AMQP (да, я знаю, что кое-что из этого формально не RPC, для того чтобы обсудить терминологию даже вот специальный топик недавно создали, тем ни менее всё это используется как RPC, а если что-то выглядит, как утка и плавает, как утка — ну, вы в курсе).

И конечно же, в полном соответствии со сценарием комикса, на рынок пришел Google и заявил что вот теперь наконец он создал ещё один, последний и самый правильный стандарт RPC. Google можно понять — продолжать в 21-ом веке гонять петабайты данных по старому и неэффективному HTTP+REST, теряя на каждом байте деньги — просто глупо. В то же время взять чужой стандарт и сказать «мы не смогли придумать ничего лучше» — совершенно не в их стиле.

Поэтому, встречайте, gRPC, что расшифровывается как «gRPC Remote Procedure Calls» — новый фреймворк для удалённого вызова процедур от Google. В этой статье мы поговорим о том, почему же он, в отличии от предыдущих «14 стандартов» всё-таки захватит мир (ну или хотя бы его часть), попробуем собрать билд gRPC под Windows + Visual Studio (и даже не говорите мне, что инструкция не нужна — в официальной документации упущено штук 5 важных шагов, без которых ничего не собирается), а также попробуем написать простенький сервис и клиент, обменивающиеся запросами и ответами.

На прошлой неделе вышла новая версия компилятора С/С++ от Intel — 16.0 aka Parallel Studio XE Composer Edition for C++. Существенно расширилась поддержка новых стандартов (C11, C++14, OpenMP 4.1), возможности по работе с Xeon Phi, вышли новые версии библиотек и ещё много всего «вкусного». Давайте более подробно посмотрим на то, что появилось в последнем релизе. Поехали!

Решил создать модуль (C/C++ Addons) для NW.js для работы с Рутокенами и поделиться с сообществом кодом, а так же пригласить вас поучаствовать в этом Open source проекте.

Суть идеи в том, чтобы можно было использовать все возможности Рутокена в NW приложении с помощью чистого и понятного JavaScript, а также этот модуль может быть использован в Node.JS или io.js.

API RutokenJS

• CKR initialize()
• bool isInitialize()
• CKR finalize()
• object countSlot()
• object getLibInfo()
• object getSlotInfo(int slot)
• object getTokenInfo(int slot)
• object getMechanismList(int slot)
• object getObjectList()
• CKR login(int slot, string pin)
• CKR loguot()
• object random(int size)
• CKR initToken(int slot)
• CKR openSession()
• CKR closeSession()
• CKR closeAllSessions()
• object getSessionInfo()
• CKR getOperationState()
• CKR setOperationState()

Долгие годы С++ программисты, пишущие под Linux язвительно пеняли разработчикам на С++ под Windows отсутствием в Visual Studio нормального профилировщика памяти. Вот в Линуксе, дескать, есть Valgrind, который решает все проблемы, а в студии что: расставляй какие-то макросы, анализируй какие-то логи — мрак. Клевета! Хотя и правда. Вернее, это было правдой до выхода Visual Studio 2015, в которой наконец-то (ура 3 раза!) присутствует нормальный профилировщик памяти, позволяющий ловить утечки памяти с закрытыми глазами, одной левой и даже не просыпаясь!

В этой статье мы посмотрим, что он умеет и как им пользоваться.

Не часто возникает необходимость создать свой итератор и хотелось бы иметь под рукой небольшой HowTo. В этой заметка хочу рассказать как создать простейший итератор, который можно использовать в стандартных алгоритмах типа std::copy, std::find. Какие методы и определения типов нужны в классе контейнере, чтобы его можно было обходить в циклах for из c++11 и BOOST_FOREACH.

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

Disclaimer: идеи в этом посте более умозрительные, чем в предыдущих. Я буду рад дискуссии.

Эрик Ниблер — известный эксперт по C++, один из важных контрибьюторов Boost, человек, который добавил в стандарт библиотеку Ranges.

26 августа в рамках C++ Party Эрик выступит в новосибирском офисе Яндекса, где как раз расскажет о библиотеке и поговорит с гостями о новых стандартах C++.



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

Кстати, если у вас есть ещё хорошие вопросы к Эрику, — их можно задать в комментариях, и мы попросим его на них ответить.

Среди большого количества цикловых оптимизаций, одной из наиболее эффективных является техника разделения цикла на блоки (loop blocking). Суть её заключается в изменении итерационного пространства с целью более оптимальной работы с памятью, то есть уменьшения промахов кэша. Для этих целей в последней версии компилятора появилась специальная директива, позволяющая контролировать эту оптимизацию. Но обо всём по порядку.

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