Расширение данных

[Igors]

А это называется "контрактом" между тем, кто спрашивает (он то знает, что ему надо) и тем, кого спрашивают. Обе стороны должны понимать, что это такое:

Так и предлагается обсудить условия этого "контракта".

const QByteArray MATERIAL_ID2 = "Material2";

(например)

Создаваемый юзером нод "материал" конечно имеет имя, но оно не уникально. Ну и по-прежнему "не въехали" - какое же const если их число переменное? 

Ладно, пожуем. Итак теперь "материалов" может быть не один а много. В любом случае владелец (объект) уже не может запросить просто "параметр материала", он должен указать (конкретизировать) какого именно. Каким образом? (предмет обсуждения). И второе: существующий сынтаксыс не пресекает старого обращения (теперь уже ошибочного). На больших объемах кода это актуально, тоже обсуждаем

[Racheengel]

- Старый код придется переписать, т.к. он стал неоднозначным. Понимаю, что кода много, но иначе практически никак.
- Убрать все численные константы, т.к. все стало динамическим - в них больше нет смысла.
- Заменить их на строковые ID (QByteArray) - а тут уже полная свобода, материалы и параметры могут называться как душе угодно. Главное, чтобы соблюдался контракт между двумя сторонами (GetParameter("MaterialX/color") - должен быть распознан получателем как "цвет материала X, если такой имеется)

[Igors]

- Старый код придется переписать, т.к. он стал неоднозначным. Понимаю, что кода много, но иначе практически никак.

Вопрос "переписывать или нет" вообще не стоит. Нужно чтобы переписанное хорошо "легло" и потом не пришлось месяцами ловить новые баги

- Убрать все численные константы, т.к. все стало динамическим - в них больше нет смысла.
- Заменить их на строковые ID (QByteArray)

"Все" не убрать, материал - лишь один из многих нодов дерева. И откуда упорное стремление к строкам? Здесь не вижу ни одной выгоды от них

а тут уже полная свобода, материалы и параметры могут называться как душе угодно. Главное, чтобы соблюдался контракт между двумя сторонами (GetParameter("MaterialX/color") - должен быть распознан получателем как "цвет материала X, если такой имеется)

Уже говорили что имена есть но не уникальны. И не раз говорили типа "откуда возьмется "MaterialX", т.е. кто и где будет хранить этот (в общем случае) ключ. Топчемся на месте

[Bepec]

to Racheengel:
Это же Igors. Ему ответы уже всевозможные дали, но он будет зудеть до последнего, просто выводя из себя людей Темы поднимает неплохие, но вот окончательное решение у него одно - "всё уже есть, всё уже сказали, скажите чё-нить новое, чтоб решило проблему сразу".

[Racheengel]

И откуда упорное стремление к строкам? Здесь не вижу ни одной выгоды от них

Однозначность ключей, убирается ограничение на численные константы. Лучше юзать строчку "MaterialX", чем const MATERIAL_X_ID = 12345; - это "12345" еще где-то надо определить, причем следить, чтоб никто больше нигде не переопределил его...

И не раз говорили типа "откуда возьмется "MaterialX", т.е. кто и где будет хранить этот (в общем случае) ключ. Топчемся на месте

Тут вообще не понял проблемы. "Хранить" значение будет тот, кто предоставляет материалы. А зачем хранить ключи?

[Igors]

Тут вообще не понял проблемы. "Хранить" значение будет тот, кто предоставляет материалы. А зачем хранить ключи?

По указанию юзера создается новый нод "материал", он добавляется в дерево параметров объекта. Потом возможно еще нод "материал", и еще, а может и наоборот какой-то нод удалят. Сейчас объект просто обращается к ноду по константе, но c переменным числом таких нодов это уже не катит. Псевдокод

Код

C++ (Qt)
double value = GetParamValue(DIFFUSE_ID, currentTime);  // было
 
double value = GetMaterialValue(???, ???, currentTime);  // надо
 

Предложите реализацию GetMaterialValue. Разумеется объект знает к какому конкретно ноду "материал" он сейчас обращается, напр его индекс. Но нужна-то диффуза которая один из чайлд нодов данного материала,  закопана там глубоко

[Racheengel]

Ну, если совсем грубо:

QMap<QByteArray, QVariant> MaterialParams;
QMap<QByteArray, MaterialParams> Materials;
Materials m_objectMaterials;

QVariant GetMaterialValue(QByteArray materialId, QByteArray paramId)
{
return objectMaterials[materialId][paramId];
}

[Igors]

Ну, если совсем грубо:

QMap<QByteArray, QVariant> MaterialParams;
QMap<QByteArray, MaterialParams> Materials;
Materials m_objectMaterials;

QVariant GetMaterialValue(QByteArray materialId, QByteArray paramId)
{
return objectMaterials[materialId][paramId];
}

А чего Вы это замазываете суть (Q)вариантом? Создаваемые материалы должны помещаться в имеющееся дерево, этого никто не отменял.

[off]Эти подачи и возвраты по значению напоминают мне опустившегося человека - не бреется, ходит в рваных вонючих носках, бухает, жрет дуст...[/off]

[Авварон]

[off]... не бреется, ходит в рваных вонючих носках, бухает, жрет boost...[/off]

[Bepec]

каноничное завершение темы Igors

[kai666_73]

[off]Эти подачи и возвраты по значению напоминают мне опустившегося человека - не бреется, ходит в рваных вонючих носках, бухает, жрет дуст...[/off]

Типичный, конченный программер 

[Igors]

Ладно, вернемся к единственному (пока) кандидату

Код

C++ (Qt)
double CObject::GetMaterialValue( uint materialIndex, uint  paramIndex, double currentTime )
{
  Q_ASSERT(materialIndex < m_MaterialMaps.size());
  int ID = m_MaterialMaps[materialIndex].value(paramIndex); // получаем реальное уникальное ID
  Q_ASSRERT(ID);
  return GetParamValue(id, currentTime);
}

При создании/удалении материалов парить m_MaterialMaps их владельцев. Критикуем, пинаем

Ничего "плохого" здесь не вижу, да и реализовать это реально. Но вот с "идейной" точки зрения мне как-то не нравится. Ведь только что объект был "совершенно свободен", все делалось механизмом дерева параметров. Добавлять новые параметры и удалять старые - не вопрос, и это не требует никаких изменений в данных. Нужен параметр для расчетов/использования - дернул его по ключу - и все. А теперь мы начинаем хранить ID ключей - ну как минимум надо обеспечивать их (де)сериализацию, т.е. появились данные (члены класса объект). Хмм...

[Bepec]

А вы в любой своей реализации храните свои ключи параметров.
Просто в первом случае они были константами, теперь стали переменными.

PS нашли корову в коровьем стаде, красота