Инструменты пользователя

Инструменты сайта



// Идея для BadUSB

Если создать USB-устройство, которое реализует интерфейс пера или тачскрина с абсолютными координатами, задать для осей X и Y значения:

  • min = 0
  • max = 65535

и сделать (эмуляция) хотя бы одно перемещение, то, как минимум, Windows 8, 8.1 и 10 реагируют BSOD и перезагрузкой. Linux работает нормально.

// C++17 Features

Пока лучший, что я нашёл, обзор новых фич C++17 с примерами и информацией о поддержке в компиляторах:

А вот обзор от команды Яндекса, которая теперь представляет РГ21 C++ Россия:

Вот и другие авторы начинают подтягиваться, в том числе - официальные источники:

// C++: алгоритмы с бинарным предикатом и значением

Или век живи - век учись.

Проблема описана здесь: https://stdcpp.ru/proposals/1386b162-0cde-49b7-a41e-90f2d9ee477c.

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

// Qt Creator, CMake: отображение всех файлов в стоковом плагине

Немного в сторону от CMakeProjectManager2, в направлении стокового плагина.

Дискуссия на LOR навела на мысль. Ради спортивного интереса попробовал реализовать и… получилось! :)

За подробностями под кат.

// CMakeProjectManager2: теперь и с Server Mode

Вот и прошло почти два месяца с последних изменений.

Время было потрачено:

  1. для ожидания некоторой стабилизации апстрима, так как, по сути, они требовали писать абсолютно новый код для реализации текущего функционала, а в условиях сильных и фатальных изменений, переписывать свой код на каждый чих… у меня столько времени нет.
  2. была предпринята неудачная попытка продвинуть код в апстрим.
  3. ну и изучался новый код, когда выпадало время, плюс раздумья - как применить функциональность и для серверного режима работы CMake.

Так как код отвергли, а это, по сути, написанная с нуля реализация старого функционала, то он был взят за основу новых изменений. Ну как основу - 99%.

Есть и изменения. Малой кровью была создана обёртка поверх Server Mode Reader'а, которая предоставляет всего его внутренние профиты за исключением классического вида дерева файлов.

Соответственно изменения, сделанные для старого ридера (Tealeaf Reader), который используется для версий CMake младше 3.7, в части отображения всех файлов, добавления, удаления и переименования теперь применимы и для Server Mode Reader.

Сразу же был найден и первый баг: неправильно обрабатываются дефайны из CMAke (add_definition()). Патч уже отослан, у себя в коде изменений делать не буду, подожду, пока попадёт в апстрим, потом засинхронизируюсь.

Функциональность же передачи Toolchain файлов выла дропнута. Можно делать настройки через Kit или же вручную создать параметр CMAKE_TOOLCHAIN_FILE и задать нужный. Главное не забудьте сделать Build → Clear CMake Configuration после этого. Ну и будьте готовы, что парсер C++ вас перестанет понимать, как минимум, частично.

Пакеты для Ubuntu 14.04 и 16.04 и производных уже доступны через PPA. Не забываем внимательно читать описание репозитория.

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

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

Ну и с ошибками и предложениями: https://github.com/h4tr3d/cmakeprojectmanager2/issues

// CMakeProjectManager2 возвращается

В продолжение Qt Creator, CMake и судьба CMakeProjectManager2.

Ревью https://codereview.qt-project.org/#/c/180827/ расставило точки над i: "Project View == Build System View", билд система не может отображать все файлы проекта? Значит не будем показывать. Билд система не предоставляет возможности добавлять, переименовывать и удалять файлы в проекте? Значит не будем даже пытаться предоставить возможность это делать. Не удобно? Ничего, целостность концепции важнее.

Хотя… мне одному кажется, что абстракции тут текут? Ведь Project View сам по себе подразумевает именно проект?

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

Ну и обоснование всего одно: «Я боюсь баг-репортов».

Неприятно, что у меня куча идей, а код из-за сервер-мода будет очень сильно меняться ещё, теперь держать кодовую базу в актуальном состоянии будет всё сложнее (более тяжёлые мёржи).

В любом случае, сейчас будет перезагрузка кода, потому как для новой кодовой базы, по сути, написан новый код. Сейчас буду думать, как наименьшей кровью в истории перенести новые изменения. Скорее всего придётся заревертить все прошлые мои изменений, привести master в состояние идентичное qtc-master, после чего просто сделать новый комит.

Ну а родной менеджер начнёт поддерживать данную функциональность, только кода CMake Server Mode сподобится на это. Удачи в ожидании :) Особенно при том условии, что конкуренты (KDevelop, Clion) это умеют делать.

// Qt Creator, CMake и судьба CMakeProjectManager2

Проект в стадии прекращения работы над ним…

// C++ и хорошие практики

Существуют хорошие практики программирования и их стоит изучать. Часть из них применима не всегда. Часть стандартов хорошо себя зарекомендовала, но стоят денег, например MISRA C++, но, помимо цены, ещё и достаточно консервативен и покрывает только язык до стандарта C++11 (выпущен в 2008 году).

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

  • The C++ Core Guidelines - естественно на первом месте, руководство от, можно сказать, создателей, корифеев языка. Основные составители Бьярне Страуструп, Герб Саттер и, конечно, сообщество. Развивается оперативно и быстро адаптируется под новые фишки стандарта.
  • High Integrity C++ Coding Standard - коротко и по делу. Немного пояснения: https://en.wikipedia.org/wiki/High_Integrity_C%2B%2B. Сейчас покрывает C++11. На этот стандарт даёт отсылки MISRA C++ 2008.
  • Все книги из Скотта Майерса из серии Эффективное программирование на C++.

Ну и на затравку: писать надёжный софт на C++ можно - C++ on Mars: Incorporating C++ into Mars Rover Flight Software ;-)

И стоит помнить, что есть практики, есть стандарты, но не стоит выключать свой мозг и обкладываться паттернами, бустом и прочими непотребствами, если вам нужно вывести всего лишь «Hello, world!».

// CMake и Qt Creator: на пути к CMake server mode

В транке появилась пачка изменений, ориентированные на использование CMake Server Mode, в связи с чем плагин теперь может работать только с CMake версии 3.0 и более новым. Тобиас крепко взялся за плагин и будем надеяться, что, как минимум, скоро не будет требоваться:

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

Пока CMake Server Mode большего не предоставлят: в основном информация, но не изменение её. Так что ожидать автоматическое добавление файла к нужной цели или переименование файла в билд-системе средствами этого нового режима не стоит.

Ну а в самом QtC пока только инфраструктурные изменения, чтобы эту фичу начать поддерживать.

И от себя: в CMakeProjectManager2 добавил возможность использовать трюк от cmake, что бы задать варианты возможных значений для какого-то параметра и выводить их при редактировании в виде выпадающего списка. Фичу портировал в апстрим и завёл ревью, кому нужно, голосуйте: https://codereview.qt-project.org/#/c/173340

Про сам трюк:

Если коротко, то в вашем CMakeLists.txt, для задания возможных значений для параметра, нужно добавить конструкцию:

set_property(CACHE OptionName PROPERTY STRINGS PossibleValue1 PossibleValue2 PossibleValue3 ... PossibleValueN)

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

Ссылки по теме:

// IncludeOS

Не мог обойти вниманием сиё творение.

Ребята запилили на суровом C++11/14 однозадачную сервисо-ориентированную операционку. Суть: операционка с минимальным футпринтом (образ 707кб), которая обслуживает ровно одну задачу (в их терминологии - сервис) и работает под управлением виртуальной машины: KVM, VirtualBox, используя возможности аппаратной виртуализации.

Сама операционка внутри представлена в виде асинхронного фреймворка, призванного, в первую очередь, строить сетевые приложения. Т.е. внутри реализован стек TCP/IP (судя по описанию, пока только IPv4, но IPv6 активно пилится). Многопоточность не поддерживается, реализован подход с кооперативной многозадачностью, которых очень хорошо ложится на асинхронную модель. Есть базовая поддержка файловых и дисковых операций (как минимум есть поддержка RAM-диска и файловых систем Ext4 и FAT).

При всём этом доступны для использования libc++ от LLVM (в том числе исключения), stdc в лице newlib.

В общем, интересное решение для сервис-ориентированных архитектур, для создания выделенных микросервисов. Плюс приятная лицензия: Apache2.

Ну и ссылки:

// Awesome C++

Вырвано из G+:

С сайта:

A curated list of awesome C/C++ frameworks, libraries, resources, and shiny things

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

Список раньше хостился на GitHub, теперь обрёл второе рождение в виде сервиса.

Система рейтингов и меток должна помогать выбирать полезное. Как будет работать на самом деле - покажет время.

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

// std::string_view и временные объекты

Идея поста родилась при употреблении чая во внутрь на южной кухне.

Недавно смотрел один доклад (точнее бегло просматривал) про Rust и в момент, когда начался рассказ про life-time, глаз зацепился за такой опасный пример из мира C++:

string get_url()
{
  return "http://htrd.su";
}
 
string_view get_schema(string_view v)
{
  // тут какие-то действия, я их опущу
  auto result = v;
  return result;
}
 
int main()
{
  auto v = get_schema(get_url());
}

Что такое string_view - смотреть тут или тут. Если коротко - это невладеющая строка. Полезна для экономии на аллокациях, когда нужно работать с частями исходной строки.

В общем, из природы string_view следует и проблемы в коде выше: get_url() вернёт временный объект, который будет уничтожен в конце выражения, а следовательно, v будет ссылаться на невалидный участок памяти.

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

// C++ и 2D графика

Навеяно.

Из того, что мне понравилось:

    • Язык: C
    • Реализация: библиотека
    • Реально проста для простых применений. Куча примеров и статей в интернете. Поддерживает достаточно большое число платформ и компиляторов.
    • Язык: C++
    • Реализация: header-only
    • Библиотека отличается феноменальной простотой установки: только один заголовочный файл и всё. Минусом будет только тот факт, что нужно будет указать правильные флаги линковщика для целевой платформы. Но при этом весь базовый функционал для рисования и процессинга изображений присутствует. Дружится с OpenCV. Думаю, стоит рассматривать вариант этой библиотеки, когда нужно что-то по-быстрому нарисовать.
    • Язык: C++
    • Реализация: библиотека
    • С данной библиотекой особо не имел дел. Но примеры представляют её эдаким вариантом SDL, но на C++. Стоит попробовать.

Кроме того, на ресурсе cppreference.com есть свой список библиотек под различные задачи (в дополнение к предыдущему посту), и, в частности, для графики.

ЗЫ по ссылке выше есть интересная библиотечка для пользовательского интерфейса (GUI): nana, стоит пощупать. А так же для TUI: cwidget.

ЗЗЫ прочие ссылки:

// Коллекция ресурсов по современному C++

На RSDN промелькнуло, может ещё кому полезно будет:

Кто хочет дополнить - шлите мёрж-реквесты.

Прочие полезные ссылки, спасибо @sikmir:

// Полезные алиасы для программиста

Пока речь пойдёт про алиасы (alias) для man. Потом, может быть, что-то будет дополнено.

MAN

Часто возникает вопрос: «man чаво?». Кроме того, интересные программистам документы, обычно, находятся в секциях 2 (системные вызовы), 3 (библиотечные вызовы) и 7 (стандарты, соглашения, обзоры). По назначению других секций можете спрашивать:

  man # intro

где # - номер секции от 1 до 7.

В общем родилось три алиаса: для обращения и для поиска.

Для использование, код ниже поместить в ~/.bashrc

alias man-prog='man -s 2,3,7'
alias man-prog-search='man -s 2,3,7 -K'
alias man-prog-apropos='man -s 2,3,7 -k'

Первый - просто ограничивает область поиска и по man-prog printf выведет не описание команды, а описание функции.

Второй - обеспечивает полнотекстовый поиск по страницам, третий - по индексу (apropos). В чём разница. Поясню на примере:

$ man-prog-apropos tcp
clnttcp_create (3)   - library routines for remote procedure calls
clock_getcpuclockid (3) - obtain ID of a process CPU-time clock
getcpu (2)           - determine CPU and NUMA node on which the calling thread is running
pthread_getcpuclockid (3) - retrieve ID of a thread's CPU time clock
QwtCPointerData (3)  - (неизвестный объект)
sched_getcpu (3)     - determine CPU on which the calling thread is running
svctcp_create (3)    - library routines for remote procedure calls
tcp (7)              - TCP protocol
zmq_tcp (7)          - 0MQ unicast transport using TCP

Вроде всё хорошо. Дальше:

$ man-prog-apropos TCP_CORK
TCP_CORK: ничего подходящего не найдено.

Оппа… В гуголь лезть? А если так:

$ man-prog-search TCP_CORK
--Man-- след: sendfile(2) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]
--Man-- след: sendfile64(2) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]
--Man-- след: sendmsg(2) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]
--Man-- след: sendto(2) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]
--Man-- след: splice(2) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]
--Man-- след: tcp(7) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]

в man 7 tcp мы найдём искомое описание.

// std::cout, std::cerr и std::clog

Сначала немного информации из мира С.

При запуске приложения (речь идёт о POSIX) вместе с ним открывается 3 файловых дескритоптора:

  • 0 - ассоциирован со стандартным вводом (stdin)
  • 1 - ассоциирован со стандартным выводом (stdout)
  • 2 - ассоциирован со стандартным выводом в поток ошибок (stderr)

В стандартной библиотеки Си используется FILE*-based буфферизируемый доступ к файлам и терминалу. В stdio.h объявлены следующие глобальные символы, которые отражают стандартные потоки ввода вывода:

  • stdin
  • stdout
  • stderr

Соответственно их свободно можно использовать вместе с семейством функций fread()/fprintf(), обеспечивая буфферизированный доступ.

Сами файловые дескрипторы POSIX объявляет через макросы в unistd.h:

  • STDIN_FILENO
  • STDOUT_FILENO
  • STDERR_FILENO

Соответственно их свободно можно использовать со всем семейством функций read(), write() и, даже, select()/epoll() и fcntl() (например, при помощи fcntl(O_NONBLOCK)+select+read можно реализовать аналог getch() из старого доброго Borland C++). Доступ через эти функции не буфферизирован.

Доступ к одному потоку разными механизмами в одной программе лучше не осуществлять: буферизация это уровень библиотеки C и внутреннего устройства FILE. write() или read() ближе к системным вызовам и ничего про это знать не обязаны. Как результат можете получить перемешивание текста даже в однопоточном приложении. Это не отменяет того файла, что сам fwrite() может, в конце концов, вызвать write().

На этом экскурс закончим и вернёмся в C++.

В C++ для работы с потоками служит библиотека iostream. Причём доступ к конкретному стриму может быть как буфферизируемым так и не буфферизируемым (зависит от потребностей).

Библиотека декларирует объекты, связанные со стандартными потоками:

  • std::cin - стандартный ввод
  • std::cout - стандартный вывод
  • std::cerr - стандартный вывод ошибок и
  • std::clog - для логирования

Про std::cin особо гооврить (пока?) не будем - он один, в своём роде. А вот про оставшиеся три стоит.

Итак, начнём с std::cout и std::cerr. В C++ они, помимо того, что связаны с разными дескрипторами, несколько отличаются поведением:

  • std::cout - буферизируемый
  • std::cerr - не буферизируемый

Такое отличие явственно следует из семантики использования: ошибку нужно увидеть сразу без ожидания каких-то дополнительных действий со стороны программиста типа std::flush или std::endl (он, кстати, делает и flush, поэтому, для большей производительности строки в нормальном выводе стоит заканчивать '\n', а не std::endl).

Ок, а что за std::clog? А это всего-лишь std::cerr + буферизация. И снова, семантика использования проста: диагностика может чуть и подождать, что бы не понижать производительность вывода, но смешиваться с нормальным выводом не есть хорошо, мы, ведь, можем использовать приложения в пайпе и, желательно, разделить диагностику и ошибки от обычного вывода.

Собственно, немного обобщая:

  • std::cout - используется для обычного вывода результатов работы программы на экран, эти данные могут быть переданы дальше по пайпу для обработки.
  • std::cerr - вывод сообщений об ошибке в обработке, что бы не подмешивались в основной поток и не ломали логику работы других программ в пайпе. При этом сообщение выводим максимально скоро.
  • std::clog - используем для разного рода диагностических сообщений, но когда использование std::cerr замедляет вывод из-за более частого дёргания системных вызовов, при этом, не подмешиваемся в основной поток и не мешаем работе других приложений в пайплайне.

Хорошим тоном, так же, является вывод справки по программе в std::cout, если вызвано с параметрами -h|–help - тогда её удобно смотреть в, например, less без дополнительных телодвижений, а вот справку по опциям, в случае неправильной установки какого-то параметра (или пропуска обязательного), лучше выводить (тут особой разницы не вижу) в std::cerr или std::clog.

И, на последок, лекция по поводу тормозов iostream и вообще, а как оно там внутри устроено:

// Source Specific Multicast и Asio

Недавно на ru.SO проскочил вопрос: как можно подключиться к SSM (Source Specific Multicast) группе?

Нюанс в том, что для этого используется опция `MCAST_JOIN_SOURCE_GROUP` для которой нет объекта-обёртки. Но, как оказалось, такой объект пишется самостоятельно на раз-два. Под катом я продублирую свой ответ, как пример подхода реализации нужного функционала. Пример не самый идеологически правильный, но, как оказалось, рабочий. Автор сам предложил свой вариант с захватом сырого хендла. Такой подход тоже имеет смысл в некоторых ситуациях2).

2) у меня случилось однажды так подружить сетевые абстракции Asio и libev, реализовав, тем самым, реактор на Asio :-)

// GeoCrop 1.0

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

Так что да будет так: https://github.com/h4tr3d/geocrop/releases/tag/v1.0

// Новый режим в GeoCrop

Теперь в GeoCrop появился новый режим: генерация полигона для обрезки рамки в формате CSV+WKT. Вывод на stdout, так что можно сохранить в любой удобный файл из скрипта, после чего использовать как аргумент для -cutline у gdalwarp в какой-то более сложной команде. Вызова gdalwarp при этом не происходит.

Активируется режим опцией -g (от [g]enerate). Указывать выходной файл при этом не нужно - он будет проигнорирован.

Так же, теперь появилась возможность указывать файл с описанием проекции: -p srs_file. Сама проекция должна быть в формате WKT или PROJ.4. Эта опция перезаписывает определение проекции в текущем файле. Полезна для преобразования файлов с привязками в виде world-файлов. Более того, если проекция в файле пустая, а опция не указана то произведётся попытка прочитать её автоматически из файла с таким же именем, но с расширением .prj или .prf (какой первый попадётся). Так что популярные карты ГГЦ с такими привязками теперь можно конвертировать так же просто, как и с привязками Ozi Explorer.

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

geocrop -f VRT -s 200k K-53-07.map K-53-07.vrt -- -overwrite

опция -overwrite будет передана gdalwarp. Помимо этого, теперь можно переопределить и сам исполняемый файл gdalwarp - опция -w GDALWARP.

Кроме того изменился формат опций, стало возможным указывать выходной формат (опция -f FMT, как следствие, образовались такие возможности: Быстро и ненавязчиво готовим карту для открытия в QMapShack) или только обрезать рамку, не делая кроп (опция -n).

// Обновление Qt Creator

Пока LOG, Habrahabr и другие гудят по поводу смены лицензионной политики в части Qt (переход на LPGL3) и QtC (переход с LGPL2.1 на GPL3 /именно GPL/ с исключением для плагинов), у меня дошли руки обновить PPA: https://launchpad.net/~adrozdoff/+archive/ubuntu/qtcreator-git

Ну и несколько интересных (для меня) изменений, которые стали доступны в этом билде. Добро пожаловать под кат.

// C++11: несуразность std::thread

Пост-вопрос.

Может кто объяснить, почему в стандарт вошла настолько обрезанная версия реализации std::thread? Ведь предлагаемый интерфейс не предоставляет абсолютно никаких средств передачи параметров потоку в момент создания, к примеру, тот же размер стека, что крайне актуально на всяких RTOS. При этом Boost.Thread такую возможность предоставляют средствами boost::thread::attributes:

    template <class F>
    explicit thread(attributes& attrs, F f);
 
    template <class F>
    thread(attributes& attrs, F &&f);
 
    template <class F, class ...Args>
    explicit thread(attributes& attrs, F&& f, Args&&... args);

Средства хоть и лимитированные, но доступ к native_handle атрибута позволяют тюнить параметры на конкретной платформе. Но в стандартной библиотеке нет и их. Нипанимать. Explain. Explain.

PS libstdc++ зато предоставляет достаточно простые средства, что бы добавить поддержку своих потоков (на той же RTOS), не прибегая к модификации кода библиотеки (если кому интересно, могу на пальцах разбросать как, но без полной реализации).

// C++: категории итераторов

Добротное разъяснение (кому непонятно это и это (ну и по ссылкам отсюда)) категорий итераторов на ru.SO:

// MinGW GCC 5 в Trusty

Сделал PPA, куда положил MinGW GCC 5: https://launchpad.net/~adrozdoff/+archive/ubuntu/mingw

Версия GCC на момент написания поста: 5.3.0. Сборка зависит от репозитория https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test/+packages (если надумаете собирать сами).

Краткие характеристики сборки:

  • Модель потоков: только posix (требуется libwinpthreads), т.к. позволяет использовать все возможности C++11/C++14. Если будет спрос на win32, то нужно только добавить одну строчку и чуть подкорректировать альтернативы (т.е. сборка поддерживает, просто выключил win32).
  • Обработка исключений: sjlj для win32 и seh для win64
  • Сборка для Win32 и Win64

Добавление репозитория:

  sudo apt-add-repository ppa:adrozdoff/mingw

Установка:

  sudo apt-get install gcc-5-mingw-w64 g++-5-mingw-w64

Компилятор с суффиксом -5, что бы не конфликтовать с тем, что распространяется вместе с Ubuntu/Mint.

В этом же репозитории планирую выкладывать сборки библиотек.

// Выбор дефолтного компилятора в Ubuntu/Mint/Debian

Создать альтернативы:

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 99
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 10
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-5   20
 
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 99
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.9 10
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-5   20
 
sudo update-alternatives --install /usr/bin/cc cc /usr/bin/gcc 99
sudo update-alternatives --set cc /usr/bin/gcc
 
sudo update-alternatives --install /usr/bin/c++ c++ /usr/bin/g++ 99
sudo update-alternatives --set c++ /usr/bin/g++

После чего можно переключаться вручную через меню:

sudo update-alternatives --config gcc
sudo update-alternatives --config g++

или скриптом:

sudo update-alternatives --set gcc /usr/bin/gcc-5
sudo update-alternatives --set g++ /usr/bin/g++-5

или вернуть в автоматический режим:

sudo update-alternatives --auto gcc
sudo update-alternatives --auto g++

Снести альтернативы:

sudo update-alternatives --remove-all gcc 
sudo update-alternatives --remove-all g++

Или только указанную:

sudo update-alternatives --remove gcc /usr/bin/gcc-4.9
sudo update-alternatives --remove g++ /usr/bin/g++-4.9

В последнем случае, подберётся другая альтернатива (на основе приоритета) и выбор будет выставлен в auto. Если альтернатив нет, то будут почищены все симлинки.

На основе: http://askubuntu.com/questions/26498/choose-gcc-and-g-version

// Про использование ссылок и указателей в C++

Данная статья практически на 100% отражает и мой подход к использованию ссылок и указателей, рекомендую к ознакомлению:
http://eao197.blogspot.ru/2015/11/progthoughts-c.html

Тезисно:

  • void f(const T &p) ожидает реально существующий объект, но не изменяет его;
  • void f(T &p) ожидает реально существующий объект и изменяет его;
  • void f(const T *p) ожидает объект или nullptr, если объект существует, то не изменяет его;
  • void f(T *p) ожидает объект или nullptr, если объект существует, то изменяет его;
  • void f(unique_ptr<T> p) ожидает объект или nullptr; если объект существует, то забирает ответственность за его удаление;
  • void f(shared_ptr<T> p) ожидает объект или nullptr; если объект существует, то разделяет владение этим объектом (что дает право функции f() сохранить p у себя для дальнейшего использования или передать кому-то еще).

// C++: inline namespace

Как-то упустил сей момент:

Вообще FAQ стоит перечитать.

// О качестве документации и понимании сути

Есть такой чип: Cypress FX3. Это чип для построения USB 3.0 устройств. Внутри железная реализация протокола, 512кБ памяти и ядро ARM926E-JS. Cypress предоставляет SDK, в котором поставляется RTOS ThreadX и необходимый код для работы с их железом.

Как и классических встраеваемых SDK есть возможность ставить пользовательские колбеки и, по сути, управлять и строить логику конкретного приложения, ну и реализовать нужное вам USB 3.0 (2.0 тоже) устройство.

// Qt Creator из Git, VirtualBox и Linux Guest

Заголовок не отражает всей сути. Конкретно:

Проблема: при запуске крешится. Выводится такой стек-трейс:

Нажмите, чтобы отобразить

Нажмите, чтобы скрыть

alexd@alexd-VirtualBox ~ $ qtcreator-git
libGL error: pci id for fd 18: 80ee:beef, driver (null)
OpenGL Warning: glFlushVertexArrayRangeNV not found in mesa table
OpenGL Warning: glVertexArrayRangeNV not found in mesa table
OpenGL Warning: glCombinerInputNV not found in mesa table
OpenGL Warning: glCombinerOutputNV not found in mesa table
OpenGL Warning: glCombinerParameterfNV not found in mesa table
OpenGL Warning: glCombinerParameterfvNV not found in mesa table
OpenGL Warning: glCombinerParameteriNV not found in mesa table
OpenGL Warning: glCombinerParameterivNV not found in mesa table
OpenGL Warning: glFinalCombinerInputNV not found in mesa table
OpenGL Warning: glGetCombinerInputParameterfvNV not found in mesa table
OpenGL Warning: glGetCombinerInputParameterivNV not found in mesa table
OpenGL Warning: glGetCombinerOutputParameterfvNV not found in mesa table
OpenGL Warning: glGetCombinerOutputParameterivNV not found in mesa table
OpenGL Warning: glGetFinalCombinerInputParameterfvNV not found in mesa table
OpenGL Warning: glGetFinalCombinerInputParameterivNV not found in mesa table
OpenGL Warning: glDeleteFencesNV not found in mesa table
OpenGL Warning: glFinishFenceNV not found in mesa table
OpenGL Warning: glGenFencesNV not found in mesa table
OpenGL Warning: glGetFenceivNV not found in mesa table
OpenGL Warning: glIsFenceNV not found in mesa table
OpenGL Warning: glSetFenceNV not found in mesa table
OpenGL Warning: glTestFenceNV not found in mesa table
libGL error: core dri or dri2 extension not found
libGL error: failed to load driver: vboxvideo
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0000000001deadb0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0000000001deadb0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
OpenGL Warning: glXGetFBConfigAttrib for 0000000001deadb0, failed to get XVisualInfo
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0000000001deadb0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
OpenGL Warning: glXGetFBConfigAttrib for 0000000001deadb0, failed to get XVisualInfo
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0000000001deadb0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
OpenGL Warning: glXGetFBConfigAttrib for 0000000001deadb0, failed to get XVisualInfo
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0000000001deadb0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
OpenGL Warning: glXGetFBConfigAttrib for 0000000001deadb0, failed to get XVisualInfo
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0000000001deadb0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
OpenGL Warning: glXGetFBConfigAttrib for 0000000001deadb0, failed to get XVisualInfo
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0000000001deadb0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
OpenGL Warning: glXGetFBConfigAttrib for 0000000001deadb0, failed to get XVisualInfo
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0000000001deadb0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
OpenGL Warning: glXGetFBConfigAttrib for 0000000001deadb0, failed to get XVisualInfo
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0000000001deadb0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
OpenGL Warning: glXGetFBConfigAttrib for 0000000001deadb0, failed to get XVisualInfo
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0000000001deadb0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
Could not initialize GLX
0  libLLVM-3.6.so.1           0x00007fe411df7912 llvm::sys::PrintStackTrace(_IO_FILE*) + 34
1  libLLVM-3.6.so.1           0x00007fe411df5eb1
2  libpthread.so.0            0x00007fe431190340
3  libc.so.6                  0x00007fe43085ecc9 gsignal + 57
4  libc.so.6                  0x00007fe4308620d8 abort + 328
5  libQt5Core.so.5            0x00007fe43143230e
6  libqxcb-glx-integration.so 0x00007fe4325e52dc
7  libqxcb-glx-integration.so 0x00007fe4325e60f8
8  libqxcb-glx-integration.so 0x00007fe4325e484b
9  libQt5XcbQpa.so.5          0x00007fe429bbcf91 QXcbIntegration::createPlatformOpenGLContext(QOpenGLContext*) const + 49
10 libQt5Gui.so.5             0x00007fe4303e721d QOpenGLContext::create() + 45
11 libUtils.so.1              0x00007fe43205afc5 Utils::HostOsInfo::canCreateOpenGLContext(QString*) + 165
12 libQmlDesigner.so          0x00007fe40a098f2c QmlDesigner::QmlDesignerPlugin::initialize(QStringList const&, QString*) + 28
13 libExtensionSystem.so.1    0x00007fe4323111e6 ExtensionSystem::Internal::PluginSpecPrivate::initializePlugin() + 246
14 libExtensionSystem.so.1    0x00007fe43230920c ExtensionSystem::Internal::PluginManagerPrivate::loadPlugin(ExtensionSystem::PluginSpec*, ExtensionSystem::PluginSpec::State) + 828
15 libExtensionSystem.so.1    0x00007fe43230d070 ExtensionSystem::Internal::PluginManagerPrivate::loadPlugins() + 256
16 qtcreator                  0x0000000000409a31
17 libc.so.6                  0x00007fe430849ec5 __libc_start_main + 245
18 qtcreator                  0x0000000000409db2
Аварийный останов

Существует какая-то проблема в реализации поддержки OpenGL в гостевых расширениях VirtualBox. В результате это аффектит два плагина: QmlDesigner и QmlProfiler.

В качестве work-around можно не загружать эти плагины (для меня не критично, но для кого-то может оказаться - очень, но тогда добивайтесь более действенного результата сами). Для этого сначала запустить Qt Creator так:

qtcreator-git -noload QmlDesigner -noload QmlProfiler

после чего выключить загрузку этих плагинов в настройках и запускать QtC обычным образом.

// День программиста

С праздником, коллеги! Что бы не было в вашем коде:

#define TRUE FALSE

// Qt5, OpenGL и Ubuntu/Mint

Временами, при сборке ловится такое:

/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status

При этом в системе наблюдается такое:

$ locate libGL.so
/usr/lib/i386-linux-gnu/mesa/libGL.so.1
/usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0
/usr/lib/insync/libGL.so.1
/usr/lib/nvidia-346-updates/libGL.so
/usr/lib/nvidia-346-updates/libGL.so.1
/usr/lib/nvidia-346-updates/libGL.so.346.82
/usr/lib/x86_64-linux-gnu/mesa/libGL.so
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
/usr/lib/x86_64-linux-gnu/primus/libGL.so.1
/usr/lib32/nvidia-346-updates/libGL.so
/usr/lib32/nvidia-346-updates/libGL.so.1
/usr/lib32/nvidia-346-updates/libGL.so.346.82

Т.е. вроде всё есть, но чего-то не хватает. А не хватает того, что они живут в директориях, которые не видны линковщику. Для рантайма средство есть через aternatives:

x86_64-linux-gnu_gl_conf
x86_64-linux-gnu_egl_conf

Для девелопмента должен стоять пакет libgl1-mesa-dev. После его установки станет так:

$ ls -l /usr/lib/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 13 марта 12 08:47 /usr/lib/x86_64-linux-gnu/libGL.so -> mesa/libGL.so

Проблема в том, что пакет стоит, а файла нет… Скорее всего были какие-то нюансы при обновлении или ещё чего. Лечится:

sudo apt-get install --reinstall libgl1-mesa-dev

// C++11: std::error_code & std::error_condition в GCC 4.8/4.9 и 5.1

Кусок кода:

    auto ecod = make_error_code(std::errc::resource_unavailable_try_again);
    auto econ = make_error_condition(std::errc::resource_unavailable_try_again);
    assert(ecod == econ);

Согласно документации ассерт не должен срабатывать. Компилятор GCC 4.8 и 4.9 в Linux Mint собирает код и выдаёт такое при запуске:

$ ./webserver
webserver: webserver.cpp:661: int main(int, char**): Assertion `ecod == econ' failed.
Aborted

Внезапно.

GCC 5.1 собирает и нормально обрабатывает ситуацию.

// AvCpp: API-2 rework, веха вторая

Продолжаем отслеживать судьбу изменений, описанных в AvCpp: API-2 rework, веха первая.

Как обычно, объём работ отличается от того, что было запланировано. Итак, что сделано:

  1. Работа со словарями и поддержка оных во всех местах, где только можно. Это вызвало необходимость разнести открытие входного потока и поиск информации о стриме (Снова FFmpeg и low-latency). Как следствие, добавился новый вызов: av::FormatContext::findStreamInfo(). Он может принимать коллекцию словарей для каждого стрима в потоке.
  2. Начата работа над фильтрами. Уже появилась базовая инфраструктура. Но пока нет понимания в каком виде оно должно получиться на выходе.
  3. В рамках чистки кода тотально переработана обработка ошибок. Теперь это делается через std::error_code, который передаётся опциональным аргументом в те функции фейл которых может приводить к неоднозначностям в будущем. Если переменная для кода ошибки не передана, будет выброшено исключение av::Exception которое будет содержать данный код. Планируется, что набор исключений расширится под каждую сущность. Данные изменений повлекли достаточно сильные изменений в API, требующие изменений в коде приложений, которые их используют. При обработке ошибок стоит учитывать категорию оных. На дынный момент используется, как минимум три:
    • avcpp_category() - для внутренних ошибок AvCpp
    • ffmpeg_category() - для ошибок, пришедших от FFmpeg
    • system_category() - для системных ошибок, в основном так рапортуются ошибки выделения памяти при помощи встроенных av_alloc() (когда владение принимается FFmpeg'ом и он сам освобождает, как следствие, использовать new/new[] нет возможности). Целесообразность использовать std::bad_alloc обдумывается.

Ну и главное, реорганизация бранчей:

  • все наработки первой вехи выделены в отдельный бранч api-2.0 (исправляются только ошибки)
  • старый мастер стал бранчем api-legacy (для совместимости, самостоятельно тут ничего не исправляется, только принимаются мерж-реквесты)
  • вся разработка перемещена на бранч master

Что осталось:

  1. Интерфейс опций
  2. Доделать фильтры
  3. Ревизия и чистка кода в т.ч. примеров.

Планируется, что это будет сделано в следующей, третье вехе.

Как обычно, за отзывы, багрепорты и пул-реквесты буду благодарен.

// Снова FFmpeg и low-latency

В дополнение к моей прошлой заметке: x264 low latency пару статей на эту же тему, но без привязки к x264:

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

В общем, согласно документации:

The above code attempts to allocate an AVFormatContext, open the specified file (autodetecting the format) and read the header, exporting the information stored there into s. Some formats do not have a header or do not store enough information there, so it is recommended that you call the avformat_find_stream_info() function which tries to read and decode a few frames to find missing information.

Суть: просто открыть файл не всегда достаточно, что бы делать предположения о некоторых параметрах файла. Походу, с этим нужно просто смириться или попытаться предпринять меры из ссылки 1, а именно зарезать параметры probesize и analyzeduration в 32 (минимально допустимое значение).

// Новые интересные фичи в Qt Creator Master

Для начала: создал репозиторий PPA, куда буду с разной периодичностью бубликовать снапшот QtC из master-бранча. Кроме того, туда же поместил свой плагин CMakeProjectManager2:
https://launchpad.net/~adrozdoff/+archive/ubuntu/qtcreator-git

Установка:

sudo add-apt-repository ppa:adrozdoff/qtcreator-git
sudo apt-get update
sudo apt-get install qtcrator-git qtcreator-git-plugin-cmake2

Для разработчиков плагинов будет полезен пакет qtcretor-git-dev который ставит в /usr/src/qtcreator-git заголовочники и .pri файлы. Пример использования можно поглядеть в спеках отстройки qtcreator-git-plugin-cmake2:

sudo apt-get install qtcrator-git-dev

Ну а теперь фичи.

Кодовая модель

Уже давно появились приятные дополнительные инструменты вроде «Reparse Externally Changed Files» (удобно при наличии внешних генераторов, тот же протобуф) и «Inspect C++ Code Model…», позволяющая понять, что не так при парсинге и отослать более вменяемый отчёт.

Сравнительно же недавно появилась возможность задавать индивидуально для каждого файла дополнительные директивы препроцессора: «Additional Preprocessor Directives…». Очень удобная штука, когда парсинг почему-то затыкается (например какая-то опция может подхватываться из переданных CXXFLAGS) - обозначил и вперёд! Или правишь код на одной системы, а нужно исправить блок для другой: определяем «#define WIN32» и пробуем что получилось. Для быстрого доступа служит иконка с «#» в верхнем правом углу рядом с номером строки и колонки.

GUI

Тоже появилось сравнительно давно, многие просили: открытие в новом окне (Window → Open in New Window иди Ctrl+E,4). Удобно при навигации и рефакторинге при наличии нескольких мониторов.

CMake

Про свой плагин не пишу. В мейнстриме появилась возможность задавать не один фиксированный cmake, а разные для разных наборов инструментов (Kits).

External Tools

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

Либо вызвать cppcheck на текущий проект, либо… что в голову взбредёт.

Чего хотелось бы, но нет

- Настройки лицензии (шапки для новых файлов) индивидуально для проекта. - Замена отдельных частей Kit индивидуально для проекта - Более гибкая система настройки устройств для Baremetal: сейчас устройство намертво привязано к Kit со своими настройками доступа к, примеру, OpenOCD и gdb. Вот для Cypress SDK нужно как минимум два: для основной прошивки и для Bootloader.

Засим пока всё.

// CMake для Cypress FX3

Слишком много параметров сборки появилось. Поэтому на досуге да под эгидой нового продукта наваял правила для сборки кода при помощи CMake: https://github.com/h4tr3d/fx3-cmake

Под виндой нужно обязательно указывать генератор: при использовании `cs-make` поставляемого вместе с SDK это «MinGW Makefiles».

// AvCpp: API-2 rework, веха первая

Для начала, что такое AvCpp - это C++ враппер над FFmpeg, позволяющий несколько упростить работу непосредственно с функциями FFmpeg.

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

Изначально структура классов опиралась на Xuggle API, ведь когда начинал его делать, многое не понимал - почему оно так. Со временем такой подход перестал мне нравится, начали вылазить всякие неприятные оверхеды, баги. Так появился подпроект API-2, цели которого:

  1. Уйти где только можно от shared_ptr (это получилось почти везде).
  2. Использовать по максимуму возможности новых версий FFmpeg, где появился reference-counting для AVFrame/AVPacket, при этом предоставить возможности создавать «тяжёлые» копии, где нужно.
  3. Более логично организовать мапинг сущностей FFmpeg в AvCpp, к примеру, если раньше AVCodecContext мапился в av::StreamCoder, то теперь av::CodecContext, аналогично для AVFormatContext (av::Container vs av::FormatContext).
  4. Корректно реализовать аудио-ресемплер
  5. Добавить побольше примеров использования API2
  6. Работа с av_options для поддерживаемых сущностей
  7. Поддержка передачи параметров через словари
  8. Тотальная переработка фильтров
  9. Чистка кода, удаление ненужных сущностей

На текущий момент на бранче api-2 уже лежат почти все эти наработки. Нереализованными остались последние 4 пункта. Приэтому, попутно, устранено несколько багов, особенно связанных с последовательностью уничтожения разных объектов (например Stream2 и FormatContext: стримом владеет FormatContext, Stream2 только предоставляет доступ к нему, при этом, даже если уничтожить объект контекста, объект Stream2 может теперь корректно рапортовать, что он инвалидировался).

Вторая веха, судя по всему, будет реализация поддержки AVOptions/AVDict, третья веха - фильтры (к слову их сейчас нет вообще в рамках API-2). Последующие вехи пока не сформированы, скорее всего нужно будет подумать над возможностями использования аппаратного ускорения для декодирования (оно достаточно некрасиво и в самом FFmpeg реализовано - нужно делать много телодвижений).

В любом случае, я уже настоятельно рекомендую начинать использовать ветку api-2. В скором времени она заместит master-ветку, а текущий мастер переедет на ветку legacy.

За отзывы, багрепорты и пул-реквесты буду благодарен.

// CMakeProjectManager2: улучшения в диалоге конфигурирования (2)

Очередная порция изменений в развитие CMakeProjectManager2: улучшения в диалоге конфигурирования:

  1. Исправлен креш при создании конфигурации, при указании тулчейн файла, когда он лежит в директории исходников. Изредка креш проявлялся при переключении уже готовых конфигураций.
  2. Добавлена кнопка обзора для выбора тулчейн-файла. По умолчанию открывается в дереве исходников проекта, если тулчейн выбран в другом месте (к примеру, у вас коллекция тулчейнов независимых от проекта), то открывается в месте, где лежит тулчейн. В быстрые закладки добавляется ссылка на дерево проекта, что бы было можно быстро туда перейти. Закрыта задача #2.
  3. Добавлена возможность очищать кеш при запуске CMake, что бывает необходимо при изменении некоторых параметров, одним из них, к примеру, является CMAKE_TOOLCHAIN_FILE, другим популярным (особенно при выборе разных версий Qt) является CMAKE_PREFIX_PATH. Изменение этих параметров без удаления кеша ни к чему не приводит, поэтому добавил параметр «Reset cache on CMake run». Стоит отметить, что при изменении тулчейна это действие обязательно, поэтому, если тулчейн поменялся, но этот параметр не включен, то будет выдаваться вопрос: «You change toolchain. This action requires CMake cache reset. Continue?». Закрыл задачу #1
  4. При встроенном редактировании тулчейна теперь открывается не пустое окно, если ничего не было, а пример тулчейна для Mingw. Можно оставлять только опции, задающие компилятор, что бы выбрать нужную версию оно в системе, если их стоит несколько.
  5. Небольшое косметическое изменение: кнопка Edit стала поменьше.

// CMakeProjectManager2: улучшения в диалоге конфигурирования

Для тех, кто не в курсе, что такое CMakeProjectManager2, вот ссылка на статью 2012 года: CMakeProjectManager2 - последние изменения. Собственно тогда и были сделаны последние крупные изменения, которых мне хватало до сегодняшнего дня. В остальном была работа по синхронизации кодовой базы с апстримом, что бы плагин продолжал собираться и радовать глаз. Код располагается на GitHub: https://github.com/h4tr3d/cmakeprojectmanager2. Инструкции по сборке приложены в README.txt

Итак, как бы ни хотелось, но времени заниматься реализацией TODO листа нет и не предвидится (суть списка: сделать парсер и обойтись без генерации файла для CodeBlocks, а всё остальное уже на это опирается). Но есть и другие задачи. В частности, в сегодняшнем обновлении несколько изменён вид окна «Run CMake» мастера, а именно:

  1. Добавлена возможность выбирать тип сборки
  2. Добавлена возможность назначать тулчейн (это файл с настройками среды сборки, особенно актуально для кросс-сборки: http://www.vtk.org/Wiki/CMake_Cross_Compiling#The_toolchain_file).

По сути, эти параметры служат для задания в более дружественной формы параметров для CMake: -DCMAKE_BUILD_TYPE= и -DCMAKE_TOOLCHAIN_FILE= соответственно.

Про тулчейн немного подробнее. Изначально планировалось три способа его задания:

  1. Автоматическое конструирование на основе Qt Creator Kit
  2. Ручное задание файла (пока сделано без возможности открытия диалога поиска, только ручной ввод: issue #2)
  3. «Инлайн» тулчейн: редактирует во встроенном редакторе, при запуске контент сохраняется в директории отстройки под именем QtCreator-toolchain-override.cmake

Пока вариант на основе Qt Creator Kit выключен. Будет время - доделаю.

Плюс есть нюанс: согласно документации CMake, смена тулчейна возможно только на новой конфигурации либо на полной очистке текущей (удаления CMakeFiles и CMakeCache.txt), поэтому, если замечены изменения настроек тулчейна, производится полное переконфигурирование без использования кеша. Планирую добавить диалог с предупреждением (issue #1).

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

Ну и картинка:

// C++11: паттерн Transaction

Переосмысление реализации паттерна Transaction, опубликованного в "Inside C++", в рамках стандарта C++11 с блек… variadict templates и хранением данных на стеке.

// Practical Guide to Bare Metal C++

Недавно наткнулся на эту книжку на GitBook: http://arobenko.gitbooks.io/bare_metal_cpp/

Доступна для онлайн-чтения, в виде форматов ePUB, MOBI и PDF. Рассматриваются вопросы уменьшения размера приложений, написания своих реализаций ABI функций, что позволяет более детально понимать, а что там вообще внутри происходит, что бывает полезно и обычных приложениях. Вместе с ней обязательно ознакомиться с Scott Meyers. Effective C++ in an Embedded Environment.

Книга больше ориентирована на ARM, в частности Raspberry PI, но идеи адаптировать к другим платформам труда не составит.

// Threads и fork: дважды подумайте

Да, дважды подумайте перед тем как смешивать их: http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them

// MinGW и локали

Если коротко, то всё, что связано с std::locale в MinGW не работает. Точка.

Зато вполне себе работает функционал из Си:

std::locale::global(std::locale("")); // не установит текущую локаль
setlocale(LC_ALL, ""); // установит текущую локаль, у меня это Russian_Russia.Cp1251

// Пополняем шпаргалки по C++: неявно-генерируемые перемещающий конструктор и оператор присваивания

Статью изначально публиковал на хабре: http://habrahabr.ru/post/232775/. Здесь - для единства мыслей :)

Когда не так часто, как хотелось бы, приходится работать с языком, некоторые аспекты забываются. А некоторые никогда и не откладываются в голове. Поэтому, когда возникают вопросы, приходится отвлекаться и лезть в документацию.

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

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

Шпаргалки представлены в виде PDF файлов для печати на принтере A4, в виде картинки PNG, а также исходников в SVG.

// hex ↔ bin в уме

Однажды писал про двоичные литералы в GCC: 0b00100100, новый стандарт C++14 закрепил их в C++.

Но тут я хотел бы рассмотреть лёгкий способ перехода в уме между hex и bin представлениями.

// C++14: Done

Стандарт отправился в печать: https://isocpp.org/blog/2014/08/we-have-cpp14

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

// erase_if

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

// Const correctness

Ничего нового, просто ссылки:

  1. http://www.cprogramming.com/tutorial/const_correctness.html - для чего нужно и почему, а так же логическая и побитовая константность.

Если коротко, то что даёт применение ключевого слова const везде, где это уместно:

  1. Уберегает вас от некоторых ошибок, связанных с внезапным изменением данных в каких-то вызовых. Т.е. добавляет безопасности.
  2. Автодокументирование кода: вы выдите const ⇒ вы знаете, что данные не меняются ни в этом вызове, ни далее по иерархии.

Побитовая константность - когда при вызове ни один бит структуры или класса не меняется.

Логическая константность - когда при вызове какие-то поля могут меняться, но данные, отвечающие за логику класса не изменяются.

Обычно последнее связано с полями, которые имеют спецификатор mutable. Для чего они нужны? Самый простой пример: экземпляр класса может использоваться из разных потоков. Писать может один поток, а читать другой. Логично, что метод для чтения будет константным. Так же логично, что чтение и запись следует защитить мьютексом. Но если мы попробуем заблокировать мьютекс в константном методе, получис ошибку компиляции. Понятно, что изменение мьютекса никак не влияет на логическую константность класса, поэтому его можно объявить mutable и спокойно защищать им данные.

Из примера выше можно сделать такое неформальное заключение:

Побитовая константностью - неиболее сильная. Логическая - более слабая.

// std::begin() и std::end()

С приходом нового стандарта эти две свободные функции появились в STL, в библиотеке итераторов (#include <iterator>). Кроме того, в примерах кода часто можно увидеть, что они используются на STL контейнерах вместо собственных методов .begin() и .end():

#include <iostream>
#include <vector>
#include <iterators>
 
using namespace std;
 
int main()
{
  vector<int> v{1, 2, 3, 4, 5};
 
  for (auto it = begin(v); it != end(v); ++it)
  {
    cout << "Number: " << *it << endl;
  }
 
  return 0;
}

Мне хорошо понятно, что эти функции отлично подходят для RAW-массивов, т.е. если в примере выше заменить:

vector<int> v{1, 2, 3, 4, 5};

на

int v[] = {1, 2, 3, 4, 5};

или даже

int v[]{1, 2, 3, 4, 5};

То весь остальной код менять не нужно. Удобно, причём мы защищены от подсовывания указателя вместо массива. Но почему они применяются для STL контейнеров?

Поиск по интернету дал только один ответ: для унификации. И только.

Т.е. ни по «кошерности» ни по скорости два этих подхода не отличаются. Чисто для единства вида.

Если у кого есть другие предположения - милости просим в дискуссию.

Ссылки

// Qt Creator и C++11

Небольшая заметка о том, как форсировать поддержку C++11 в парсере для различных билд-систем. Заметки касаются master-снапшота QTC (брать тут: http://download.qt-project.org/snapshots/qtcreator/master/latest/ или собирать из исходников).

Нужно отметить, что синтаксис нового стандарта поддерживается сейчас по-умолчанию. Проблемы касаются правильного определения констант компилятора, подключения частей стандартной библиотеки и т.п.

// C++ и копирование перекрывающихся областей

Программируя на Си многие сталкивались с такими функциями как memcpy() и memmove(), по сути, функции делают одно и тоже, но вторая корректно отрабатывает ситуацию, когда области памяти перекрываются (на что появляются дополнительные накладные расходы).

В мире С++ никто не запрещает пользоваться этими функциями (часто эти функции используют различные механизмы оптимизации и могут статься быстрее своих собратьев из мира C++), но есть и более родное средство, работающее через итераторы: std::copy. Это средство применимо не только к POD типам, а к любым сущностям, поддерживающим итераторы. О деталях реализации в стандарте ничего не сказано, но можно предположить, что разработчики библиотеки не настолько глупы, что бы не использовать, оптимизированные memcpy()/memmove() когда это возможно.

Но по наитию, хочется посмотреть, а что там с пересекающимися областями (overlapping memory blocks)? Ведь задача, на самом деле, не такая уж редкая. К примеру, хотим мы читать MPEG-TS пакеты (размер каждого 188 байт, каждый пакет начинается с 0x47 /sync byte/) из какого-то потока, и есть вероятность, что первое (а может и последующее, либо имеем дело с M2TS контейнером, размер блока которого 192 байта и лишние 4 байта в большинстве случаем мы можем игнорировать) чтение может попасть на середину пакета. В таких случаях обычно делается так: вычитываем блок 188 байт, далее ищем байт синхронизации, если он в нулевой позиции - всё отлично, если нет, то данные от него и до конца, нужно переместить в начало блока, в освободившееся место нужно дочитать недостающу порцию, после чего пакет считается вычитанным и можно отдавать его на обработку.

Наглядно процесс копирования данных в начало блока можно показать этой картинкой:

Т.е. видим, что есть перекрытие. Логично, было бы применить какой-то аналог memmove(), но в стандартной библиотеке есть только std::move который делает совершенно не то. Но при этом, читая описание для std::copy (http://www.cplusplus.com/reference/algorithm/copy) видим следующую строчку:

The ranges shall not overlap in such a way that result points to an element in the range [first,last).

т.е. на самом деле, если начало области (result) куда копировать, лежит вне области [first,last), то всё должно быть ок. И это реально так.

Но посмотрим такую схему копирования с перекрытием:

пока не обращаем внимание на то, что result тут в конце. Смысл картинки в том, что блок памяти нужно сдвинуть с начала на какое-то смещение вперёд, соответственно если это смещение меньше размера сдвигаемого блока, то адрес назначения у нас будет лежать в пределах [first,last), таким образом условие применимости std::copy не соблюдаются. И если применить его, мы просто затрём данным в перекрывающейся области.

Но тут на помощь нам приходит его собрат, как раз решающий эту проблему: std::copy_backward, всё отличие этой функции в том, что он осуществляет копирование с конца. Т.е. для случая изображённой на второй картинке, он возьмёт (далее очень грубо, т.е. на самом деле last и result это указатели на конец блока, а ближайшие данные находятся по last-1 и result-1) элемент из last и ложится в result, далее из last-1 в result-1, далее из last-2 в result-2 и так далее.

Видно, что при такой схеме копирования, когда мы начнём писать в перекрывающуюся область, данные в ней уже будут обработаны. Т.е. для нас всё хорошо. Забавно, что условие применимости при перекрывающийся областях для std::copy_backward слово в слово повторяет данное условие для std::copy.

Итак, резюмируя, простое правило:

  • Если result < first («сдвиг блока к началу /или влево/»), то применяем std::copy, в качестве result указываем НАЧАЛО блока-назначения.
  • Если result > first («сдвиг блока к концу /или вправо/»), то применяем std::copy_backward, в качестве result указываем КОНЕЦ блока-назначения.

Текст является творческим переосмыслением англоязычной статьи: http://www.trilithium.com/johan/2006/02/copy-confusion, картинки взяты от туда же, пример из собственного опыта.

Референс:

PS Статья была опубликована на Habrahabr: http://habrahabr.ru/post/218451