Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: учёт пользовательских Id типов данных
Форум на CrossPlatform.RU > Библиотеки > Другие библиотеки
Litkevich Yuriy
в Qt, а возможно и в других библиотеках, есть перечисления, описывающие тип (подтип) данных. Например:
QEvent — объект-событие, позволяет создавать наследников. В этом классе определено перечисление enum QEvent::Type. в котором есть значение QEvent::User. При создании наследника нужно определить собственный тип, следующим образом:
enum { Type = UserType + 1 };
int type() const
{
     return Type;
}
здесь единичка только для примера. Когда создаются несколько пользовательских типов, то у каждого должно быть своё смещение.

Вопрос: какие способы учёта идентификатор пользовательских типов вы используете/знаете?
На мой взгляд эта проблема стоит довольно остро в приложениях с развитым использованием подключаемых модулей (plugins)


П.С.
применительно к QEvent я знаю о существовании метода
int QEvent::registerEventType ( int hint = -1 )   [static]
Алексей1153
насколько понимаю, так этот диапазон определённых самим пользовательских типо - он ведь актуален только для одного-трёх приложений (если комплекс), а между чужими программами/комплексами конфликта быть не должно.

если всё очень глобально, то лучше GUID применить для идентификации )
Litkevich Yuriy
Цитата(Алексей1153 @ 23.8.2010, 10:11) *
то лучше GUID применить для идентификации )
не получится, это ограничение базового класса, он уже предоставляет константу UserType и виртуальную функцию type()

Цитата(Алексей1153 @ 23.8.2010, 10:11) *
он ведь актуален только для одного-трёх приложений
если бы, если строить приложения модульно, то модули можно повторно использовать.

Ещё один пример - QGraphicsItem (про его UserType на форуме уже всплывала тема.)
Алексей1153
Может быть, я просто суть проблемы не понял. А пример косяка можно ?
Litkevich Yuriy
Цитата(Алексей1153 @ 23.8.2010, 10:39) *
А пример косяка можно ?
есть два стандартных (со временем таковыми стали) модуля, которые определяют тип UserType + 1, и вот сошлись они в одной программе. Во время выполнения получим что-нибудь жуткое
Алексей1153
Ну, так то оно всё так. Но как два модуля могут войти в конфликт, если у них эти типы не запрашивать ? Это обязательно ?

Как вариант - если это исходный код, то выделить в namespace какой-то модуль
igor_bogomolov
Цитата(Litkevich Yuriy)
есть два стандартных (со временем таковыми стали) модуля, которые определяют тип UserType + 1, и вот сошлись они в одной программе. Во время выполнения получим что-нибудь жуткое
Тут видимо ничего не поделать. Придётся смириться и проектировать с учетом этой особенности.

Хотя, с другой стороны, знание смещений тебе не нужно. Главное чтобы они не пересекались. Можно сделать класс, который последовательно выдавал номера для этих типов. Минус здесь - это появление новых зависимостей.
kwisp
если модули наследники одного базового класса. то можно сделать регистрацию нового типа (как в QEvent) registerType()(в ней наращивать статическую переменную класса) и функцию которая возвращает текущий последний номер.
при создании наследника в конструкторе присваивать переменной type наследника последний номер + 1 и заново наращивать счетчик.
получается без лишних зависимостей
Litkevich Yuriy
Цитата(igor_bogomolov @ 23.8.2010, 12:05) *
Можно сделать класс, который последовательно выдавал номера для этих типов.
Цитата(kwisp @ 23.8.2010, 12:54) *
то можно сделать регистрацию нового типа (как в QEvent) registerType()(в ней наращивать статическую переменную класса) и функцию которая возвращает текущий последний номер.
вот вроде выход из положения, но на примере того же QEvent::registerType() вроде всё гладко.
А вот в случае, например, с QGraphicsItem уже не очень гладко, т.к. у него нет такой функции, значит нужно её "где-то" реализовать.
А где это "где-то" должно находится?
kwisp
Litkevich Yuriy,
хм. ну как вариант подмешать свойство с помощью наследования.
Litkevich Yuriy
в общем ещё думать и экспериментировать.
Iron Bug
я тоже подумала о регистрации и выделении динамического id'а. например, в кернеле так решена проблема идентификаторов устройств. устройств может быть сколько угодно и каких угодно. драйвер при старте получает своё смещение и запрашивает нужное количество id'ов. ядро ему выделяет этот диапазон, а у себя ведёт списко заюзанных id'ов.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.