В QtCore/qglobal.h есть определение QIncompatibleFlag, которое соседствует с QFlag.

Меня мучает вопрос: зачем?

Оно не документировано, и, судя по всему, документировано не будет т.к. фактически это лазейка в системе безопасности, которую обеспечивает QFlags.

Если я правильно понимаю QIncompatibleFlag позволяет использовать произвольный int в качестве флага в сумме флагов без применения cast'ов.

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

Это используется в приложениях? Но почему тогда не задокументировать как положено?

P.S. Всё что нагуливал по этому поводу --- одно недоумение без ответа.

Здравствуй, лор.

На днях при программировании сигнального процессора встретился с примерно следующей задачкой:

Программистам довольно часто требуются функции ffs и fls, которые ищут в двоичном представлении целого числа первый и последний биты соответственно, установленные в 1. Например ffs(1)=0, ffs(2)=1, ffs(3)=0, ffs(4)=2, ffs(5)=0 и т.д. fls(1)=0, fls(2)=1, fls(3)=1, fls(4)=2, fls(5)=2 и т.д.

Так вот, попался мне процессор самый обыкновенный. В нём есть команда, выполняющая для заданного числа fls. А мне потребовался ffs. И нет ротации последовательности бит. Помимо этой команды fls имеется так же полный комплект: целочисленная арифметика, логика, проверки, переходы, обращение к памяти. Регистров штук 10. Достаточно одним словом.

Я получил крайне элегантное решение проблемы, найдя в таких условиях алгоритм для вычисления fls со сложностью O(1). Решение это поистине банально и элементарно, но немного не тривиально.

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

Добрый день.

Прошу прощения, если тема уже поднималась... Искал, не нашел.

Я пишу миленький такой велосипед: фасет локали C++ с поддержкой перекодировки символов. При том перекодировка должна происходить с использованием libiconv.

Более того, предполагается реальным использование символьных наборов с символами не постоянной длинны (естественно, в качестве внешней кодировки). Как следствие должно использоваться смещение в строке (state_type aka mbstate_t).

При том фасет сей должен будет работать с несколькими строками одновременно (это уже заложено в системе и перестройка ее крайне не желательна).

Возможны следующие варианты:

(0) При каждом обращении к фасету создавать новый дескриптор преобразования libiconv. При этом мы вообще не нуждаемся в его хранении. Но при этом мы не сможем отслеживать смещения в внешнем представлении.

(1) Хранить дескриптор, непосредственно в фасете (однако, это может привести к нарушению смещений в строке во внешней кодировке, ибо при первом обращении будет преобразована одна строка, а при втором обращении будет начата работа с другой строкой, но сдвиг останется прежним).

(2) Хранить дескриптор в поле имеющегося типа mbstate_t. Однако, это уж совсем коряво, ибо тип этот зависит от реализации. И тогда единственный способ его использовать, это побитовая запись в него информации в обход системы контроля типов.

(3) Реализовать свой тип символов. Реализовать для него std::char_traits, в котором будет определяться подходящий state_type. Реализовать фасет на основе этого символа типов. Это пожалуй самый "правильный" вариант, но во первых это вызовет трудности при работе со строками встроенных типов, а во-вторых это слишком сложно для реализации.

В стандартах (C, C++) я не нашел никаких упоминаний о минимальных требованиях к mbstate_t. Т.е. это черный ящик. Вариант (2) можно было бы, скрепя сердцем, реализовать если бы хотя бы гарантировалось, что в любой системе sizeof(mbstate_t) >= sizeof(void*).

Вопрос собственно такой: может ли мне кто что-нибудь путное порекомендовать? Может я чего-то упустил... Заранее спасибо.

>>>