|
|
|
STL containers
|
|||
|---|---|---|---|
|
#18+
Наверно, этот вопрос уже обсуждался, но т.к. топика не нашел, задам еще раз :) Необходимо хранить довольно объемные объекты классов и их потомков. Что лучше помещать в собственно контейнеры (list, vector etc): сами объекты или указатели на них? Как я понимаю, есть минусы в обоих случаях. хранение самих объектов: - при добавлении нового элемента контейнера объект нужно создать дважды: сначала собственно объект коструируется, а затем копируется в элемент контейнера. При большом размере объекта и их количестве могут начаться тормоза. хранение указателей: - необходимость явного вызова деструкторов для удаляемых объектов; неработоспособность некоторых алгоритмов – remove (утечка памяти), fill, copy (копируются указатели, а не объекты) - т.к. элементы модифицируемые, то конструкции с итераторами типа Код: plaintext 1. 2. Я правильно рассуждаю? Окончательный вопрос: какое из зол, по мнению All, меньше, и что все-таки лучше хранить: объекты или указатели? Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 11:06 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
shared_ptr smart_ptr ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 13:31 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
Gluk прав, но слишком краток. В контейнере можно хранить как объекты, так и указатели, но если вам понадобится полиморфное поведение объектов, поневоле придется сладывать туда указатели, а лучше чтобы избежать утечек памяти - smart pointer'ы. Один из представителей - std::auto_ptr.Если хочется узнать о них подробнее читайте Александреску Modern C++ design... Что касается алгоритмов почитайте внимательнее про STL, если вам надо глубокое копрование используйте вместо copy transform, вместо fill - generate ну и т.д А вот что касается утверждения на счет изменения адреса объекта - не говорите об этом брльше никогда и никому. Адрес объекту дается раз и навсегда при аллокировании памяти под него, если у вас вдруг изменился адрес объекта - значит вы видите уже другой объект ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 14:23 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
blindedОдин из представителей - std::auto_ptr. std::auto_ptr - это аналог boost::shared_ptr? А куда лучше склониться? ;) А вот что касается утверждения на счет изменения адреса объекта - не говорите об этом брльше никогда и никому. Адрес объекту дается раз и навсегда при аллокировании памяти под него, если у вас вдруг изменился адрес объекта - значит вы видите уже другой объект Это предположение я сделал из того, что этот код не работает Код: plaintext 1. 2. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 14:34 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
VasTemp...Это предположение я сделал из того, что этот код не работает Код: plaintext 1. 2. Код: plaintext 1. 2. а полный текст приведите пожалуйста данного тэста... имееться ввиду с объявлениями переменных участвующих в данном коде. (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 14:58 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
blindedGluk прав, но слишком краток. авторstd::auto_ptr - это аналог boost::shared_ptr? А куда лучше склониться? ;) НИКОГДА, НИКОГДА в этой задаче НЕ СКЛОНЯЙТЕСЬ к auto_ptr ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 16:17 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
Ответ на этот вопрос однозначен - нужно хранить объекты в контейнерах по значению. Просто потому что STL не поддерживает автоматическое уничтожение объектов при удалении их из коллекций. Что бы его поддержаТь, надо переопределить буквально все операции добавления/удаления. А это страшный геморой. Однако если вас устроит реализация внешнего контроля за созданием и удалением объектов (например, такая схема : объекты создаются, пихаются в контейнеры , обрабатываются, а затем все скопом удаляются) , то можно (и нужно) хранить в контейнерах указатели. Вот такая у нас замечательная библиотека STL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 21:12 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
kolobok0а полный текст приведите пожалуйста данного тэста... имееться ввиду с объявлениями переменных участвующих в данном коде. Урезанный код выглядит так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2006, 09:10 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
Что именно не работает? Приведи текст ошибки. Вот урезанный кусок из моего класса: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Отлично все работает! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2006, 10:52 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
VasTempУрезанный код выглядит так:.... к сожалению в нём нет тех вещей которые могут оказаться причиной...Что бы не терять время привожу Ваш кусочек и довесок к нему (некоторые имена подкорректированы - уж не обесудьте, если на просвет не совпадёт :) ). Весь код рабочий, проблем не наблюдаю... Код: plaintext 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. в коде нет освобождения ресурсов. Думаю, что проблемы теперь будет легче найти у ВАс... Ищите в объявлениях, наполнении вектора и прочей чухне... с уважением (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2006, 15:47 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
В продолжение темы (VasTemp - это я, просто пароль забыл :) Локализовал падающий код: Код: plaintext 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. Научите глупого! Не могу понять, что не так! :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 11:55 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
жжош, естественно сбивается происходит ресайз вектора на осередном пуше и итераторы превращаются ... превращаются итераторы ... в элегантные указатели х.з. куда совершенно недетеменированно притом. Поставь резерве 100000 у вектора, результат приятно удивит :) Кстати, а нафига такие половые извращения ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 12:46 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)жжош, естественно сбивается происходит ресайз вектора на осередном пуше и итераторы превращаются ... превращаются итераторы ... в элегантные указатели х.з. куда совершенно недетеменированно притом. Поставь резерве 100000 у вектора, результат приятно удивит :) Нехорошо как-то: я считал, что работа итераторов основана на счетчиках, и они всегда указывают на заданный элемент (до его удаления, конечно). :( Gluk (Kazan)Кстати, а нафига такие половые извращения ??? Это контейнер "действий", которые могут изменять существующие или порождать новые. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 12:59 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
Итератор вектора это (почти) всегда указатель. При ресайзе содержимое вектора перемещается. Ваше отношение к этому ничего не изменит. Так есть. И на то есть причины. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 13:04 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
заведи дополнительный вектор, вливай новые элементы туда, после прохода цикла сливай. Желательно конечно алгоритмами а не циклами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 13:07 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
Кстати, это не единственный сюрприз итераторы дека еще более странные. Они инвалидируются, а указатели полученные ранее из них остаются валидными :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 13:08 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
VasTempхранение самих объектов: - при добавлении нового элемента контейнера объект нужно создать дважды: сначала собственно объект коструируется, а затем копируется в элемент контейнера. При большом размере объекта и их количестве могут начаться тормоза. хранение указателей: - необходимость явного вызова деструкторов для удаляемых объектов; неработоспособность некоторых алгоритмов – remove (утечка памяти), fill, copy (копируются указатели, а не объекты) - т.к. элементы модифицируемые, то конструкции с итераторами типа Когда вы храните указатели на объекты, то тратите память ещё и на указатели - если память критична, то это явно лишнее. Мне кажется, что вам есть смысл оценить обём требуемой памяти и понять, что вам нужно оптимизировать - память или скорость. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2006, 00:46 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
Какойто спор интересный что хранить, выбор простой если вам нужен контейнер с конкретным типом то лучше хранить сами объекты и то при условии что вас удовлетворяет стандартный аллокатор, если у вашего обекта нет открытого конструкторакопирования, а вы не готовы переписывать allocator выбора у вас нет - придется хранить указатели, аналогично придется хранить указатели ежели хочется получить полиморфное поведение объектов в контейнере. Чтобы избежатть утечки ресурсов при хранении указателей, храните не указатель, а smart poiter Чтобы не оказаться в положении автора топика, помните что есть операции которые инвалидируют итераторы. И никогда не пфтайтесь удалить iterator end() - эффект потрясающий! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2006, 10:56 |
|
||
|
STL containers
|
|||
|---|---|---|---|
|
#18+
Стандартные аллокаторы не работают, они вообще бесполезны. Это так, просто напомнил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2006, 12:59 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=33958286&tid=2030586]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
157ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
81ms |
get tp. blocked users: |
2ms |
| others: | 208ms |
| total: | 493ms |

| 0 / 0 |
