Адресная арифметика

[Igors]

Добрый день

Есть такая структурка на суровом С

Код:

struct Model {
...
  int m_MaterialCount;
  Material ** m_Materials;
...
} 
typedef Material * MaterialPtr;

Возникла необходимость имея MaterialPtr + смещение получить другой как если бы они хранились непрерывным массивом (была бы одна звездочка вместо 2).

Ну а если в рамках "С с классами" это уж никак низзя - можно блеснуть std:: и.т.п. (если конечно оно здесь поможет)

Спасибо

[Igors]

Все-таки наблюдающийся "отток" людей имеет свои плюсы: по крайней мере нет глупых советов типа

сделай std::vector<Material> и будет тебе счастье

Правда умных советов тоже нет, ну я ничего не потерял

Выбрать подходящий контейнер обычно не так уж сложно "с чистого листа", но здесь уже написано немало кода. И даже беглое знакомство с ним показало: решение сделать Material "неперемещаемым" вполне оправдано/грамотно, менять это на вектор не только трудоемко, но просто плохо, не видно как/чем заткнуть полезущие из всех щелей проблемы.

Еще популярный совет

Вот видите, "кривая архитектура" не была продумана с самого начала! Если бы..

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

Однако вернемся к собсно теме. Хорошо или плохо, но новый ф-ционал обеспечить надо, как это сделать?

1) Изменить базовый контейнер так чтобы он поддерживал нужный ф-ционал. Тогда как? (простое std::vector явно не годится)

2) Оставить **, т.е. не пытаться сотворить чудо-контейнер (такого нет в природе), а нового ф-ционала добиться добавлением новых данных, а возможно и доп контейнеров. Лично я считаю что этот путь верный и вовсе не является "костылем". Опять-таки "как"?

Да, и поактивнее, товарищи, надо быть "в тонусе", а не сваливаться в блевотину сборок и андроидов

[Old]

Сам задаю вопрос, сам даю глупые советы и сам же их ловко отвергаю...
Зачем вам форум, вам нужен блог.

[Igors]

Все равно "дубль-пусто". Почему, ведь вариантов немало, ну хотя бы так

Код

C++ (Qt)
struct Material {
 ..
 Material * m_prev, * m_next;
 ..
};

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

[Old]

Ну что же, бывает и так, попастись на готовом часто выгодно, но не всегда удается. Здесь видимо нет.

Да, к сожалению в 21 веке эта задача не решаема. Будем ждать 22 век, возможно в c++120 что-то появится.

[ecspertiza]

Разве две звездочки не дают возможности доступа по индексу? Дальше вопрос со смещением, смещение делим на sizeof получаем индекс, только если внутри нет POD типов.

[__Heaven__]

сделай std::vector<Material> и будет тебе счастье

[__Heaven__]

Звучит просто
1. найти индекс материала в массиве
2. вычислить новый индекс
3. найти материал по новому индексу

[Igors]

Разве две звездочки не дают возможности доступа по индексу?
Дальше вопрос со смещением, смещение делим на sizeof получаем индекс, только если внутри нет POD типов.

Не дают Material * (MaterialPtr) - это адрес структуры, а в контейнере сидит указатель на нее (**). И кстати делить на sizeof можно всегда, хоть POD хоть не POD (указатель на VMT в sizeof входит).

Звучит просто
1. найти индекс материала в массиве
2. вычислить новый индекс
3. найти материал по новому индексу

"А можно пример?"

И чтобы С не смущало можно просто

Код

C++ (Qt)
struct Model {
...
  QList<Material> m_materials;
...
}; 

Все то же самое, я оставил ** чисто из уважения к старому коду

[__Heaven__]

Примерно так вижу

Код

C++ (Qt)
MaterialPtr Model::advancedMaterial(MaterialPtr base, int offset) {
    auto pos = std::find(m_Materials, m_Materials + m_MaterialCount, base);
    return pos + offset;
};
 

[Igors]

Примерно так вижу

Код

C++ (Qt)
MaterialPtr Model::advancedMaterial(MaterialPtr base, int offset) {
    auto pos = std::find(m_Materials, m_Materials + m_MaterialCount, base);
    return pos + offset;
};
 

Так а где ж взять Model? MaterialPtr подается в сотни мест которые о модели ничего не слыхали.

И чмошный find в этой задаче не катится (выжимается скорость)

[Old]

И чмошный find в этой задаче не катится (выжимается скорость)

Вы бы показали как мамкины настоящие выжимальщики выжимают скорость в таком варианте:

Код

C++ (Qt)
struct Model {
...
  int m_MaterialCount;
  Material ** m_Materials;
...
}
 

[__Heaven__]

Не, ну можно ещё нечмошным бинарным поиском воспользоваться

А вообще, что спрошено, то и предложено

[Igors]

Не, ну можно ещё нечмошным бинарным поиском воспользоваться

Все равно оверхед, да и сортировать материалы никто не разрешал

А вообще, что спрошено, то и предложено

Неправда, спрашивалось как по одному материалу найти другой (а вовсе не "как найти эл-т в контейнере")

[Igors]

Вообще-то мне больше интересен "философский аспект". Вот жил-был какой-то код, не будем смущать звездочками, то же самое в более привычном (для современников) виде

Код

C++ (Qt)
class Model {
..
 QList<Material> m_materials;
..  
}; 

Что тут "не так"? Да все так, Model владеет материалами, каждый материал размещен в куче и неперемещаем, поэтому указатель на него используется повсеместно. Все бычит.

И вот появляется новая фича, у которой материал может "мутировать". Отношения владения при этом никак не меняются, владеет по-прежнему модель.

И вот ЧТО? Я должен немедленно  "менять архитектуру своего приложения" (как говорит научный работник)? Сразу приходит на ум: а еще чего-то понадобится - так что, опять все менять? Что же это за архитектура что рассыпается на первом скачке?

А если не менять, то как обеспечить новую фичу?