214 / 116 / 14
Регистрация: 30.05.2011
Сообщений: 1,772
|
|
1 | |
про кучу и не кучу11.07.2011, 21:49. Показов 2224. Ответов 17
уважаемые подскажите плиз, есть ли точный способ отличить по указателю, расположен объект в куче или нет, был ли он создан операцией new и можно ли к нему применить delete или нет?
первое что приходит в голову это адрес указателя. но так ли это? подскажите плиз
0
|
11.07.2011, 21:49 | |
Ответы с готовыми решениями:
17
Массив указателей на кучу векторов Выводит кучу мусора в файл Как собрать файлы в кучу? Помогите написать кучу задач |
Модератор
8908 / 6677 / 918
Регистрация: 14.02.2011
Сообщений: 23,512
|
|
11.07.2011, 22:00 | 2 |
Вы скакой целью интересуетесь???
что приходит в голову сравниваем адрес локальной переменной и куда указывает указатель если рядом то точно стек потом сравнить с какой нибудь глобальной если рядом то глобальная иначе куча указатель может лежать где угодно это же не выделенная память но зачем енто ??? если при выполнении то по моему не нужно а если при написании че ж ты не помнишь как переменные объявлял? Добавлено через 1 минуту а если malloс то тоже куча но delete не применим
1
|
214 / 116 / 14
Регистрация: 30.05.2011
Сообщений: 1,772
|
|
11.07.2011, 22:13 [ТС] | 3 |
где то читал что под стэк выделяется определенный объем по моему в верхних адресах. думал может как то от этого оттолкнуться.
ну а теоретически, зачем нужно? например есть некий класс принимающий указатель, захватывающий его так сказать. этот класс должен понимать можно и нужно ли делать delete по адресу принятого указателя, чтобы очистить его или это авто переменная. как то так.....
0
|
Модератор
8908 / 6677 / 918
Регистрация: 14.02.2011
Сообщений: 23,512
|
|
11.07.2011, 22:28 | 4 |
удалять должен тот кто вызывал иначе можешь огрести
например CFrameWnd создается динамически попробуй создать в стеке и получишь аварийный выход потому что в деструторе(по моему) стоит delete this надо анализировать PE заголовок там все есть и где стек и куча и глобальные переменные но когда пишешь прогу его еще нет а потом твой анализ никому не нужен. а почему delete а не delete[] или free как ты это узнаешь по указателю даже если будешь знать что он в куче?
1
|
214 / 116 / 14
Регистрация: 30.05.2011
Сообщений: 1,772
|
|
11.07.2011, 22:35 [ТС] | 5 |
мда, вопрос обрастает как снежный ком...согласен, слишком много но. а если тогда отбросить операции удаления. то каков алгоритм поиска отличия? сравнение с авто и статик переменными и если не+-(сколько?) значений то - куча?
0
|
1069 / 848 / 60
Регистрация: 30.04.2011
Сообщений: 1,659
|
|
11.07.2011, 22:44 | 7 |
По указателю это определить нельзя. Указатель не содержит НИКАКОЙ информации о способе создания объекта.
1
|
214 / 116 / 14
Регистрация: 30.05.2011
Сообщений: 1,772
|
|
11.07.2011, 22:45 [ТС] | 8 |
ValeryLaptev, а как можно?
0
|
2381 / 1665 / 279
Регистрация: 29.05.2011
Сообщений: 3,399
|
|
11.07.2011, 22:57 | 9 |
Сообщение было отмечено как решение
Решение
Мейерс в книге "Наиболее эффективное использование C++" в правиле 27 затрагивает этот вопрос, касательно объектов. И хотя он так же говорит об отсутствии способов определить, находится он в куче или нет, тем не менее там же приводится описание идеи, как можно реализовать проверку возможности удаления объекта (с использованием функции operator delete)
Раз интерес есть, то думаю есть смысл почитать.
5
|
214 / 116 / 14
Регистрация: 30.05.2011
Сообщений: 1,772
|
|
11.07.2011, 23:02 [ТС] | 10 |
ок. книга есть. просто пока учу стандарт. почитаемс. спасибо.
0
|
Модератор
8908 / 6677 / 918
Регистрация: 14.02.2011
Сообщений: 23,512
|
|
11.07.2011, 23:24 | 11 |
почитали
интересно но там говориться о создании классов которые нельзя разместить на стеке или в куче а здесь об определении каково-то указателя куда он указывает Добавлено через 1 минуту непереносимую
0
|
2381 / 1665 / 279
Регистрация: 29.05.2011
Сообщений: 3,399
|
|
11.07.2011, 23:44 | 12 |
Там сходная цель, это главное.
И автор этого не скрывает. Я, собственно, и порекомендовал почитать, чтобы была ясна аргументация, что дело это непростое.
0
|
Заблокирован
|
|
12.07.2011, 01:29 | 13 |
Я себе даже примерно представить не могу, зачем такие пляски с бубном могут понадобиться...
Вообще то, в таких случаях, "некие классы" принимают не указатели, а всевозможные смартпоинтеры. Правило очень простое: Удаляет объект тот, кто его создавал. Потому что, он знает точно, как это сделать правильно. В противном случае, это хороший повод ещё раз пересмотреть архитектуру.
2
|
214 / 116 / 14
Регистрация: 30.05.2011
Сообщений: 1,772
|
|
12.07.2011, 08:51 [ТС] | 14 |
может я сейчас глупость напишу. но как быть в случае с auto_ptr? Я создал объект в куче, далее его адрес у меня хранится в указателе и вот я передаю данный адрес к auto_ptr, насколько я понял происходит разрушающее копирование(т.е. мой указатель должен более не ссылаться на объект в куче), владение переходит к auto_ptr и, на выходе auto_ptr уничтожается. удаляя объект в куче. Понимаю что скорее всего внутри auto_ptr сам создает копию и сам ее разрушает, но как он уничтожает МОЮ изначальную копию в куче?Либо если копия не создается, то как он может уничтожить объект о создании которого не знает ничего? Ведь во время данного процесса я удаления не касаюсь.
Извиняюсь заранее если написал глупость, но спросил то, что непонятно.
0
|
187 / 174 / 18
Регистрация: 22.03.2010
Сообщений: 612
|
|
12.07.2011, 09:18 | 15 |
разрушающее копирование происходит при копировании одного auto_ptr в другой. Тот указатель который ты передал в auto_ptr остаётся валидным
Добавлено через 7 минут у меня так определён деструктор ~auto_ptr() { delete _M_ptr; } видимо в auto_ptr можно запихать только указатели для которых память выделялась с помощью new Добавлено через 2 минуты и кстати обрати внимание, что если ты запихал туда указатель выделенный с помощью new[] то ты сразу попадёшь в область неопределённого поведения. В самом лучшем случае пройзойдёт утечка памяти
2
|
342 / 306 / 36
Регистрация: 16.06.2009
Сообщений: 486
|
|
12.07.2011, 11:07 | 16 |
Для этого предусмотрен boost::shared_array, так что и пихать, что попало в std::auto_ptr нет необходимости.
1
|
214 / 116 / 14
Регистрация: 30.05.2011
Сообщений: 1,772
|
|
12.07.2011, 13:49 [ТС] | 17 |
в общем если подводить итог моего вопроса и полученных ответов, то вырисовывается следующее.
Сделать класс который может сам принимать решение - что вызывать delete, delete [], free или вообще не вызывать - практически невозможно, в любом случае он не сможет гарантировать стабильной работы. Определить где создан объект по указателю - невозможно. умные указатели, подразумевают работу с объектами созданными определенным образом, т.е. уже предполагается некая информация на входе. например то что пользователь создал объект при помощи new. Большое всем спасибо за ответы. Узнал много нового
0
|
Заблокирован
|
|
12.07.2011, 16:14 | 18 |
Обычно же как делается:
Некая сущность отвечает за создание объектов. Эта сущность знает, как именно нужно создать объект, и как его скормить умному указателю. А наружу уже выдаётся проинициализированный умный указатель. Получается что-то вроде: SmartPointer ptr = CreateObj(); //все, умный указатель уже владеет подопечным объектом. И ему глубоко фиолетова, как он в нём оказался. Теперь можно скормить этот указатель клиентскому коду, и этому коду будит глубоко фиолетова кто и как отвечает за время жизни объекта.
0
|
12.07.2011, 16:14 | |
12.07.2011, 16:14 | |
Помогаю со студенческими работами здесь
18
Iostream выбивает кучу ошибок Реализовать бинарную кучу на базе указателей Оператор присваивания для объектов на кучу Нужно 2 кода слепить в кучу (деревья) Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |