Предположим, что есть структура типа 



Так вот как в цикле удалить указатели из этой структуры, чтобы освободить память, при этом, чтобы оставить возможность обращаться к этим указателям по имени и не городить башню типа:



Плюс с точки зрения безопасности. Я ведь могу добавить итем в структуру и забыть прописать его удаление.

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

Использовать всякие hashmap'ы я не хочу. Может просто в структуре объявить массив указателей, а в отдельной структуре описать имена каждого элемента. Когда нужен поименный доступ буду "кастовать" этот массив в структуру, когда нужно удаление - буду пробегаться по массив. 

Может просто использовать конструктор-деструктор.

или писать на ЯП с автоматическим сбором мусора

А смысл, если в том же деструкторе придется прописывать многоэтажное удаление ?



Намек на Java понят, но что если проекту уже несколько лет и он на C++  ? (проекта нет на самом деле, это гипотетически)

А использовать умные указатели? Да тот же shared_ptr<> освободит от необходимости писать кучу delete.

А его можно использовать с библиотеками, которые не знают о существовании умных указателей ? Например у метода чужого класса параметр mytype * и больше никакой ? Если я получу указатель через get() и передам его в метод. Метод его поюзает и вернет управление. Все, теперь мне надо удалить указатель. Не удалится же он сам ?

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


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


shared_ptr<> удалит объект на который он указывает сам, как только запустится деструктор последнего shared_ptr, указывающего на этот объект.

В деструкторе прописывается один раз, а если удалять в коде программы, то при изменении структуры надо будет найти все места, где происходило удаление.

Пример какой то надуманный.. Чего от Вы не договариваете.. 

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

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


В принципе очистка и так в деструкторе идет, но в стороннем классе, который использует эти структуры. Место хоть и одно, но с  точки зрения оптимизации 20 инструкций delete идущих подряд в бинарнике, вместо цикла с адресной арифметикой, не очень нравится.


Просто сегодня увидел код, где в цикле удалялись элементы структуры с инкриментированием указателя на эту структуру. И вспомнил, что действительно бывают часто такие ситуации при написании GUI приложений, когда надо инициализировать кучу итемов и у каждого свое имя.


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

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

Это сообщение отредактировал(а) SABROG - 30.12.2008, 13:20

ИМХО, лучше  смотреть с точки зрения логичности и подерживаемости кода.


А при чем тут реализация объектов ?

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






Это сообщение отредактировал(а) mes - 30.12.2008, 13:41

Вот о чем я говорю. Метод с enum отбросил из-за некоторой кривизны доступа к именам объектов, хотя в виде класса смотрится неплохо.



Т.е. тут достаточно менять список итемов в структуре-интерфейсе. Об остальном программа заботится сама.

Это сообщение отредактировал(а) SABROG - 30.12.2008, 13:55

Удачи и будем надеяться, что "крах " не коснется Вашей конструкции.   

  
Если бы это написал мой подчиненны, я бы заставил переписывать...
И вообще, с некоторых пор для этих целей использую std::auto_ptr. И стараюсь не юзать его с new вне классов...

В каком месте  ? Всякое конечно может быть. Особенно, если компилятору вздумается размещать данные не по порядку.


А что именно не нравится, сама задача или то как я реализовал и у тебя есть третий вариант ее решения  ? Или ты имеешь ввиду, что не замарачивался бы вообще с этим и прописывал все ручками ?

 Вы не учитываете выравнивание...(хотя Вам повезет, так как размер указателя на обычных архитектурах  "попадает на границу выравнивания".)


А вот этого не вздумается. )



Хотя бы то, что способ использования определен "далеко" от декларации.

Это сообщение отредактировал(а) mes - 30.12.2008, 18:48