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

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



// 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

// KDevelop 4.6 в Linux Mint

Ставим из PPA kubuntu-ppa/backports. Подробности:

А если коротко:

sudo add-apt-repository ppa:kubuntu-ppa/backports 
sudo apt-get update
sudo apt-get install kdevelop

// Android SDK/NDK в Linux Mint

Просто последовательность действий - на память (брать из PPA не хотелось). Как качать NDK, SDK и Android Studio я расписывать не буду. Распаковку всего этого добра произвёл в ~/Android. Имена директорий привёл к виду (или переименованием или созданием необходимых симлинков):

  • android-sdk
  • android-ndk
  • android-studio

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

Итак…

Необходимое

  1. Ставим OpenJDK: sudo apt-get install openjdk-7-jdk libswt-cairo-gtk-3-jni libswt-cairo-gtk-3-jni ant
  2. В ~/.profile или ~/.bashrc_profile прописываем:
    export ANDROID_HOME=$HOME/Android/android-sdk
    export ANDROID_NDK=$HOME/Android/android-ndk
    # For compability
    export NDK_HOME=$ANDROID_NDK
    export ANDROID_SWT=/usr/share/java
    export PATH=$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools:$ANDROID_NDK:$HOME/Android/android-studio/bin
    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ANDROID_HOME/tools/lib
  3. Переходим в ~/Android/android-studio/bin и выполняем:
    ln -s studio.sh android-studio
  4. Добавляем следующие параметры в studio.vmoptions и studio64.vmoptions (предварительно сделайте резервные копии, пригодятся при обновлениях):
    -Dswing.aatext=true
  5. На этом шаге можно перелогиниться, вызвать android и поставить платформы, утилиты, потом запустить Android Studio и сделать необходимые настройки.

Опциональное

Ярлыки в меню

FIXME относительные пути к иконкам не воспринимаются, поэтому иконки не отображаются, только текст.

  1. Создаём файл: ~/.local/share/applications/android-sdk.desktop со следующим содержимым:
    [Desktop Entry]
    Encoding=UTF-8
    Name=Android SDK
    Comment=Android Sofware Development Kit
    Exec=android
    Icon=~/Android/android-sdk/tools/apps/SdkController/res/drawable-xhdpi/ic_launcher.png
    Terminal=false
    Type=Application
    Categories=IDE;Development;

    Если иконка не будет отображаться, замените на полный путь.

  2. Извлекаем иконку Android Studio:
    unzip -o lib/resources.jar artwork/icon_AS_128.png

    Вызываем команду из корня android-studio

  3. Создаём файл: ~/.local/share/applications/android-studio.desktop:
    [Desktop Entry]
    Version=1.0
    Type=Application
    Name=Android Studio
    Exec=android-studio %f
    Icon=~/Android/android-studio/artwork/icon_AS_128.png
    Comment=Develop with pleasure!
    Categories=Development;IDE;
    Terminal=false
    StartupNotify=true
    StartupWMClass=jetbrains-android-studio
    MimeType=application/x-extension-iml;

Автодополнение BASH

Автодополнение для команд android, adb, emulator, fastboot и repo.

  1. Идём в ~/Android
  2. Забираем последнюю версию скрипта (предполагаю, что git уже установлен):
    git clone https://github.com/mbrubeck/android-completion.git
  3. Создаём файл ~/.bash_completion и помещаем в него:
    . $HOME/Android/android-completion/android
    . $HOME/Android/android-completion/repo
  4. Перелогиниваемся

// Big-endian и little-endian: шпаргалка

Big-endian Little-endian
Формулировка Старшие разряды (байты) - первые Младшие разряды (байты) - первые
Запись M = sum{i=0}{n} {A_i} * {B^i} = A_0 * B^0 + A_1 * B^1 + cdots + A_n * B^n
B - база системы счисления, для dec - 10, для hex - 0xFF или 256.
A_0 - младший разряд, A_n - старший разряд
An, …, A1, A0 A0, A1, …, An
1024 (dec), 0x0400 (hex)
dec 1, 2, 0, 4 4, 0, 2, 1
hex 0x40, 0x00 0x00, 0x40
Синонимы Network byte order
Motorola byte order
Intel byte order
VAX order
Использование Обычная для человека1) запись чисел (в том
числе шестнадцатиричных в C/C++ и других)
TCP/IP
PNG
Числа в памяти на x86 и некоторых других
USB
PCI
1)
Для письма слева-направо

// На заметку: чисто виртуальные функции с определением

Да, речь про такое:

struct Foo {
  virtual ~Foo()      = 0; // [1]
  virtual void proc() = 0; // [2]
};
 
// [3]
Foo::~Foo() {
  // some actions
}
 
// [4]
void Foo::proc() {
  // some actions
}

[3] и [4] для [1] и [2] соответственно могут находится в другом файле.

Информации в интернете много, поэтому заметка для себя, ибо где-то пропустил в изучении. Далее мои домысли и моё понимание проблемы.

Начнём с [2].

Такое нужно:

  1. когда требуется, что бы в наследниках эти функции были обязательно определены (т.е. были чисто виртуальными в базовом),
  2. но при этом требуется, что бы была предоставлена реализация по умолчанию.

Например:

struct Bar : Foo {
  virtual void proc() {
    // здесь полностью своя реализация
  }
};
 
struct Baz : Foo {
  virtual void proc() {
    // а здесь мы позвали реализацию по умолчанию.
    Foo::proc();
  }
};
 
struct Bak : Foo {
  // а такой класс мы инстанцировать не сможем
};

А теперь про [1]

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

/tmp/cc42YqK5.o: In function `Bar::~Bar()':
main.cpp:(.text._ZN3BarD2Ev[_ZN3BarD5Ev]+0x1f): undefined reference to `Foo::~Foo()'
collect2: error: ld returned 1 exit status

Т.е. тело у деструктора должно быть всегда (ну не совсем, см. ниже). Так когда возникает необходимость сделать деструктор базового класса чисто виртуальным с определением? Мне в голову пришло только:

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

Поясню. Если сделать так:

struct Virtuable {
  virtual ~Virtuable() {}
};

Все классы-наследники автоматом будут с виртуальными деструкторам, но при этом мы можем сделать такое:

Virtuable f;
Virtuable *p = new Virtuable;

Т.е. мы можем создать объекты-пустышки. А зачем нам это? Если же объявить класс так:

struct Virtuable {
  virtual ~Virtuable() = 0;
};
 
Virtuable::~Virtuable() {}

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

Имхо, может быть полезно во всяких фабриках.

// Онлайн компиляторы C/C++ и не только

Иногда нужно быстро проверить работоспособность какой-то идеи или алгоритма. Хорошо, когда у вас Linux и какая-то система из семейства Unix с установленным компилятором (имхо, в 90% случаев это будет правдой), вам просто нужно открыть консоль вызвать vim/emacs/joe/mcedit/etc набросать программку и вызвать компилятор. Но иногда вы в гостях/командировке/интернет-кафе, в общем тогда, когда компилятора нет под рукой, но есть доступ в интернет. Тут помогут онлайн-компиляторы.

// Забавный баг

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

void *pool_alloc(size_t size); // выделение памяти из пула
void *pool_calloc(size_t size); // выделение памяти из пула и зануление её
void pool_free(void *ptr); // возврат (освобождение) памяти в пул

есть так же определённые операторы new/new[]/delete/delete[] для использования этого механизма в C++ коде (код сильно упрощён):

void* operator new (size_t size)
{
    return pool_alloc(size);
}
 
void* operator new[] (size_t size)
{
    return pool_alloc(size);
}
 
void operator delete (void *ptr)
{
    pool_free(ptr);
}
 
void operator delete[] (void *ptr)
{
    pool_free(ptr);
}

На этом вводная часть закончена. Переходим к сути.

Существовала испокон веков некая большая структура (в терминологии C++ - POD тип), и код, использующий её был повсеместно на чистом C. Назовём эту структуру так:

struct BigStruct 
{
    // a lot of fields
};

Соответственно память под эту структуру выделялась и освобождалась так:

...
big_struct_ptr = (struct BigStruct*)pool_calloc(sizeof(struct BigStruct)); // память сразу занулялась
...
pool_free(big_struct_ptr);
...

Время шло, код постепенно «переписывался» на C++. В кавычках, потому как это «переписывание» сводилось к изменению расширения файла на .cpp и исправлению очевидных ошибок и предупреждений (тут, с одной стороны, используется -Werror как опция для GCC, с другой стороны, предупреждение включены далеко не все). И вот, в один прекрасный момент, весь код, который использует эту структуру, уже компилируется C++ компилятором. Как результат, при очередной фиче или багофиксе в структуре появляется поле типа

std::vector<Foo> some_field;

То есть, одним мановением руки, структура перестаёт быть POD-типом, но… Механизм выделения и освобождения памяти для неё не меняется!

Теперь сделайте паузу и пофантазируйте, к чему это приводит.

На практике, это решение жило около двух лет (на момент написания статьи) и никак себя не проявляло. А приводило оно к постепенной утечке памяти: для std::vector не вызывался ни конструктор ни деструктор. Отсутствие вызова конструктора проходило незаметно, в этом конкретном примере «спасало» то, что память занулялась и у класса нет vtable. А вот отсутствие вызова деструктора приводило к тому, что все аллокации, сделанные внутри вектора, не освобождались. Маскировало эту проблему то, что аллокации были очень маленькие (около 4 байт), и их было немного за весь период нормальной работы аппарата от момента включения до выключения.

Выявило нагрузочное тестирование, где один алгоритм прогонялся атипичное, для нормальной работы, количество раз (помогло логирование вызовов new при помощи gcc'шной __builtin_return_address(), objdump -d и базовые знания ассемблера).

// Qt Creator и perforce

UPD: Изменения, на основе этого патча, заинтегрированы в Qt Creator другим человеком. От меня была только ревью кода.

Во времена, когда проект Qt и все смежные тулы были под управлением VCS Perforce, появился плагин для Qt Creator'а для интеграции работы с этой системой, да вот только в своём развитии он конкретно и застрял в тех стародавних временах. Причина проста: проект переехал на Git, а перфорс нафиг никому не сдался. Как результат: плагин есть, и даже собирается, да вот только считать его хоть малость рабочим… не получается.

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

При этом, это вроде как работает, когда забиваешь настройки, да вот только они там и поселяются навсегда, прибитые к одному серверу и одному пользователю. А кроме того, за директорию верхнего уровня принимается текущая рабочая директория (читать: та, из которой запущен Qt Creator).

Немного повозившись, родился патч:

Perforce-VCS-plugin-fix-top-level-directory-detection.patch
From c111318c78acb2b7ddd41533de3577fa7dc64b1d Mon Sep 17 00:00:00 2001
From: Alexander Drozdov <adrozdoff@gmail.com>
Date: Tue, 10 Sep 2013 17:33:55 +1100
Subject: [PATCH] Perforce VCS plugin: fix top-level directory detection
 
---
 src/plugins/perforce/perforcechecker.cpp        | 21 ++++++++-
 src/plugins/perforce/perforcechecker.h          |  5 ++-
 src/plugins/perforce/perforceconstants.h        |  2 +-
 src/plugins/perforce/perforceplugin.cpp         | 57 ++++++++++++++++++++-----
 src/plugins/perforce/perforceplugin.h           | 16 ++++++-
 src/plugins/perforce/perforceversioncontrol.cpp |  2 +-
 6 files changed, 86 insertions(+), 17 deletions(-)
 
diff --git a/src/plugins/perforce/perforcechecker.cpp b/src/plugins/perforce/perforcechecker.cpp
index 5971c00..b9b0395 100644
--- a/src/plugins/perforce/perforcechecker.cpp
+++ b/src/plugins/perforce/perforcechecker.cpp
@@ -28,6 +28,7 @@
 ****************************************************************************/
 
 #include "perforcechecker.h"
+#include "perforceconstants.h"
 
 #include <utils/qtcassert.h>
 #include <utils/synchronousprocess.h>
@@ -78,7 +79,8 @@ void PerforceChecker::resetOverrideCursor()
 
 void PerforceChecker::start(const QString &binary,
                             const QStringList &basicArgs,
-                            int timeoutMS)
+                            int timeoutMS,
+                            const QString &workingDirectory)
 {
     if (isRunning()) {
         emitFailed(QLatin1String("Internal error: process still running"));
@@ -91,6 +93,15 @@ void PerforceChecker::start(const QString &binary,
     m_binary = binary;
     QStringList args = basicArgs;
     args << QLatin1String("client") << QLatin1String("-o");
+
+    if (Perforce::Constants::debug)
+        qDebug() << "PerforceChecker::start: [" << workingDirectory << "]" << m_binary << args;
+
+    if (!workingDirectory.isEmpty())
+    {
+        m_process.setWorkingDirectory(workingDirectory);
+    }
+
     m_process.start(m_binary, args);
     m_process.closeWriteChannel();
     // Timeout handling
@@ -105,6 +116,11 @@ void PerforceChecker::start(const QString &binary,
     }
 }
 
+bool PerforceChecker::waitForFinished(int msec)
+{
+    return m_process.waitForFinished(msec);
+}
+
 void PerforceChecker::slotTimeOut()
 {
     if (!isRunning())
@@ -169,6 +185,9 @@ static inline QString clientRootFromOutput(const QString &in)
 
 void PerforceChecker::parseOutput(const QString &response)
 {
+    if (Perforce::Constants::debug)
+        qDebug() << "PerforceChecker::parseOutput: " << response;
+
     if (!response.contains(QLatin1String("View:")) && !response.contains(QLatin1String("//depot/"))) {
         emitFailed(tr("The client does not seem to contain any mapped files."));
         return;
diff --git a/src/plugins/perforce/perforcechecker.h b/src/plugins/perforce/perforcechecker.h
index e466250..aada848 100644
--- a/src/plugins/perforce/perforcechecker.h
+++ b/src/plugins/perforce/perforcechecker.h
@@ -50,10 +50,13 @@ public:
 public slots:
     void start(const QString &binary,
                const QStringList &basicArgs = QStringList(),
-               int timeoutMS = -1);
+               int timeoutMS = -1,
+               const QString &workingDirectory = QString());
 
     bool isRunning() const;
 
+    bool waitForFinished(int msec = -1);
+
     bool useOverideCursor() const;
     void setUseOverideCursor(bool v);
 
diff --git a/src/plugins/perforce/perforceconstants.h b/src/plugins/perforce/perforceconstants.h
index 316fc24..1f8c2a1 100644
--- a/src/plugins/perforce/perforceconstants.h
+++ b/src/plugins/perforce/perforceconstants.h
@@ -55,7 +55,7 @@ const char SUBMIT_CURRENT[] = "Perforce.SubmitCurrentLog";
 const char DIFF_SELECTED[] = "Perforce.DiffSelectedFilesInLog";
 const char SUBMIT_MIMETYPE[] = "text/vnd.qtcreator.p4.submit";
 
-enum { debug = 0 };
+enum { debug = 1 };
 
 } // Constants
 } // Perforce
diff --git a/src/plugins/perforce/perforceplugin.cpp b/src/plugins/perforce/perforceplugin.cpp
index 8fd5957..1f9480d 100644
--- a/src/plugins/perforce/perforceplugin.cpp
+++ b/src/plugins/perforce/perforceplugin.cpp
@@ -824,7 +824,11 @@ bool PerforcePlugin::managesDirectory(const QString &directory, QString *topLeve
     const bool rc = managesDirectoryFstat(directory);
     if (topLevel) {
         if (rc)
+        {
+            if (Perforce::Constants::debug)
+                qDebug() << "Top Level: " << m_settings.topLevelSymLinkTarget();
             *topLevel = m_settings.topLevelSymLinkTarget();
+        }
         else
             topLevel->clear();
     }
@@ -834,28 +838,48 @@ bool PerforcePlugin::managesDirectory(const QString &directory, QString *topLeve
 bool PerforcePlugin::managesDirectoryFstat(const QString &directory)
 {
     if (!m_settings.isValid())
+    {
+        if (Perforce::Constants::debug)
+            qDebug() << "Settings invalid";
         return false;
+    }
     // Cached?
     const ManagedDirectoryCache::const_iterator cit = m_managedDirectoryCache.constFind(directory);
     if (cit != m_managedDirectoryCache.constEnd())
-        return cit.value();
+    {
+        const DirectoryCacheEntry &entry = cit.value();
+        if (Perforce::Constants::debug)
+            qDebug() << "Directory: " << directory << " is cached and managed: " << entry.isManaged;
+
+        setNewTopLevel(entry.topLevel);
+
+        return entry.isManaged;
+    }
     // Determine value and insert into cache
     bool managed = false;
     do {
         // Quick check: Must be at or below top level and not "../../other_path"
         const QStringList relativeDirArgs = m_settings.relativeToTopLevelArguments(directory);
         if (!relativeDirArgs.empty() && relativeDirArgs.front().startsWith(QLatin1String("..")))
-            break;
+        {
+            if (Perforce::Constants::debug)
+                qDebug() << "Directory " << directory << " is a relative path to current top level dir [" << relativeDirArgs << "], try find new top level.";
+            getTopLevel(directory, true);
+        }
         // Is it actually managed by perforce?
         QStringList args;
         args << QLatin1String("fstat") << QLatin1String("-m1") << perforceRelativeFileArguments(relativeDirArgs);
         const PerforceResponse result = runP4Cmd(m_settings.topLevel(), args,
                                                  RunFullySynchronous);
+
+        if (Perforce::Constants::debug)
+            qDebug() << "Perforce result:\n" << result.stdOut << "\n---\n" << result.stdErr << "\n---\n" << result.message;
+
         managed = result.stdOut.contains(QLatin1String("depotFile"))
                   || result.stdErr.contains(QLatin1String("... - no such file(s)"));
     } while (false);
 
-    m_managedDirectoryCache.insert(directory, managed);
+    m_managedDirectoryCache.insert(directory, DirectoryCacheEntry(managed, m_settings.topLevel()));
     return managed;
 }
 
@@ -1489,12 +1513,7 @@ PerforceVersionControl *PerforcePlugin::perforceVersionControl() const
 
 void PerforcePlugin::slotTopLevelFound(const QString &t)
 {
-    m_settings.setTopLevel(t);
-    const QString msg = tr("Perforce repository: %1").
-                        arg(QDir::toNativeSeparators(t));
-    VcsBase::VcsBaseOutputWindow::instance()->appendSilently(msg);
-    if (Perforce::Constants::debug)
-        qDebug() << "P4: " << t;
+    setNewTopLevel(t);
 }
 
 void PerforcePlugin::slotTopLevelFailed(const QString &errorMessage)
@@ -1504,7 +1523,7 @@ void PerforcePlugin::slotTopLevelFailed(const QString &errorMessage)
         qDebug() << errorMessage;
 }
 
-void PerforcePlugin::getTopLevel()
+void PerforcePlugin::getTopLevel(const QString &workingDirectory, bool isSync)
 {
     // Run a new checker
     if (m_settings.p4BinaryPath().isEmpty())
@@ -1514,7 +1533,23 @@ void PerforcePlugin::getTopLevel()
     connect(checker, SIGNAL(failed(QString)), checker, SLOT(deleteLater()));
     connect(checker, SIGNAL(succeeded(QString)), this, SLOT(slotTopLevelFound(QString)));
     connect(checker, SIGNAL(succeeded(QString)),checker, SLOT(deleteLater()));
-    checker->start(m_settings.p4BinaryPath(), m_settings.commonP4Arguments(QString()), 30000);
+    checker->start(m_settings.p4BinaryPath(), m_settings.commonP4Arguments(QString()), 30000, workingDirectory);
+
+    if (isSync)
+        checker->waitForFinished();
+}
+
+void PerforcePlugin::setNewTopLevel(const QString &newTopLevel)
+{
+    if (m_settings.topLevel() != newTopLevel)
+    {
+        m_settings.setTopLevel(newTopLevel);
+        const QString msg = tr("Perforce repository: %1").
+                            arg(QDir::toNativeSeparators(newTopLevel));
+        VcsBase::VcsBaseOutputWindow::instance()->appendSilently(msg);
+        if (Perforce::Constants::debug)
+            qDebug() << "P4: " << newTopLevel;
+    }
 }
 
 #ifdef WITH_TESTS
diff --git a/src/plugins/perforce/perforceplugin.h b/src/plugins/perforce/perforceplugin.h
index 8eeb1e2..8e08500 100644
--- a/src/plugins/perforce/perforceplugin.h
+++ b/src/plugins/perforce/perforceplugin.h
@@ -146,7 +146,18 @@ protected:
 
 
 private:
-    typedef QHash<QString, bool> ManagedDirectoryCache;
+    struct DirectoryCacheEntry
+    {
+        DirectoryCacheEntry(bool isManaged, const QString &topLevel)
+            : isManaged(isManaged),
+              topLevel(topLevel)
+        {}
+
+        bool    isManaged;
+        QString topLevel;
+    };
+
+    typedef QHash<QString, DirectoryCacheEntry> ManagedDirectoryCache;
 
     Core::IEditor *showOutputInEditor(const QString& title, const QString output,
                                       int editorType, const QString &source,
@@ -193,7 +204,8 @@ private:
     bool isCommitEditorOpen() const;
     QSharedPointer<Utils::TempFileSaver> createTemporaryArgumentFile(const QStringList &extraArgs,
                                                                      QString *errorString) const;
-    void getTopLevel();
+    void getTopLevel(const QString &workingDirectory = QString(), bool isSync = false);
+    void setNewTopLevel(const QString &newTopLevel);
     QString pendingChangesData();
 
     void updateCheckout(const QString &workingDir = QString(),
diff --git a/src/plugins/perforce/perforceversioncontrol.cpp b/src/plugins/perforce/perforceversioncontrol.cpp
index 19303a6..ad4f35b 100644
--- a/src/plugins/perforce/perforceversioncontrol.cpp
+++ b/src/plugins/perforce/perforceversioncontrol.cpp
@@ -178,7 +178,7 @@ bool PerforceVersionControl::managesDirectory(const QString &directory, QString
         QDebug nsp = qDebug().nospace();
         nsp << "managesDirectory" << directory << rc;
         if (topLevel)
-            nsp << topLevel;
+            nsp << *topLevel;
     }
     return rc;
 }
-- 
1.8.3.msysgit.0

// Build Boost on Windows with MinGW

Чисто заметка, без вдавания в детали.

Для начала нужно поставить MinGW и MSYS.

Сделать это можно двумя путями. Первый, это поставить и то и другое средствами mingw-get-inst: http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/

Но там только GCC 4.7.2, а мне нужен был GCC 4.8 (где брать свежие сборки MinGW я уже ранее писал, замечу только, что брать нужно версию с поддержкой threads-posix и dwarf, если вдруг захочется использовать бинарные сборки Qt). MSYS поставил при помощи mingw-get (http://sourceforge.net/projects/mingw/files/Installer/mingw-get/, а можно и вручную, скачивая и распаковывая файлы отсюда: http://sourceforge.net/projects/mingw/files/MSYS/). Распаковываем его, к примеру, в C:\msys, далее:

cd C:\msys\bin
mingw-get.exe update
mingw-get.exe install msys

После этого MSYS будет расположен в C:\msys\msys\1.0. Если потребуется ещё что-то от msys: mingw-get list вам в помощь.

Далее сборка Boost (у меня 1.53.0).

Распаковываем его, например в D:\boost_1_53_0

Настраиваем пути до компилятора (делаем это из запущенной копии cmd):

set PATH=c:\msys\msys\1.0\bin;c:\mingw\bin;%PATH%

Тут обращаю ваше внимание на один факт, за который разработчикам буста нужно малость по рукам настучать: буст соберётся хорошо только в случае, если MinGW поставлен в C:\MinGW и ни как иначе!

После чего собираем bjam:

cd D:\boost_1_53_0\tools\build\v2
bootstrap.bat gcc
b2 --prefix=C:\boost install
set PATH=%PATH%;C:\boost\bin

Теперь мы готовы собирать сам буст:

cd D:\boost_1_53_0\
bjam -j2 toolset=gcc --build-type=complete --prefix=C:\boost install

Вместо -j2 ставим нужное количество потоков сборки.

После продолжительной сборки буст будет расположен:

  • заголовки: C:\boost\include\boost-1_53
  • библиотеки: C:\boost\lib

И полезные параметры при сборке:

-Wno-unused-local-typedefs -DGLIBCXX_FORCE_NEW -D_WIN32_WINNT=0x0501 -DBOOST_THREAD_USE_LIB -DBOOST_THREAD_PROVIDES_GENERIC_SHARED_MUTEX_ON_WIN

Для совсем ленивых, напоминаю про альтернативную сборку MinGW от Стефана, в ней он уже обновил GCC до 4.8 и Boost до 1.53. Кстати, Стефан работает в Microsoft :-D

// Qt Creator: C/C++ parser and "pre-included" headers

Некоторые компиляторы (если не все) поддерживают такую функциональность: через параметр командной строки можно указать файл или файлы, которые будут подключаться автоматически к каждому обрабатываемому файлу. У GCC это опция -include <file>.

В некоторых проектах используют эту особенность, как результат - явного включения файла нет, а парсер в Qt Creator'е не видит части объявлений.

Решения единого нет: для каждого типа проекта (qmake, cmake, generic & etc), теоретически, оно своё (если есть вообще). В моём случае используется Generic project, для него решение существует.

И решение достаточно простое: Generic Project Mananger использует несколько файлов для хранения настроек проекта:

  • ProjectName.creator - головной файл, по сути не содержит никакой полезной информации
  • ProjectName.files - список файлов проекта (может содержать и не исходники)
  • ProjectName.includes - пути поиска заголовочных файлов
  • ProjectName.config - как гласит комментарий внутри этого файла: «ADD PREDEFINED MACROS HERE!»

Вот последний файл самый интересный. Комментарий немного наводит в ступор и мы решаем, что тут можно только писать код вида:

#define MACRO some_value

На самом деле, парсером этот файл воспринимается как обычный заголовочный файл и информация из него используется для парсинга всего остального. Чуете профит? Если нет, подсказываю: по сути это и есть наш «pre-included» header для парсера! И писать в нём мы можем всё, что понимается препроцессором (если быть точнее: парсером скеатора). Т.е. мы можем сделать такое:

#include "includes/pre-included.h"

И всё, что объявлено в нашем pre-included.h станет доступно парсеру при обработке каждого файла. Дело сделано!

Было бы любопытно узнать как такое можно реализовать для Qmake и Cmake проектов.

PS вопрос этот я поднял в списке рассылки Qt Creator'а, пока ждал ответ, в голову пришла идея с #include, в результате список только подтвердил моё изыскание :)

UPDATE: рано обрадовался, внезапно, решение отказалось работать. Имхо, причина в несовсем корректном использовании .config файла.

// C++ Template Metaprogramming

Что-то не нашёл официального русского перевода книги, только сделанный в частном порядке (читать сложновато): http://enotcpp.blogspot.ru/2011/11/c-template-metaprogramming-david.html

На английском: http://ultra.sdk.free.fr/misc/docs/Addison.Wesley.C++.Template.Metaprogramming.Concepts.Tools.and.Techniques.from.Boost.and.Beyond.pdf или среди торрентов: http://rutracker.org/forum/viewtopic.php?t=1140883

// Binary Logic Bit Operations In C and C++

На заметку: http://www.somacon.com/p125.php там же удобный калькулятор для перевода констант между четырмя популярными системами счисления (BIN, OCT, HEX, DEC)

// Бинарные сборки MinGW

Сайт qt-project.org навёл меня на проект http://sourceforge.net/projects/mingwbuilds/files/ где можно разжиться бинарными сборками MinGW для MacOSX, Linux, Windows.

Удобдно для использования совместно с Qt Creator на Windows.

// Qt Creator: "the debugger could not load the debugging helper library" на Windows XP

Решение подсказывают тут и тут. Если коротко: нужен GDB скомпилированный с поддержкой Python и Qt Creator на это расчитывает. По первой ссылке его рекомендуют брать в QtSDK, но качать его сильно накладно. Недолгое гугление привело на эту ссылку: http://origin.releases.qt-project.org/gdb/windows-xp/.

Устанавливатся просто: скачиваем, распаковываем, в настройках китов в Qt Creator (Tool → Options… → Build & Run → Kits) выбираем новый отладчик (для MinGW) и живём.

PS другие версии: http://origin.releases.qt-project.org/gdb/ PPS более корректные ссылки: http://builds.qt-project.org/job/gdb-windowsxp/ и http://builds.qt-project.org/job/gdb-windows/

// Scott Meyers. Effective C++ in an Embedded Environment

This PDF document contains the presentation materials from Scott Meyers' two-day training course Effective C++ in an Embedded Environment. It provides an in-depth examination of how C++ can be applied in embedded systems, including costs of language features, ROMing, ISRs, memory management, safety-critical and real-time considerations, and more.

Формат: презентация в PDF, чётко и по делу.

Для желающих получить без оплаты: effectcppemb.pdf

// OpenCV Cheat Sheet (C++)

Текщущая версия 2.4: http://docs.opencv.org/trunk/opencv_cheatsheet.pdf

Она же на этом ресурсе: opencv_cheatsheet.pdf

// Простой враппер для встроенных типов в C++

В C/C++ определение переменной не есть её инициализация. Верно для фундаментальных (или встроенных) типов. Для пользовательских типов всегда (если не указано ничего иного) вызывается конструктор по умолчанию, в котором можно принять необходимые меры по инициализации.

Враппер помогает решать задачи инициализации переменной при её объявлении, а так же при использовании в контейнерах типа std::map или std::multimap, когда нужно проверить переменную для ключа, которого ещё нет (при обращении через operator[] создастся новое значение, для которого вызовется конструктор по умолчанию).

Код:

/**
 * Can be used for built-in types only (like int, char, long and so on)
 */
template <typename T, T initialValue = 0>
struct BuiltInTypeWrapper
{
    BuiltInTypeWrapper()
        : value(initialValue)
    {}
    BuiltInTypeWrapper(T v)
        : value(v)
    {}
 
    bool isValid() const
    {
        return (value != initialValue);
    }
 
    void reset()
    {
        value = initialValue;
    }
 
    operator T&()
    {
        return value;
    }
 
    operator T const&() const
    {
        return value;
    }
 
    BuiltInTypeWrapper& operator=(T v)
    {
        value = v;
        return *this;
    }
 
    T value;
};

Для временных меток в FFMPEG можно использовать так:

/**
 * Simple wrapper for time stamp values
 */
typedef BuiltInTypeWrapper<int64_t, AV_NOPTS_VALUE> TsWrapper;

т.е. при объявлении переменной типа TsWrapper она автоматом станет инициализирована в AV_NOPTS_VALUE.

А просто для int так:

typedef BuiltInTypeWrapper<int> Integer;

При этом при объявлении переменной типа будет она будет инициализирована в 0.

За счёт определения оператора приведения типа и перегруженному оператору присваивания использование обёрнутого значения мало отличается от необёрнутого:

typedef BuiltInTypeWrapper<int64_t, AV_NOPTS_VALUE> TsWrapper;
...
 
void foo(int64_t &v)
{
    clog << v << endl;
}
 
...
 
TsWrapper wrappedValue;
int64_t   value = 255;
 
wrappedValue = value;      // 1
if (wrappedValue == value) // 2
...
 
foo(wrappedValue)          // 3
wrappedValue++;            // 4, аналогично для префиксной формы
wrappedValue--;            // 5, аналогично для префиксной формы
wrappedValue += 5;         // 6
wrappedValue -= 5;         // 7  

В общем и целом практически повторяет поведение оригинального типа.

Кто какие нюансы видит?

PS тестировалось на gcc 4.7.2

// MinGW32: как избавиться от зависимостей в виде libgcc_*.dll и libstdc++-*.dll?

Почти всегда программа (особенно маленькие и без инсталлятора) для win распространяется в виде законченного бандла со всеми DLL и прочим потребством. Проблема, что программа, скомпилированная примерно так:

i486-mingw32-g++ -o foo.exe foo.cpp

как минимум требует двух DLL: libgcc_*.dll и libstdc++-*.dll, что бы избавится от них можно использовать опции -static-libgcc и -static-libstdc++:

i486-mingw32-g++ -static-libgcc -static-libstdc++ -o foo.exe foo.cpp

// Boost shared_ptr, bind и thread

Правило: при использовании boost::bind будьте предельно осторожны при передаче аргументов в виде boost::shared_ptr (как и других типов умных указателей): по умолчанию используется семантика копирования, поэтому в полученном функторе будет храниться копия вашего указателя с увеличенным счётчиком ссылок. Данный факт, вкупе с использованием совместно с boost::thread, может стать иточником утечки ресурсов.

Ниже более детально.

// Охранные классы в boost::thread

Для начала, охранные классы, это не что иное как различные *_lock классы, реализующие идиому RAII, захватывающие мутекс в конструкторе (lock()) и освобождающие его в деструкторе (unlock()) - паттерн «блокировка в области видимости». Не смог придумать более корректного перевода.

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

// CMakeProjectManager2 - последние изменения

Как я уже писал, вяло пилю модифицированную версию плагина CMakeProjectManager для Qt Creator'а. Там же указаны причины, вынудившие меня на это. Но разговор, не про это, а про то, что с момента прошлого поста было сделано.

Итак:

  1. Для каждого профиля сборки сохраняются введённые параметры для CMake, так что, выбрав в следующий раз «Run CMake» не нужно вспоминать, с какими параметрами вы его запускали и легче управлять профилями сборки. Вкупе с последней фичей из апстрима: сохранения глобальной истории параметров для CMake, получается достаточно мощный механизм.
  2. Используя вышеприведённую информацию, появилась возможность при модификации дерева исходников (добавление, удаление, переименование) в фоновом режиме запускать обновление CBP файла и дерева сборки, что особо актуально при использовании глоббинга.
  3. По сравнению с первым вариантом, получилось значительно сократить расходование памяти при использовании плагина, особенно когда в дереве проекта много вспомогательных модулей, временного C/C++ кода.

Кодовая база периодически синхронизируется с GIT версией Qt Creator. Если кто-то будет делать клоны для стабильных релизов, просьба отписываться с информацией об оных.

HINT:
Так как, при добавлении, удалении или переименовывании файла, не осуществляется модификация CMakeLists.txt, то нужно вносить изменения самому, либо использовать globbing:

# UTILS
file(GLOB_RECURSE UTIL_SOURCES "../util/*.cpp")
file(GLOB_RECURSE UTIL_HEADERS "../util/*.h" "../util/*.hpp")

На полноценный парсер пока времени нет (хотя уже адоптирован на чистый C++/Qt оный из KDevelop), к тому же, в списке рассылки Qt Creator проскакивала новость, что одна команда разрабатывает полноценный плагин (тыц). Зная это, не хочется делать бесполезную работу, при том, что текущий функционал уже вполне удовлетворяет.

// Паттерн Iterator

Полезно, когда нужно перебирать последовательно какие-то данные, мне, в частности, потребовалось для перебора кодеков и форматов во C++ враппере для FFMPEG, а так же получения набора параметров и именованных констант, которые они могут принимать.

Основные идеи данного паттерна изложены по этой ссылке: http://sourcemaking.com/design_patterns/iterator, а возможные реализации на C++ здесь:

Сведения эти - общетеоретические. Более практическое описание с разделением итераторов на типы приведено на cplusplus.com: http://www.cplusplus.com/reference/std/iterator/, в частности вводятся понятие следующих типов итераторов (а так же наглядная таблица, по которой можно понять какие методы и операторы должны определяться в классе-итераторе):

А что бы несколько привести итераторы к одному виду, существует класс в стандартной библиотеке, называется ~std::iterator~, почитать можно здесь: http://www.cplusplus.com/reference/std/iterator/iterator/, там же приведён простой пример итератора.

// Using Internet Sockets

Работая над программой столкнулся с проблемой в части функционала сокетов, пока искал в интернетах возможный пути решения проблемы, натолкнулся на интересное руководство: Beej's Guide to Network Programming. Using Internet Sockets

Руководство доступно в в различных форматах (по ссылке выше можно найти подходящие), вот самые удобные, на мой взгляд:

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

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

Ещё, среди кучи ссылок, в тексте обнаружилась такая полезная: UNIX Socket FAQ - тоже кладезь знаний.

В дополнение, книжка «Linux Socket Programming by Example», можно купить на Амазоне: http://www.amazon.com/Linux-Socket-Programming-Example-Warren/dp/0789722410 или:

// Библиотеки для MinGW

Некоторые библиотеки находятся в AUR, некоторые собираются сами, но есть ещё такой чудный проект как Windows KDE: http://windows.kde.org/ в рамках которого, для компиляции KDE уже отстроено много библиотек.

Найти их можно:

Ну и поиграться с версиями, начиная отсюда: http://www.winkde.org/pub/kde/ports/win32/

Что самое чудное, есть версии не только для mingw, но и для VC10, а так же версии библиотек с отладочной информацией.

UPD

Для зависимостей между модулями будет полезно: http://www.winkde.org/pub/kde/ports/win32/repository-4.8/config/config.txt

И все файлы одним списком без разделение ня kde & win32libs: http://winkde.org/pub/kde/ports/win32/releases/stable/4.8.0/

// Qt4 и стандартные иконки

Бывает необходимость в вашем приложении отобразить ту или иную стандартную системную иконку, типа значка диска CD-ROM. Можно, конечно, создавать свой ресурсный файл и ложить иконки туда, но это будет выглядеть несуразно, особенно при смене различных тем оформления. Задаёмся резонным вопросом: а как бы использовать то, что уже есть в Qt и/или системе?

Вариант 1: стандартные ресурсы Qt4

Про это написано тут: http://www.qtcentre.org/wiki/index.php?title=Embedded_resources

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

QPixmap pixmap(":/trolltech/styles/commonstyle/images/up-128.png");
QIcon   icon(":/trolltech/styles/commonstyle/images/up-128.png");

Вариант 2: стандартные иконки при помощи QStyle

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

Собственно что нам нужно, это метод класса QStyle:

QIcon QStyle::standardIcon ( StandardPixmap standardIcon, const QStyleOption * option = 0, const QWidget * widget = 0 ) const

Иконки опеределяются перечислением StandardPixmap

Вариант 3: использование иконок темы оформления

Тут, скорее всего, всё будет очень сильно зависеть от платформы. Но в общем случае, нам нужен такой вызов:

QIcon icon(QIcon::fromTheme(QString::fromUtf8("icon-name")));

icon-name имя иконки, возможные значения, стандартные, для Linux можно узнать тут: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html

// На правах заметки: Статический анализ кода C++

Давно пользуюсь услугами cppcheck, но решил поглядеть что есть ещё (как оказалось, лучше, по сути, ничего и нету). Наткнулся на статью по теме на хабре: http://habrahabr.ru/post/75123

Тезисно:

  • Педантичные ключи для gcc (сам автор отсылает за подробностями: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html), особо хочется отметить неизвестный мне ключ -Weffc++, включает проверку на соответствие рекомендациям Скотта Майерса. Результат сборки моего последнего проекта поверг в уныние: будет ещё работы по вычистке.
  • cppcheck (в арчике есть в стандартных репах)
  • vera++ (есть в AUR)
  • rats (есть в AUR)
  • проверялки для чистого Си (как оказалось2) их значительно больше, нежели для C++)

Далее, Анализ утилит статического анализа C++ кода, автор рассматривает следующие анализаторы:

  • rats (выше писал)
  • cppcheck (аналогично)
  • Graudit (есть в AUR)

причём рассматривает проблемы, которые они не выявляют.

Список статических анализаторов можно поглядеть на страничке в википедии: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis, причём не только для C/C++

Для интереса можно почитать перевод статьи Джона Кармака о статическом анализе: http://habrahabr.ru/post/135234/3), где кратко излагается, какими инструментами ему довелось воспользоваться, и какие впечатления остались после них.

И на последок серия из четырёх заметок камрада Andrey20084) «Как уменьшить вероятность ошибки на этапе написания кода»:

    1. Избегайте функции memset, memcpy, ZeroMemory и им аналогичные
    2. Внимательно следите, работаете вы со знаковым или беззнаковым типом
    3. Избегайте большого количества вычислений в одной строке
    4. Выравнивайте в коде всё, что возможно
    5. Не размножайте строку более, чем один раз
    6. Выставляйте высокий уровень предупреждений у компилятора и используйте статические анализаторы
    1. Не используйте тернарную операцию '?:' в составных выражениях
    2. Не стесняйтесь использовать скобки
  • Заметка №3 - на примерах ошибок в Qt4
    1. Обрабатывайте переменные в той же последовательности, как они объявлены
    2. Табличные методы — это хорошо
    3. Разное интересное (про разные и интересные ошибки в Qt4)
  • Заметка №4 - на примерах ошибок в Firefox
3)
Оригинал статьи: altdevblogaday.com/2011/12/24/static-code-analysis/
4)
Один из разработчиков PVS-Studio, поэтому малость пропускаем его отсылы к этому продукту

// Многопоточность в C++

На правах заметки: цикл статей о многопоточности в C++.

В цикле рассматриваются создание обёртки над pthreads5), использование boost::thread, а так же использование идиомы RAII (Захват ресурса есть инициализация) в контексте потоков.

Вообще, блог Empty Crate крайне рекомендую к ознакомлению - интересные заметки по программированию на C++.

Так же в тему многопоточности concurency в C++0x (но всё это можно переложить, с небольшими оговорками и на boost::thread) серия статей в блоге Just Software Solution:

// BlogTNG и SQLite3

Как писал в прошлом сообщении в PHP 5.4.x нет SQLite2, есть поддержка только SQLite3. Пришлось немного напрячься и сделать поддержку оного в BlogTNG, дабы не впадать в уныние.

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

// Как узнать каким компилятором мы компилируемся?

Не всё делается одинаково во всех компиляторах, не на всех платформах, приходится временами городить хитрые конструкции из #if/#elif/#endif. Случайно наткнулся на шпаргалку, в которой описано, какие директивы препроцессора предопределяют конкретные компиляторы: http://sourceforge.net/p/predef/wiki/Compilers/

С того же ресурса:

А так же определение порядка байтов: http://sourceforge.net/p/predef/wiki/Endianness/

Другие ссылки на эту тематику:

// The Function Pointer Tutorials

Хорошее руководство: http://www.newty.de/fpt/index.html

PDF версия: http://www.newty.de/fpt/zip/e_fpt.pdf

Там же, прицепом: «Callback Implementations in C++»

// Удаление weak_ptr из std::list

Дано: контейнер примерно такого вида:

std::list< boost::weak_ptr<Item> > items;

Вместо boost::weak_ptr<> могу быть:

  • std::tr1::weak_ptr<>
  • std::weak_ptr<> для C++11

Задача: нужно удалить элемент по значению.

Казалось бы, просто сделай:

...
items.remove(value);
...

ан нет: для weak_ptr<> не определён оператор сравнения. Если потеоретизировать, можно предположить, почему так сделано: что бы гарантировать консистентность указателей при сравнении нужно их захватить (сделать value.lock()), т.е. создать два shared_ptr и уже их сравнивать, т.е. лишние накладные расходы.

Поэтому удаление можно делать так:

template <typename T>
bool operator == (const boost::weak_ptr<T>& a, const boost::weak_ptr<T>& b)
{
    return a.lock() == b.lock();
}

после такого std::list::remove(const T&) будет работать для всех типов. Можно и сузить до конкретного.

Либо использовать std::list::remove_if(Predicate), предикат объявить как:

struct EqPredicate
{
    const boost::weak_ptr<Item>& item;
 
    EqPredicate(const boost::weak_ptr<Item>& item)
        : item(item)
    {
    }
 
    bool operator () (const boost::weak_ptr<Item>& p) const
    {
         return p.lock() == item.lock();
    }
};

и использовать так:

std::list< boost::weak_ptr<Item> > items;
...
items.remove_if(EqPredicate(value));

Информация взята отсюда: http://stackoverflow.com/questions/1390340/how-can-i-use-stdremove-on-a-container-with-stdtr1weak-ptr

Вышесказанное верно для boost::weak_ptr, std::tr1::weak_ptr, std::weak_ptr

// RESTEasy, JAXB, XML, JSON и другие

Столкнулся с непонятной проблемой в JBoss и RESTEasy:
Когда сервис принимает или отдаёт данные в JSON формате Jackson (сериализатор/десериализатор JSON) игнорирует JAXB аннотации @XmlElement(name = «bla_bla») вместо указанного имя поля всегда используется имя поля в классе, т.е. такое:

@XmlRootElement
class SimpleJson
{
  @XmlElement(name = "my_name")
  public String megaName;
}

сериализуется в это:

{
  "megaName" : ""
}

а не, как ожидается, в это:

{
  "my_name" : ""
}

А так же игнорируется @XmlJavaTypeAdapter, что есть пичалька.

Тут по ходу сочинения заметки пришло в голову, что Джексон не настроен использовать JaxbAnnotationIntrospector - повод рассмотреть.

Пока же использую work-around, в виде дополнительного навешивания Jackson-аннотаций вроде:

@XmlRootElement
class SimpleJson
{
  @XmlElement(name = "my_name")
  @XmlJavaTypeAdapter(Iso8601DateAdapter.class)
  @JsonProperty(value = "my_name")
  @JsonSerialize(using = JsonIso8601DateSeializer.class)
  @JsonDeserialize(using = JsonIso8601DateDeserializer.class)
  public Date megaName;
}

Подкатом, бонусом, классы Iso8601DateAdapter, JsonIso8601DateSeializer, JsonIso8601DateDeserializer.

// Quartz Scheduler

Потребовалось использовать в одном проекте данный планировщик (http://quartz-scheduler.org/). Запускается на ура в виде бина в JBoss… Но вот тут с размаху врезался лбом в косяк:

  1. планировщик регистрируется в JNDI
  2. я успешно получаю инстанс планировщика
  3. добавляю свои задачу со своим воркером

И кряк вам с хреном, а не профит:

ClassNotFoundException...

// hypot

hypot(x, y) создан, что бы не звать sqrt(x*x + y*y)

Подробности:

// Robust Design Techniques for C Programs - на заметку

http://freetype.sourceforge.net/david/reliable-c.html

UPD 2014-06-09: сменил ссылку, прошлая убилась

// Полезная ссылочка на документацию от IBM

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahg%2Frzahgicprog2.htm - iSeries Information Center, версия 5, выпуск 3

В разделе есть примеры кода, достаточно много про сокеты написано (в том числе и мультикаст и SSL).

// Boost, CMake, кросскомпиляция

  • Q: Boost.Asio - что нужно указать в cmake среди компонентов при поиске библиотеки boost?
    A: только библиотеку system:
    find_package(Boost REQUIRED COMPONENTS system)
  • Q: Boost.Thread и кроскомпиляция - что делать, если получаем ошибку вида: undefined reference to `boost::tss_cleanup_implemented()'?
    A: для начала чуток обратно: в случае Linux, в качестве компонента при поиске библиотеки нужно указывать thread, а в случае windows (и кроскомпиляции): thread_win32, т.е. необходимо писать что-то вроде такого кода:
    set(BOOST_COMPONENTS
        program_options
        system
    )
    # Boost thread library is different on Win/Linux
    if(WIN32)
      set(BOOST_COMPONENTS ${BOOST_COMPONENTS} thread_win32)
    else()
      set(BOOST_COMPONENTS ${BOOST_COMPONENTS} thread)
    endif()
     
    ...
     
    find_package(Boost COMPONENTS ${BOOST_COMPONENTS} REQUIRED)

    Подсказку увидел тут: http://lists.gnu.org/archive/html/mingw-cross-env-list/2010-11/msg00063.html. Так же следует добавить следующее (при статической линковке):

    add_definitions(-DBOOST_THREAD_USE_LIB=1)

    . Далее, собственно, относительно самого вопроса, предлагают в случае появления такой ошибки при компиляции, поместить в любой свой исходник следующее:

    namespace boost {
     void tss_cleanup_implemented() { }
    }

    чистой воды хак :) Дополнительно написано тут: http://solarcore.blogspot.com/2010/10/boost-c-threads-mingw-mac-os-x.html