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

А как сделать, чтобы было "близко" ?

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



Написал и забыл  Через пару месяцев я с этим точно ничего делать не буду. Вспоминается одно из правил плохого тона программирования: "временные решения очень быстро становятся постоянными".

P.S.: снял пометку о решении. Раз местным гуру не нравится такой вариант, остается ждать либо другого решения, либо ответа почему подобная ситуация не должна возникать в принципе...

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

Как раз своей новой конструкцией Вы и обременили себе память. 


Не понял.


Один раз написал - забыл, второй, а в третий так вылезет, что мало не покажется.   


вот вот   



"Далеко" это как например внутри Get-функции создавать объект который должен быть удален снаружи.
А "близко" это то что создано в конструкторе- удаляeтся в деструкторе.

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


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


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

SABROG, для начала попробуй описать что ты хочешь получить в итоге (методы реализации на данном этапе не интересны).
Например, то что ты написал в первом сообщении можно сделать так:Теперь, для получения просто указателя нужно применить метод get(). Для (пере)присвоения значения указателю - метод reset(). Для доступа к содержимому - стандартный синтаксис (унарная * или ->). delete будет вызван автоматически при уничтожении экземпляра объекта MyStruct.
Но я не уверен, что это все нужно городить, так как мне кажется сама идея хранения такого большого списка однотипных параметров нелогичной. Может стоит сделать как-то иначе?

Предположим есть treeview, который является Property Editor'ом для какой-нибудь IDE или просто редактор БД.
Несмотря на то, что каждый параметр имеет свой тип, сами итемы этого treeview - одного класса. В итоге 10 строковых параметров, 5 интовых, 4 блоба, 8 флоат - все указатели имеют один тип - элемент treeview.

То есть у нас есть структура которое содержит n-e кол-во наследников одного типа. Тут понятно.. Но пока видим только массив.
 Продолжайте.   

Аналогично

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

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

и что это меняет ? 
Разница возникнет, тогда, когда Вам 
1. либо надо знать конкретный тип каждого/определенного элемента
2. либо обращаться к элементу по имени (опять же известно ли имя на момент компиляции? и полезна ли даная известность ?)

SABROG, не вижу проблем с ограниченностью количества элементов. Почему нельзя написать в структуре mytype *items[20]?

А параметры проверять так чтоль ?



Вместо

а почему бы не root->title()->text();  или  даже root()->title()->text();  ?
если конечно статические имена в Вашем случае удобны чем динамические.


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

С массивом я такое смогу провернуть только если создам класс как уже писали тут http://forum.vingrad.ru/index.php?showtopi...t&p=1743811

auto_ptr использовать опасно т.к. treeview может сам удалить указатель.

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

а "вручную" как Вы узнаете что treeview уже удалил элемент и его не надо удалять?


пока Вы не привели ни одного довода, для создания той структуры о которой идет речь. 
Как я понял у Вас есть treview с элементами. Вы делаете его маппинг. Т.е Ваша структура служит посредником для доступа к определенным полям.
В таком случае использование открытой структуры, внесет Вам большой ряд проблем.
Если доступ к элементам будет "разгружен" функцией, то Вы отгородите реализацию "компонента" от остальной программы.

Все таки до сих пор не понятно, важно ли для самой программы (ее бизнес-логики) знание статического имени.
можно ведь вместо  root()->title()->text(); использовать динамическое имя root()->node(title)->text().

ну а можно статическое root()->node<title>()->text(). (для удобства только придется у Александреску позаимствовать шаблоны TypeList и некоторые другие)




Это сообщение отредактировал(а) mes - 31.12.2008, 14:06