учёт пользовательских Id типов данных Опции

[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]

то лучше GUID применить для идентификации )

не получится, это ограничение базового класса, он уже предоставляет константу UserType и виртуальную функцию type()

он ведь актуален только для одного-трёх приложений

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

Ещё один пример - QGraphicsItem (про его UserType на форуме уже всплывала тема.)

[Алексей1153]

Может быть, я просто суть проблемы не понял. А пример косяка можно ?

[Litkevich Yuriy]

А пример косяка можно ?

есть два стандартных (со временем таковыми стали) модуля, которые определяют тип UserType + 1, и вот сошлись они в одной программе. Во время выполнения получим что-нибудь жуткое

[Алексей1153]

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

Как вариант - если это исходный код, то выделить в namespace какой-то модуль

Сообщение отредактировал Алексей1153 - 23.8.2010, 7:46

[igor_bogomolov]

есть два стандартных (со временем таковыми стали) модуля, которые определяют тип UserType + 1, и вот сошлись они в одной программе. Во время выполнения получим что-нибудь жуткое

Тут видимо ничего не поделать. Придётся смириться и проектировать с учетом этой особенности.

Хотя, с другой стороны, знание смещений тебе не нужно. Главное чтобы они не пересекались. Можно сделать класс, который последовательно выдавал номера для этих типов. Минус здесь - это появление новых зависимостей.

[kwisp]

если модули наследники одного базового класса. то можно сделать регистрацию нового типа (как в QEvent) registerType()(в ней наращивать статическую переменную класса) и функцию которая возвращает текущий последний номер.
при создании наследника в конструкторе присваивать переменной type наследника последний номер + 1 и заново наращивать счетчик.
получается без лишних зависимостей

[Litkevich Yuriy]

Можно сделать класс, который последовательно выдавал номера для этих типов.

то можно сделать регистрацию нового типа (как в QEvent) registerType()(в ней наращивать статическую переменную класса) и функцию которая возвращает текущий последний номер.

вот вроде выход из положения, но на примере того же QEvent::registerType() вроде всё гладко.
А вот в случае, например, с QGraphicsItem уже не очень гладко, т.к. у него нет такой функции, значит нужно её "где-то" реализовать.
А где это "где-то" должно находится?

[kwisp]

Litkevich Yuriy,
хм. ну как вариант подмешать свойство с помощью наследования.