qt analog of motif constraint resources

[Dendy]

В принципе ето и правильно. Если в обьекте есть какой-то параметр, то подразумевается, что для етого же типа обьекта есть и методьІ использования етого параметра.

Если мьІ добавляем параметрьІ для уже существующего типа, то мьІ как будто бьІ создаём новьІй тип данньІх, не наследуясь от него. То-есть подразумеваем использование добавленньІх параметров.

Если же есть необходимость динамического добавления произвольньІх параметров, то, логически подумать, ето нельзя расценивать как параметр обьекта. Правильнее понимать под етим - елемент контейнера, где сам контейнер - параметр обьекта. Так как обработка будет осуществляться над контейнером, а не над параметром.

[programmer]

Мне кажется гораздо логичней было бы вставить в QObject или QWidget изначально просто указатель на который при надобности можно повесить структуру в памяти или в крайнем случае добавить QList с пропертями

Может это конечно сказывается С-шный подход (я на С++ почти не пишу) но думаю так было удобнее да и уверен не я первый сталкиваюсь с такими проблемами. Не надо было бы городить  производные классы.

[Alex03]

ИМХО базовые объекты не должны обладать излишней функциональностью, особенно если она нужна в 0.001% случаев.
qt и так до памяти прожорлива.

[bigirbis]

To programmer
Читай посты внимательнее. Зачем базовым объектам встроенный указатель на void? Это же можно решить аттачментом объекта класса, пронаследованного от QObject. При чем, таких объектов можно зацепить столько...  :shock:
ИМХО, тебе надо изменить подход к написанию кода...

[Dendy]

Мне кажется гораздо логичней было бы вставить в QObject или QWidget изначально просто указатель на который при надобности можно повесить структуру в памяти или в крайнем случае добавить QList с пропертями.

Такие рассуждения подходят для одноразовьІх решений, а так как обьектная система Qt претендует на универсальную, то в ней по понятньІм причинам нет ничего лишнего.

В данном случае тебе нужно прикрепить свои данньІе и первое, чтобьІ тьІ сделал на месте Троллей - прицепил бьІ пустой указатель - на всяк случай, вдруг хто захочет - юзайте.

Теперь посмотри на ситуацию, если бьІ вдруг так в Qt и бьІло. ТьІ пользуешься сторонними уже созданньІми обьектами и пьІтаешься привесить к ним свои данньІе через предоставляемьІй указатель. НО! Часть библиотеки, которой тьІ пользуешься уже прикрепила туда какие-то свои данньІе. Что делать? А как на счёт автоматического удаления, кто вьІзовет деструктор етих данньІх? Может добавить вместо указатея список указателей или некий хеш юзерских параметров, хранимьІх в QVariant? Но всё равно ето не решает проблему с автоматическим удалением и конфликтом параметров (по ключам), навешенньІх на один обьект от разньІх компонент. Навесить контейнер QList<QVariant>? И как в нём найти именно свои данньІе?

Именно поетому система параметром создана универсально, без конфликтов - путём С++ наследования от обьектов. Поетому ничего лишнего (одноразового) в QObject нет.

Если хочешь прицепить свои данньІе - можешь воспользоваться собственньІм хешем с поиском по указателю на обьект:

Код:

QHash<QObject*,MyCustomProperties>

Процесс поиска можно ускорить механизмами Qt - отсеять ненужньІе обьектьІ с помощью qobject_cast.

[Dendy]

Qt 4.2 Released!

Тролли видать перечитали ентот форум и решили помочь тебе в проблеме

И так, теперь в QObject встроена такая вещь как Dynamic Properties:

In addition to properties defined using Q_PROPERTY in a class it is possible to dynamically add and remove properties to any QObject at run-time.

If setProperty is called with a property not statically defined using Q_PROPERTY it is automatically added as dynamic property and its value is stored in the object. The value can be queried using the property() method, just like with static properties.

Собсна, конфликт имён разрешён с помощью позволения установки своих параметров с именами, несовпадающими с уже предопределённьІми для данного типа. Дёшево и сердито.

[programmer]

блин

я уже все сделал без этого с дочерними классами

не могли добавить в 4.1.4

и все таки предложенный мной подход на 5 постов выше был правильный раз так и сделали

[bigirbis]

и все таки предложенный мной подход на 5 постов выше был правильный раз так и сделали

Так скажем - шаг к WEB (XML)

[programmer]

Дело в том что я писал кастомный контейнер и мне как раз надо было дампить в XML

[bigirbis]

В этом случае есть 2 варианта:
1 - Держать XML(DOM) дерево
2 - Держать QStandartItemModel - если надо держать в дереве QVariant