Предлагается разработать безопасную альтернативу встроенного макроса __COUNTER__. Первое вхождение макроса заменяется на 0, второе на 1, и так далее. Значение __COUNTER__ подставляется на этапе препроцессирования, следовательно его можно использовать в контексте constant expression.

К сожалению, макрос __COUNTER__ опасно использовать в заголовочных файлах — при другом порядке включения заголовочных файлов подставленные значения счетчика поменяются. Это может привести к ситуации, когда например в foo.cpp значение константы AWESOME равно 42, в то время как в bar.cpp AWESOME≡33. Это нарушение принципа one definition rule, что есть страшный криминал во вселенной C++.

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

По мотивам этого вопроса на Stack Overflow.

Почти все продвинутые зеркальные камеры, а также некоторые правильные мыльницы, позволяют управлять собой с компьютера. Программное управление камерой дает интересные возможности, например: съемка time lapse video, сопряжение камеры с микроскопом, эксперименты в области компьютерного зрения. Для управления камерой вендоры предоставляют свои проприетарные SDK, которые обычно работают исключительно под Windows и поддерживают камеры только в рамках определенной линейки (например у Canon есть аж 4 несовместимых между собой SDK). Какое счастье, что есть достойная открытая альтернатива — проект gphoto.

Прямо сейчас gphoto поддерживает 1598 моделей камер и список постоянно растет. Проект собирается под все UNIX-like ОС, включая Linux и Mac OS X. Съемкой можно управлять как при помощи command line утилиты, так и из своей собственной программы, используя библиотеку libgphoto. Доступны биндинги для разных языковых платформ, включая node.js.

В современных ОС присутствуют встроенные средства для работы с цифровыми камерами — как правило под «работой» подразумевается только выгрузка фото из камеры. Эти встроенные механизмы препятствуют работе gphoto, так как захватывают USB устройство в эксклюзивном режиме. Особенно интересно дела в этом плане обстоят в Mac OS X — ОС не предоставляет никаких штатных возможностей для отключения, но при этом система поддержки цифровых камер легко поддается реверс инжинирингу.

Apple привносит в мир много нового. Удачные нововведения приживаются, а неудачные понемногу отмирают. Кстати неудачных решений оказывается не так уж и мало и я считаю это абсолютно нормальным. В конце концов мы уважаем Apple именно за готовность идти на риск и экспериментировать:)

Все это в полной мере относится и к средствам разработки. В прошлой заметке я писал о нестандартном алгоритме поиске заголовочных файлов в XCode. Сегодня я хочу подробнее остановиться на так называемых SDK — в XCode этим термином называют комплект библиотек и заголовочных файлов под определенную версию iOS или Mac OS. Зачем нужны SDK в понимании xCode?

Семейство языков Си/Objective C/C++ нуждается в препроцессоре. Препроцессор пропускает компилируемый исходник через себя, прежде чем отдать текст на вход компилятору. Пожалуй самая важная часть работы препроцессора заключается в подстановке на место директив #include<имя-файла> содержимого указанного файла. Обычно указывают относительный путь (ex: stdio.h, sys/stat.h). Возникает закономерный вопрос — как препроцессор находит заголовочные файлы?

Классический ответ такой: препроцессор последовательно перебирает пути в INCLUDE_PATH начиная с первого. Относительный путь из директивы include разрешается относительно (sic) папки из INCLUDE_PATH. Если файл не найден, переходим к следующему элементу INCLUDE_PATH. Если INCLUDE_PATH исчерпан, компилятор сообщает об ошибке.

Но Apple как всегда вносит свои коррективы. При сборке в XCode дополнительно используются т.н. header map. Это индекс всех заголовочных файлов в проекте. Если XCode «знает» про foobar.h, то данный файл будет доступен просто по имени (#include<foobar.h>), вне зависимости от фактического размещения на файловой системе.

Это прекрасное решение — до тех пор, пока оно работает как задумано. К сожалению, механизм header map плохо документирован, что не способствует быстрому разрешению проблем. Постараюсь восполнить этот пробел.

До появления gccxml, был только один способ извлечь мета-информацию из Си/С++ кода. Для начала, необходимо было написать парсер, способный справиться с грамматикой языка С++. Это не та задача, которую вы обычно решаете дома за выходные.

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

Для разбора XML данных, полученных от gccxml, пригодится библиотека pygccxml. Это не просто ридер формата gccxml — библиотека предоставляет интерфейсы для изучения собранных метаданных; в частности есть готовые функции, отвечающие на вопросы вроде «совместимы ли типы T₁ и T₂?» или «наследует ли класс C₁ от C₂?». Библиотека написана на языке Python.

Хочу поделиться своим опытом адаптации fakeroot для использования на маке в связке с XCode. Fakeroot запускает программы в особом окружении, которое эмулирует сессию супер-пользователя. Права root могут потребоваться при сборке инсталлятора с помощью PackageMaker.