Чисто заметка, без вдавания в детали.
Для начала нужно поставить 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 :)
Надеюсь мои ощущения, что космические программы стали более активными, не просто ощущения. Поздравляю всех причастных!
Некоторые компиляторы (если не все) поддерживают такую функциональность: через параметр командной строки можно указать файл или файлы, которые будут подключаться автоматически к каждому обрабатываемому файлу. У GCC это опция `-include ````.
В некоторых проектах используют эту особенность, как результат - явного включения файла нет, а парсер в 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 файла.
Что-то не нашёл официального русского перевода книги, только сделанный в частном порядке (читать сложновато):
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
Будет дополняться и оформляться.
На заметку:
http://www.somacon.com/p125.php там же удобный калькулятор для перевода констант между четырмя популярными системами счисления (BIN, OCT, HEX, DEC)
Сайт qt-project.org навёл меня на проект
http://sourceforge.net/projects/mingwbuilds/files/ где можно разжиться бинарными сборками MinGW для MacOSX, Linux, Windows.
Удобдно для использования совместно с Qt Creator на Windows.
Решение подсказывают
тут и
тут. Если коротко: нужен 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/
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
Переехал на новый хостинг, вроде всё основное запустил. Заодно обновился и обновил плагин
googleplusoneng.
Теперь проблем со скоростью (100Мбит) и доступностью (всё же сервер в серверной :)) должно быть поменьше.
Google Drive [речь про Windows] может работать только с прямым подключением к интернету или через прокси, настроенный в IE и без авторизации.
Что бы решить сабжевую проблему:
Пересказывая… Ставим cntlm прокси, идём в “C:
Program Files
Cntlm”, редактируем cntlm.ini, указываем логин и домен. При этом не спешим вводить свой пароль открытым текстом, вместо того вызываем cntml.exe следующим образом:
cntlm.exe -H
вводим пароль, и копируем один из вариантов хеша в конфиг.
После всего этого делаем команду:
net start cntml
и сервис у нас запущен.
В настройках прокси IE указываем:
- хост: localhost
- порт: 3128
Пробуем зайти на куда нибудь и радуемся жизни. Если на этот момент Google Drive уже поставлен и запущен, он сразу сможет подрубиться и начать свою работу.
UPD: Под Linux нужно попробовать:
https://aur.archlinux.org/packages/insync/
Текщущая версия 2.4:
http://docs.opencv.org/trunk/opencv_cheatsheet.pdf
Она же на этом ресурсе:
opencv_cheatsheet.pdf
Столкнулся с ситуацией: после перехода к systemd и его logind внезапно отказались монтироваться
флешки средствами udisks и udisks2. При этом на соседнем компьютере всё нормально. Разница при этом
между ними только одна: на одном иксы запускаются через kdm, на другом - startx. Вот там, где
используется startx монтирование и не работает.
В ходе разбора наткнулся на эпичный тред, где поттеринг пытается убедить, что нужно апдейтить
startx:
https://bugzilla.redhat.com/show_bug.cgi?id=820675
Но оставим этого человека альтернативной ориентации и вернёмся к нашим баранам. А бараны такие:
заставить без костылей или минимум оных монтировать накопители средствами udisks/udisks2 на машине,
где используется startx.
Для начала выясняем, а в чём собственно соль проблемы. Выясняется, что когда мы запускаем иксы, они
захватывают отдельный терминал и переключают пользователя на него, тем самым мы как бы переключаемся
из сессии, созданной при логине в консоли, и она становится неактивной. Новой сессии для иксов при
этом не создаётся. В результате этого в выводе команды
loginctl show-session $XDG_SESSION_ID
видим такие строчки:
Active=no
При этом, изучая конфиги polkit, мы можем увидеть, что мы можем регулировать права доступа для
монтирования для активной сессии, неактивной и для остальных. Отсюда вытекает первый вариант
исправления ошибки (и первый костыльный): править конфиги polkit и разрешать доступы с неактивных
сессий для операций монтирования.
Проблема метода очевидна: ближайшее обновление и нам нужно мержить, или менять снова. Не гут.
Второй метод, запустить иксы на том же терминале, на котором мы залогинились. К примеру, мы зашли с
первой консоли, команда tty выдаёт следующее:
/dev/tty1
тогда, что бы запустить иксы на этой консоли нам нужно выполнить следующую команду:
startx – vt1
И видим, что в выводе loginctl Active стал yes. Viva!
В таком варианте есть свой плюс: если заблокировать экран, допустим, с помощью xscreensaver, то мы
не сможем переключиться на первую текстовую консоль и, нажав Ctrl-C, убить иксы и получить доступ к
залогиненому аккаунту. Здесь же кроется и минус: подвисшую сессию оперативно не убьёшь, особенно, если
она отказывается реагировать на Ctrl-Alt-BS. Плюс как-то не классически.
Как последний штрих, добавляем в ~/.bashrc следующее:
stx()
{
local vt=$(fgconsole)
startx -- vt$vt
}
alias startx='stx'
и продолжать пользоваться просто командой startx.
Здесь же кроется забавный баг: теперь, если случайно нажать startx в окне терминала в запущенных
иксах, поверх них запустится их вторая копия и переключиться между ними не получится ни при каких
обстоятельствах. Так что будьте осторожны и бдительны.
Как заключение: подобные изменения лишний раз подтверждают правило: работает - не трожь! Особенно
если это касается системообразующих функций, систем загрузки и пр.
Материалы которые помогли мне разобраться:
AsciiDoc - язык разметки и утилита для генерации, из этой самой разметки, документов самых разных форматов: Unix man pages, HTML, PDF, OpenOffice и т.п. (список поддерживаемых форматов можно расширить модулями). При этом текст разметки напоминает некоторые WiKi (типа той же DokuWiki) и остаётся читабельным даже без компиляции в какой либо выходной формат. Часто используется для приготовления документации к продуктам.
PlantUML - тоже язык разметки, и тоже текстовый, для генерации различных UML диаграмм.
Резонный вопрос: как бы их скрестить. Помогает модульность AsciiDoc, в частности фильтры. В скором времени находим уже готовое решение:
http://code.google.com/p/asciidoc-plantuml/
Устанавливается просто:
- скачиваем файл
plantuml.zip
- натравливаем на него команду:
asciidoc --filter install plantuml.zip
Либо, для пользователей ArchLinux, ипользуем пакет из AUR:
https://aur.archlinux.org/packages/asciidoc-plantuml
После чего, в тело документа можно вставлять такие блоки:
[plantuml]
------
User -> (Start)
User --> (Use the application) : Polish label-Zażółć gęślą jaźń
:Main Admin: ---> (Use the application) : This is<br/>nyet another<br/>nlabel
------
И оно заменится картинкой с диаграммой.
Под катом снимок экрана редактора
asciidoc-gui с предпросмотром диаграммы.
В 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
