Член указатель

@Igor3D · Регистрация: 01.10.2012

Студворк — интернет-сервис помощи студентам

Добрый день

Очень простая конструкция

C++
1
2
3
4
5
struct SomeObject {
...
 SomeData * m_data;
...
};

Как минимум возникают заботы с сохранностью/валидностью m_data, но не только
Как лучше? Слышал такое

1) "Лучше иметь m_data членом, а не указателем". Это владение, а оно не всегда нужно/допустимо. В большинстве случаев SomeObject просто использует SomeData для чтения/записи, но SomeData остается вполне самостоятельным объектом что может существовать и без SomeObject

2) "Необходимо использовать вумный указатель! Вообще "голые" указатели (как в примере выше) - это зло, их быть вообще не должно!"

А Вы что предложите?

Спасибо

@Igor3D · 15.07.2024, 21:52 **[ТС]**

Сообщение от zayats80888

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

Вернемся к стартовому посту. Вот удаляется SomeData и указатель m_data становится невалидным. Да, это решается как стандартными средствами std::, так и слот/сигналом. Да, это было указано/предложено в первых же ответах.

Но вопрос не только (и не столько) в этом. Ожидается что undo удаления восстановит указатель на SomeData. А вот для этого никаких решений предложено не было. Если я что-то упустил - плиз "ткните носиком", а иначе не надо "говорить неправду" (это мягко

)

@zayats80888 · 15.07.2024, 22:14

Сообщение от Igor3D

Вернемся к стартовому посту.

Сообщение от Igor3D

Но вопрос не только (и не столько) в этом.

Ну в стартовом посте так и написано:

Сообщение от Igor3D

но не только

Я вам предложил:

Сообщение от zayats80888

Ну добавьте еще указатель на функцию форматирования диска

.
Это относится к "не только".
Что не устраивает?

Сообщение от Igor3D

А вот для этого никаких решений предложено не было. Если я что-то упустил - плиз "ткните носиком"

Тыц:

Сообщение от Shamil1

Событие "меня удаляют", на которое можно подписаться?

Сообщение от zayats80888

Ну а если вы не намерены исправлять дизайн, то, как уже было упомянуто в этой теме, вам нужно для slave объектов организовать подписку на событие удаление master объекта из сцены, в том или ином виде (зависит от того, как у вас там вообще взаимодействие между объектами организованно). А для реализации undo/redo в обработчике такого события сериализовать команду "расцепления" каждого slave с master (идентификацию объектов при сериализации/десериализации удобно делать через глобальный id, а не через указатель, если вы не управляете менеджером памяти).

И еще несколько постов от Алексея.

@Igor3D · 16.07.2024, 03:08 **[ТС]**

Сообщение от zayats80888

вам нужно для slave объектов организовать подписку на событие удаление master объекта из сцены

Это решает обнуление указателя ставшего невалидным, но никак не помогает с его восстановлением после undo. Псевдокод удаления объекта из сцены

C++
1
2
3
4
5
void RemoveFromScene( SomeData * data )
{
 Write2Undo(data, ...);
 delete data;
}

В теле Write2Undo я должен записать id объекта(ов) которые ссылаются на SomeData, иначе undo не сможет восстановить указатель. Но (здесь) неизвестны ссылающиеся на экземпляр SomeData. Да, сигнал удаления они получат и свой указатель на SomeData обнулят, но передать себя в Write2Undo не могут.

Не по теме:

Да, и про форматирование диска так и не понял. Наверно Вы острите, но в чем прикол не знаю

@zayats80888 · 16.07.2024, 19:58

Сообщение от Igor3D

Да, сигнал удаления они получат и свой указатель на SomeData обнулят, но передать себя в Write2Undo не могут.

Но это же не буквально они должны делать, это ответственность редактора. Псевдокод с использованием семантики сигналов qt:

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
void Editor::enslave(Light *master, Light *slave) {
    auto * urm = UndoRedoManager::instance();
    auto *action = urm->createAction(...);
    Light *oldMaster = slave->getMaster();
    // redo
    action->addDoCommand([this, slave, master, oldMaster](){
        if (oldMaster) {
            // cleanup connections
        }
        slave->setMaster(master)
        if (master) {
            connect(master, &Object::leavingSceneTree, slave, [this, slave](){
                this->enslave(nullptr, slave);
           });
        }
    });
    // undo
    action->addUndoCommand([this, slave, master, oldMaster](){
        if (master) {
            // cleanup connections
        }    
        slave->setMaster(oldMaster)
        if (oldMaster) {
            // restore connections
        }
    });
    action->redo();
    urm->submitLastAction();
}
 
void Editor::removeObjectFromeSceneTree(Object *object) {
    auto * urm = UndoRedoManager::instance();
    auto *action = urm->createAction(..., MERGE_MODE); // все команды, добавленные до submitAction, будут объединяться с этой
    // тут нет сериализации, передаем объект во владение команды, просто и эффективно
    action->bindObject(object);
    // redo
    action->addDoCommand([this, object](){
        emit object->leavingSceneTree();
        this->removeObjectImpl(object);
        // block slots/signals
       });
    });
    // undo
    action->addUndoCommand([this, object](){
        this->addObject(object);
        // unblock slots/signals
    );
    action->redo();
    urm->submitAction(action);
}

Сообщение от Igor3D

Да, и про форматирование диска так и не понял. Наверно Вы острите, но в чем прикол не знаю

Я абсолютно серьезен. А вот созданная вами тема - это какой-то прикол. Ознакомьтесь: https://www.cyberforum.ru/announcement.php?a=3 и https://www.cyberforum.ru/abou... ment8.html
Этой теме самое место в разделе "обо всем" (и ниочем).

@Igor3D · 18.07.2024, 00:10 **[ТС]**

Немного повторюсь чтобы можно было читать тему отсюда. Некто SomeObject ссылается на др объект SomeData. Я предлагаю самое простое решение: пусть не только SomeObject "знает" SomeData, но и наоборот, SomeData знает всех SomeObject что ссылаются на него. Тогда легко отрабатываются все случаи когда "надо знать кто ссылается на данный SomeData"

C++
1
2
3
4
5
6
7
8
9
10
11
struct SomeObject {
...
 SomeData * m_data;
...
};
 
struct SomeData {
...
 std::vector<SomeObject *> m_clients;
...
};

Понятно надо добавить в классы по паре методов типа Add/Remove, для простоты опускаем.

zayats80888 со мной не согласен и считает добавление/хранение m_clients плохим и неграмотным. И утверждает что вместо этого правильно использовать слот/сигнал, приводя псевдокод (хорошо написаный)

Сообщение от zayats80888

Но это же не буквально они должны делать, это ответственность редактора. Псевдокод с использованием семантики сигналов qt:

Да, нужного ф-ционала можно добиться с помощью слот/сигнал, но это коряво, натужно, "через то место" и.т.п. Почему

1) Плохо с общностью. Всякий раз когда надо знать "ссылающихся" приходится прыгать в слот где они известны. Вот напр юзер хочет знать какие SomeObject используют данный SomeData (покажите всех slaves данного master'а) . И опять приходится заводить/коннектить сигнал. Может лучше сделать так

C++
1
2
3
4
void SomeObject::SlotAddThis( std::vector<SomeObject * vec )
{
 vec->push_back(this);
}

Т.е. получать "на лету" тот самый вектор m_clients что мы (гордо) отказались хранить.

2) Не вижу как "расширять". Мой вариант расширяется легко, если надо - покажу, сейчас не хочу перегружать пост. А со слот/сигнал - не вижу

@zayats80888 · 18.07.2024, 21:39

Сообщение от Igor3D

Некто SomeObject ссылается на др объект SomeData. Я предлагаю самое простое решение

Ну ссылается и ладно, решениие какой проблемы вы предлагаете? Валидность указателя? Вы сами же решение в стартовом посте написали. Проблема undo/redo (которая не была заявляна в стартовом посте) оказалось вообще не проблема и решается уже имеющимися средствами. Вы же предлагаете типичную реализацию паттерна "наблюдатель", причем не в обобщённом виде, а "зашитую" в и "прибитую гвоздями" к конкретным типам(хотя и не понятно к каким). При этом вы не озвучили ни одной предпосылки для его реализации (это вам предложили "подписаться на событие", для чего этот паттерн подходит).

Сообщение от Igor3D

zayats80888 со мной не согласен и считает добавление/хранение m_clients плохим и неграмотным. И утверждает что вместо этого правильно использовать слот/сигнал

Не надо передергивать, все мои оценки касаются вполне конкретной ситуации с лайтами, где, как мы выяснили, хранение указателя само по себе является архитектурной ошибкой, которую вы не хотите исправлять. В этом плане любое решение будет лишь усугублять ситуацию, я предложил выкрутиться с наименьшим ущербом. Вы опять уходите в какие-то непонятные абстракции, у абстрактной проблемы не может быть "лучшего" решения. Например, SomeData это char - куда вы там собрались клиентов добавлять? Или это текстура - вы будуте добавлять отдельные списки для всех, кто ей пользуется, спрайты, материалы, фреймбуферы и т.д.? Обсуждать сферических коней в вакууме - пустая трата времени и флуд по-сути.

Сообщение от Igor3D

Вот напр юзер хочет знать какие SomeObject используют данный SomeData (покажите всех slaves данного master'а)

Нет не хочет, покажите, где вы обозначили это требование в этой теме.
А если юзер захочет форматировать диск(вы помните, что нужно сделать)?

Ссылки, что я вам дал, вы видимо поленились прочитать. Тогда повторюсь, для продуктивного обсуждения вы должны указать конечную цель и максимально подробный список сопутствующих хотелок. Вы же тут разводите типичную проблему XY. И ладно бы вы были зеленым новичком, но нет, вы не новичок и не глупы, поэтому я справедливо делаю вывод, что вы намеренно троллите пользователей форума.
Если не хотите нормально сформулировать вопрос, то это сделаю я на основе всего вами написанного в этой теме(на самом деле для себя я это давно сделал, и все мои посты нужно рассматривать только в этом контекте):
цель - нужно в условном графическом редакторе реализовать возможность одновременного редактирования свойств нескольких объектов, хотелки - нужно сохранить поддержку undo/redo; нужно сохранять группу редактирования не только на время редактирования и иметь возможность исключать/добавлять новые объекты в группу(в том числе и опосредованно через уничтожение объекта); тип объектов не имеет значения, важно только наличие общих свойств (это моя хотелка). Лучшее, на мой субъективный взгляд, решение я уже озвучивал:

Сообщение от zayats80888

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

Т.е. нужно выкинуть указатель на master и вообще по возможности не трогать объекты, создать в редакторе класс менеджер групп, класс группа, хранящий ссылки на объекты(и отслеживающий их валидность тем или иным способом) и использовать уже имеющиеся в распоряжении мезанизмы, а не внедрять новые со схожими функциями(в контексте qt это сигналы/слоты и Q_PROPERTY, например, хотя при желании можете и своего упомянутого "наблюдателя" воткнуть).

@Igor3D · 19.07.2024, 23:48 **[ТС]**

Сообщение от zayats80888

для продуктивного обсуждения вы должны указать конечную цель и максимально подробный список сопутствующих хотелок.

Все хорошо в меру, в своем стремлении к четкости/ясности Вы явно перегибаете палку. Как я говорил, случаев когда "один объект ссылается на другой" я насчитал больше 20, дальше просто устал считать. Перечислять/озвучивать их все займет много места но совершенно бесполезно. Ну зачем Вам обильные подробности чужого проекта? И "проблема XY" здесь неактуальна, иксов слишком много, даже если решить один из них - это ничего не даст.

Не по теме:

Кстати, отличная ссылка (проблема XY), раньше не видел.

С хотелками тоже не все так просто. Да, кое-что очевидно: кроме просто валидности, возникают ситуации когда надо "знать всех кто ссылается на данный объект" (SomeData стартового поста). Таких ситуаций не так уж много, хорошо помню с undo, часто нужно просто "предъявить ссылающихся" (напр выбрать эти объекты в UI), но "огласить весь список" - ну не хочу я пыль глотать лазая по коду день за днем.

А вот дальше с хотелками - неясно. Вам нравится собсно "член-указатель" стартового поста? Мне нет, ну как-то выглядит он хреновенько. Не ошибка, но и гордиться нечем. Чуть лучше BaseClass (вместо SomeObject и SomeData), но тоже не блеск (god-class и все такое). Было бы таких пара-тройка - ну и ладно. Но если их уже десятки - значит обобщения/расширения актуальны. Для каждого указателя надо проводить/обеспечивать undo, сериализацию и др. При этом хотя зависимости самые разные и используются в самых разных классах - нет никакой "связи" ни с каким из этих классов. Членство (именно) указателей совсем необязательно, для ф-ционала нужно этот указатель получить - и все. Др словами это может быть чем-то другим, напр умным указателем, id, просто ф-цией и.т.п.

И мы приходим к классической задаче

Сделайте так чтобы было красиво

@Shamil1 · 20.07.2024, 02:06

Сообщение от Igor3D

И мы приходим к классической задаче

Нужно исходить из физического смысла. И соблюдать принцип единой ответственности.

SomeData - это тип-значение (как целое число или цвет). В С++ это структура с открытыми полями. Этот тип не должен знать, каким образом редактируют SomeObject. При необходимости можно добавить несколько конструкторов и статических методов.

SomeObject - это тип-объект. Если нужно редактировать какое-то свойство пачками, то создайте тип SomeDataGroup "Группа редактирования". Группа может хранить список объектов, которые её используют. SomeObject кроме свойства SomeData может иметь свойство SomeDataGroup. Если оно заполнено в SomeObject, то SomeData будет браться из него. Это приблизительно. При реализации могут всплыть дополнительные нюансы.

@mashmed135 · 20.07.2024, 16:53

Сообщение от Igor3D

Как лучше?

возможно, по теме уже всё сказали - лень читать, поэтому по поводу твоего вопроса.

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

@Igor3D · 21.07.2024, 21:43 **[ТС]**

Сообщение от Shamil1

SomeData - это тип-значение (как целое число или цвет). В С++ это структура с открытыми полями. Этот тип не должен знать, каким образом редактируют SomeObject.

Когда-то видел более удачные названия чем мои

ReferenceHandler // тот кто ссылается, клиент (SomeObject)
ReferenceTarget // на кого ссылаются (SomeData)

При этом ReferenceTarget - совсем не какие-то простые данные что решаются владением. Обычно Handler и Target - оба объекты сцены, т.е. примерно "равноправны", выше пример где это даже один тип (light master/slave)

Сообщение от Shamil1

Если нужно редактировать какое-то свойство пачками

Это всего лишь один из вариантов, он ни в коей мере не "типичен", да и ф-ционал похож но совсем не равен групповому редактированию.

Сообщение от Shamil1

Нужно исходить из физического смысла.

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

Интересные "коллизии" возникают при дублировании/клонировании объектов со ссылками. На примере master/slave вроде все ясно - копия slave тоже slave (того же мастера), а копия мастера нет, на нее никто не ссылается. Но если клонируются оба (master и slave), то рез-т ожидается другой. Как и для других конкретных использований.

Ну и это я скромно/серенько назвал тему "про указатели", а при желании можно написать много громких слов типа "как организовать ссылки объектов" и все такое.

Да, и все-таки интересно, а как с этим в др языках где указателей нет?

@Shamil1 · 21.07.2024, 22:02

Сообщение от Igor3D

выше пример где это даже один тип (light master/slave)

В данном примере я увидел типы-значения (описывают параметры света) и типы-объекты (источники света).

Сообщение от Igor3D

ReferenceHandler // тот кто ссылается, клиент (SomeObject)
ReferenceTarget // на кого ссылаются (SomeData)

Это, во-первых, слишком обще. Ситуаций, когда "объект" ссылается на другой много, и они разные (требуют разного подхода). Во-вторых, выглядит как технические детали реализации, оторванные от физического смысла.

Сообщение от Igor3D

Да, и все-таки интересно, а как с этим в др языках где указателей нет?

Указатели есть (неявные). Просто не нужно заботится об очистке, так как используется другой алгоритм выделения/освобождения памяти.

@Igor3D · 22.07.2024, 16:56 **[ТС]**

Сообщение от Shamil1

Это, во-первых, слишком обще. Ситуаций, когда "объект" ссылается на другой много, и они разные (требуют разного подхода). Во-вторых, выглядит как технические детали реализации, оторванные от физического смысла.

Так может и хорошо что "оторван"? Ну вот зачем в данном случае нам (мучительно) вникать в "физический смысл" (предметную часть)? Этих смыслов огромное количество, и каждому просто нужен указатель (или null если такового нет), а дальше смысл сам разберется. Почему бы не сосредоточиться чисто на "технических деталях"?

Стандартные средства, напр weak_ptr или QPointer обеспечивают лишь валидность, при этом навязывая shared_ptr или QObject. Знать какие объекты ссылаются на данный - такого не знаю. Почему бы не реализовать такое самому? Напр (псевдокод)

C++
1
2
3
4
5
6
7
8
9
auto * rm = ReferenceManager::Instance();
..
rm->AddReference(ref_MasterLight, someObject,  someData);
..
Light * masterLight = rm->GetTarget<Light *>(ref_MasterLight, someObject);
..
std::vector<Light *> slaves = rm->GetHandlers<Light *>(ref_MasterLight, someData);
..
rm->RemoveReference(ref_MasterLight, someObject,  someData);

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

Добавлено через 2 часа 1 минуту
Да, и опять чуть не забыл. А где все эти распрекрасные книги и их знатоки? На мой взгляд, вопрос чисто общий, ни с какой предметной частью не связан. Вот этим знатокам и карты в руки, ожидается хотя бы "тыц" типа "читайте такую-то работу".

@Igor3D · 30.07.2024, 02:03 **[ТС]**

Апну (хорошую) тему. Пожуем как "член-указатель" реализован изначально, писалось (не мной) еще в 90-е (если не раньше) и, видимо, вначале на паскале.

Решение такое: всякий раз когда нужно что-то сделать для "ссылающихся" (SomeObject), мы пробегаемся по всем объектам, фильтруя и выполняя нужные действия для них. Псевдокод

C++
1
2
3
4
5
6
7
8
9
10
11
void RemoveReference2SomeData( SomeData * data )
{
 for (auto * obj : globalScene.objects) {
   SomeObject * so = dynamic_cast<SomeObject *> (obj);
   if (so && so->m_data == data) {
    if (undoFlag)
     AddRef2Undo(so);
    so->m_data = nullptr;
   } 
 }
}

Привлекает своей простотой, ведь кроме члена-указателя никаких дополнительных данных не создается. Также нет никаких обязательств типа shared_ptr или QObject.

Несмотря на всю "примитивность" такого подхода, докопаться/покритиковать его непросто. Контейнер "всех объектов" (globalScene.objects) есть, даже если его бы не было - создать несложно. Он слишком велик и может тормозить - ну вряд ли. Пожалуй единственный минус что я заметил - вживлять такой перебор приходится в нескольких местах, никак не связанных между собой. Если эти места знать/помнить - новый "член-указатель" успешно добавляется за 5 минут.

Если все работает, то в чем вопрос/проблема?

Смущает что это как-то "немодно" или "несовременно"

В самом деле, мы, (такие умные) вооруженные пятком новых стандартов языка, слот/сигналами и еще бог весть чем - почему-то не можем улучшить конструкцию что какой-то чувак написал лет 30 назад даже без плюсов. Это как

Новые блоги и статьи Все статьи Все блоги /
сукцессия 33. открытые вопросы от клауде anaschu 19.07.2026 "Что накопилось за эту часть А — тринадцать правок, из которых шесть пришли из ваших вопросов и каждая оказалась реальной ошибкой, а не калибровкой: односторонний симбиоз, отсутствующий листопад,. . .	32 сукцессия anaschu 19.07.2026 сукцессия 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не «подкручивает» сходимость —. . .	сукцессия 31: модель микоризы - это модель ещё нескольких явлений, социальных и экономических anaschu 18.07.2026 Теория «Всего»: апдейт v1. 1. 2 — 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не. . .	сукцессия 30. Массив проверяющих друг друга моделей anaschu 18.07.2026 Архитектура сети взаимопроверяющих моделей микоризной сукцессии (v2. 0) Развитие тензорного ОДУ-ядра и создание кросс-платформенного калибровочного полигона Уважаемые коллеги! В продолжение. . .
Грибы - это женщины, деревья - это мужчины. Анти инь янь для союза мужчины и женщины. anaschu 18.07.2026 ГЛАВНЫЙ НАУЧНО-ФИЛОСОФСКИЙ ВЫВОД: Сексуально-Репродуктивный Капитализм против Государства Моногамии Коллеги, мы вышли на финишную прямую 20-мерного ОДУ-моделирования вековой сукцессии (ветка. . .	Текстовый слайдер с нумерацией страниц и кроссбраузерность. russiannick 18.07.2026 Один мой друг написал текстовый слайдер с нумерацией страниц. Сегодня я расскажу как он умудрился подружить его с кроссбраузерностью. Очевидно сложно угодить с шириной каждому браузеру. Один крадет. . .	Грибы - это мемы, дерево - это человек. Применение микоризной модели к теории меметики Докинза. anaschu 18.07.2026 Меметический изоморфизм теории «всего»: Грибная сукцессия как модель эволюции идей Докинза Базовый код системы ОДУ микоризной сукцессии описывает не просто биологию, а универсальную. . .	Грибы - это корпорации, деревья - это государства. Механизм массонского захвата власти anaschu 18.07.2026 Макроэкономический изоморфизм теории «всего»: Грибная сукцессия как модель транснационального капитализма Базовый код системы ОДУ микоризной сукцессии описывает не просто биологию, а. . .