Мне оказали честь — пригласили выступить на первой конференции C++ 2015 Russia 27-28 февраля. Я был насколько наглым, что запросил 2 часа на выступление вместо положенного одного и заявил тему, наиболее меня интересующую — конкурентные ассоциативные контейнеры. Это hash set/map и деревья. Организатор sermp пошел навстречу, за что ему большое спасибо.
Как подготовиться ко столь ответственному испытанию выступлению? Первое — нарисовать презентацию, то есть кучу картинок, желательно близко к теме. Но надо ещё и два часа озвучивать картинки, — как все это запомнить? Как избежать глубокомысленных «ээээмммм», «здесь мы видим», «на этом слайде показано», несвязных прыжков повествования и прочих вещей, характеризующих выступающего c не очень хорошей стороны в части владения родным языком (это я про русский, с C++ я разобрался быстро — никакого кода в презентации, только картинки)?
Конечно, надо записать свои мысли, глядя на слайды. А если что-то написано, то не худо бы и опубликовать. А если публиковать, — то на хабре.
Итак, по следам C++ 2015 Russia! Авторское изложение, надеюсь, без авторского косноязычия, без купюр и с отступлениями по теме, написанное до наступления события, в нескольких частях.

В субботу, 14 марта днепропетровский офис компании Ciklum приглашает всех любителей С++ на «субботник», во время которого в презентациях будут освещены следующие темы:

Предлагаем читателю очередную статью о проверке известного open-source проекта. В этот раз мы проверили проект LibreOffice, представляющий собой офисный пакет. В его разработке принимает участие более чем 480 программистов. Код оказался весьма качественным и регулярно проверяемым статическим анализатором Coverity. Но, как и в любом другом большом проекте, были найдены новые ошибки и недочеты, о которых мы и расскажем в статье. Для разнообразия, в этот раз нас будут сопровождать не единороги, а коровы.

Два с половиной часа в поезде – прекрасное время для того, чтобы написать благодарность организатору конференции Сергею Платонову (@sermp) и его команде за то, что наконец-то в России появилась конференция про C++! Заслуги Сергея поистине впечатляют, учитывая то, что он не обладал бюджетами Microsoft и Intel. Однако оказалось, что главное не бюджет, а желание и энтузиазм. Поэтому собранные Сергеем докладчики были выше всяческих похвал, иностранные гости – крайне общительны и любезны. А на стендах JetBrains, IncrediBuild, Kaspersky и PVS-Studio собрались не говорящие головы, а профессионалы, с которыми интересно было общаться и гостям, и соседям по стенду. Наши личные впечатления – под катом.

И вновь приветствую, Хабр!

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

D3 — мощная JavaScript библиотека для визуализации данных. На мой взгляд — просто рай для web-разработчика, казалось бы недоступный для Qt-программиста. Но гибкость фреймворка Qt позволяет интегрировать web-frontend в толстый клиент с помощью механизма Qt Web Bridge. Такие приложения получили наименование гибридные (Qt Hybrid Apps).

Для JavaScript-программистов хорошая новость заключается в том, что их решения можно легко интегрировать в Desktop приложения, что потенциально может увеличить целевую аудиторию пользователей разрабатываемых библиотек (во всяком случае это верно для мира Qt приложений).

На скриншоте ниже изображен виджет Dependency Wheel (Круг Зависимостей), отрисовка которого осуществляется с помощью D3.js а управление данными и отображением — с помощью Qt. При нахождении указателя над соответствующей дугой её взаимосвязи «подсвечиваются», а остальные становятся полупрозначными. Данный виджет можно использовать для визуализации различного рода зависимостей (например библиотек).

В отличии от оригинального JS решения диаграмма динамически изменяет размер под размер виджета, а данные устанавливаются на стороне Qt, а не с помощью загрузки JSON-файла.

Статья больше ориентирована на Qt-программистов, но также может быть интересна и JS программистам.

Если вы верите в Agile и разработка через тестирование для вас является нормой, а не какой-то непонятной практикой, но наверное столкнулись с такой нехорошей проблемой как организацией тестирования объектов которые используют другие объекты через интерфейсы на C++.

Если для .NET есть замечательная библиотека Rhino.Mocks, которой достаточно «скормить» интерфейс и вы получаете возможность программирования поведения методов интерфейса прямо в модульном тесте. То для С++ все сильно сложнее, так как нет замечательного рефлекшена который позволяет строить код во время исполнения. И приходится писать объекты-заглушки вручную. И в случае изменения интерфейса приходится не только обновлять все классы в приложении но обновлять весь набор «одноразовых» классов заглушек реализующих интерфейс которые применяются в тестах.

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

Обозначения и предположения

• Я буду предполагать, что читатель понимает, что, например, в C++ есть ссылки, а в C — нет, поэтому я не буду постоянно напоминать, о каком именно языке (C/C++ или именно C++) я сейчас говорю, читатель поймёт это из контекста;
• Также, я предполагаю, что читатель уже знает C и C++ на базовом уровне и знает, к примеру, синтаксис объявления ссылки. В этом посте я буду заниматься именно дотошным разбором мелочей;
• Буду обозначать типы так, как выглядело бы объявление переменной TYPE соответствующего типа. Например, тип «массив длины 2 int'ов» я буду обозначать как int TYPE[2];
• Я буду предполагать, что мы в основном имеем дело с обычными типами данных, такими как int TYPE, int *TYPE и т. д., для которых операции =, &, * и другие не переопределены и обозначают обычные вещи;
• «Объект» всегда будет означать «всё, что не ссылка», а не «экземпляр класса»;
• Везде, за исключением специально оговоренных случаев, подразумеваются C89 и C++98.

Указатели и ссылки

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

int x;
int *y = &x; // От любой переменной можно взять адрес при помощи операции взятия адреса "&". Эта операция возвращает указатель
int z = *y; // Указатель можно разыменовать при помощи операции разыменовывания "*". Это операция возвращает тот объект, на который указывает указатель

Хочу рассказать о своем первом опыте в геймдеве. Сразу стоит оговориться, что статья будет чисто технической, поскольку моей целью было всего лишь получение навыков разработки графических приложений, использующих Direct3D, без привлечения высокоуровневых средств разработки игр типа Unity. Соответственно, никаких разговоров о внедрении, монетизации и раскрутке игры также не будет. Статья ориентирована на новичков в программировании приложений Direct3D, а также просто на людей, интересующихся ключевыми механизмами работы подобных приложений. Также в конце привожу список литературы по геймдеву, тщательно отобранный мной из более чем ста книг по программированию игр и компьютерной графики.

При реализации проектов на 1С зачастую приходится сталкиваться с разного рода устройствами и их сопряжением. Покуда будут существовать устройства на древним RS232 будет необходимость во внешних компонентах такого рода. Как правило с устройством идет документация, которая нередко содержит систему команд и некий драйвер который распространяется «так как есть». Очень часто драйвера «так как они есть» оставляют ожидать лучшего. Я предлагаю немного окунутся в системное программирование и решить для себя сей вопрос раз и навсегда.

Прекрасная статья содержит пример и достаточное описание что к чему, что где менять. Пример компилируется. Для быстрого старта замечательная статья. Подобный пример свободно распространяется фирмой 1С и валяется в куче хлама на диске ИТС. Много раз мелькало в глазах но было заложено на дальнюю полку с ярлыком «обязательно изучить».

7 октября 2014 года в публичном доступе появились исходники Qt-модуля QtRemoteObjects. Модуль создан в недрах Ford Motor Company (автор Brett Stottlemyer). Вещь, на мой взгляд, очень перспективная. Модуль позволяет, например, передавать сигналы между объектами по сети. Но этим возможности модуля не ограничиваются. Более точно суть модуля описывает его предыдущее наименование — Replica, так как объекты «реплицируются» между процессами.



Ключевой идеей QtRemoteObjects, которая качественно отличает его от других способов межпроцессного взаимодействия/удаленного вызова процедур, является идея полностью продублировать Qt-объект в другие процессы. Это значит, что все изменения свойств (properties) в объекте — источнике отражаются (с уведомлением посредством сигналов) в объекте-реплике. Любые сигналы, которые эмитируются объектом-источником будут также эмитированы в каждом объекте-реплике. Также можно устанавливать свойства, вызывать слоты и в объекте-реплике, при этом запросы отправляются объекту-источнику, который их обрабатывает и затем изменения отражаются в других объектах-репликах посредством сигналов или с помощью изменения свойств. В результате все объекты (включая объект-источник) синхронизируются. При этом вся сложность межпроцессного взаимодействия скрыта внутри QtRemoteObjects.

Эта статья написана прежде всего для программистов C/C++, использующих в своей работе Visual Studio 2013. Поскольку я, как говорится, totally windows guy, то я не могу оценить полезность этой статьи для программистов, не использующих эту среду в своей работе. Итак.

Не секрет, что стандартный аллокатор new/delete/malloc/free в языке C/C++ не блещет быстродействием. Конечно, всё зависит от реализации, но, если говорить об оной от компании Microsoft, то это факт. Кроме того, стандартная реализация аллокатора обладает еще одним фатальным недостатком — фрагментацией памяти. Если в вашей программе происходят частые выделения/освобождения памяти, вы можете обнаружить, что спустя несколько часов работы ваша программа упала по причине нехватки памяти, хотя свободной памяти еще достаточно — просто в результате фрагментации в пуле аллокатора не осталось свободного участка достаточного размера. (Это, кстати, абсолютно реальный случай, который произошел на одном из проектов, в котором я принимал непосредственное участие.)

                                             — У нас дыра в безопасности.
                                             — Ну, хоть что-то у нас в безопасности.
                                                                                  Анекдот

Если вы Windows-пользователь, то вам должны быть знакомы всплывающие каждый второй вторник месяца окошки, рапортующие об установке «критических обновлений безопасности». Microsoft прилагает немалые усилия, постоянно работая над исправлениями уязвимостей в своих операционных системах, но оно того стоит: в мире, где число кибератак день ото дня только возрастает, ни одна лазейка в обороне наших компьютеров не должна оставаться открытой для потенциальных злоумышленников.

Недавнее обсуждение в списке рассылки, посвящённого 66192-й SVN ревизии ReactOS, показало как это легко — внести в код ядра критическую уязвимость. Я буду использовать этот случай как пример простой, но влияющей на безопасность ошибки, а также для наглядного представления некоторых мер, которым необходимо подвергать код ядра, если вы действительно хотите получить безопасную систему.

Отыщем уязвимость

Ненароком я породил большую дискуссию, касающуюся того, допустимо ли использовать в Си/Си++ выражение &P->m_foo, если P является нулевым указателем. Программисты разделились на два лагеря. Одни уверенно доказывали, что так писать нельзя, другие столь же уверенно утверждали, что можно. Приводились различные аргументы и ссылки. И я понял, что нужно внести окончательную ясность в этот вопрос. Для этого я обратился к экспертам Microsoft MVP и разработчикам Visual C++, общающимся через закрытый список рассылки. Они помогли подготовить эту статью, и я представляю её всем желающим. Для нетерпеливых: этот код не корректен.

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

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

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

Не забывай — количество мест на самых привлекательных курсах обычно ограничено и заканчивается стремительно! А некоторые так и просто стартуют совсем скоро — запрыгивай в уходящий поезд!

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

Некоторое время назад мы поддержали Рутокен ЭЦП в openssl, затем выпустили кроссплатформенный плагин для браузера, а теперь сделали высокоуровневую криптобиблиотеку для встраивания в С++ приложения.

Концептуально данные решения выполнены идентично: используется аппаратная реализация российских криптоалгоритмов на чипе Рутокен ЭЦП, обеспечивается поддержка цифровых сертификатов X.509, запросов на сертификаты PKCS#10, подписанных и зашифрованных сообщений CMS.

Новая библиотека пригодится тем, кто пишет «толстые клиенты», десктопные приложения, свои браузерные плагины и т.п.

Поддерживаемые устройства:

• USB-токен Рутокен ЭЦП
• Смарт-карта Рутокен ЭЦП
• Bluetooth-токен Рутокен ЭЦП
• Trustscreen-устройство Рутокен PINPad
• USB-токен Рутокен WEB (HID)

Основные сценарии применения библиотеки с примерами кода под катом.

Высокоуровневые языки программирования содержат в себе много абстрактных программистских конструкций, таких как функции, условные операторы и циклы — они делают нас удивительно продуктивными. Однако одним из недостатков написания кода на высокоуровневом языке является потенциальное значительное снижение скорости работы программы. Поэтому компиляторы стараются автоматически оптимизировать код и увеличить скорость работы. В наши дни логика оптимизации стала очень сложной: компиляторы преобразуют циклы, условные выражения и рекурсивные функции; удаляют целые блоки кода. Они оптимизируют код под процессорную архитектуру, чтобы сделать его действительно быстрым и компактным. И это очень здорово, ведь лучше фокусироваться на написании читабельного кода, чем заниматься ручными оптимизациями, которые будет сложно понимать и поддерживать. Кроме того, ручные оптимизации могут помешать компилятору выполнить дополнительные и более эффективные автоматические оптимизации. Вместо того чтобы писать оптимизации руками, лучше бы сосредоточиться на дизайне архитектуры и на эффективных алгоритмах, включая параллелизм и использование особенностей библиотек.

Данная статья посвящена оптимизациям компилятора Visual C++. Я собираюсь обсудить наиболее важные техники оптимизаций и решения, которые приходится применить компилятору, чтобы правильно их применить. Моя цель не в том, чтобы рассказать вам как вручную оптимизировать код, а в том, чтобы показать, почему стоит доверять компилятору оптимизировать ваш код самостоятельно.

Эта публикация для тех, кто вынужден по долгу службы пользоваться pgcpp компилятором или поддерживать совместимость кода с этим компилятором.

На днях я получил баг репорт, что мой код неправильно работает, если его скомпилировать при помощи pgcpp.

Начав разбираться, я нашел место, где происходит ошибка. Оказалось, что если код компилируется с O2 или O3 оптимизацией, то std::sort может начать дублировать часть вектора и заменять этими дубликатами другие части.

Вот простой C++ код, который поможет воссоздать это ужасное поведение (обратите внимание на число 3193 в выводе):

Продолжение предыдущего поста.



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