То, что определяет то, что записано в указатель C++, когда удаляют, называют?
Вы можете легко добиться этого, используя следующую скрипку. Не нужно использовать много тегов списка в вашем коде. Всегда пытайтесь писать СУХИЕ коды. Это пример кода, и вы можете внести необходимые изменения в соответствии с вашими требованиями
.lists {
margin:0;
padding:0;
list-style:none;
display:flex
}
.lists li {
display:flex;
flex-direction:column;
border-right: 1px solid #000000;
padding: 4px 10px;
justify-content:center;
text-align:center;
font-size:18px
}
.lists li:last-child {
border:none
}
.lists li > span:first-child {
color: #11A8A1;
}
10 ответов
Nothing in the standard determines what gets written there. Visual studio (at least in debug mode) will often write sentinal values all over the place to help in catching bugs early.
This value is not something you can rely on, but if you ever find that value popping up in your program mysteriously, you can assume that somewhere you are referencing deleted memory. See this answer for a list of values under one compiler.
It's also entirely possible that it's a free list pointer, pointing to the next piece of free memory. Most memory allocators keep their free memory in a linked list of sorts, using the free memory they are tracking to store the tracking data.
In any case, you MUST NOT use that pointer value for anything you want to keep working, unless you call up microsoft and get some documentation saying why that value is what it is, and get them to guarantee that it will not change. And even then, know that your code is now tied to one compiler's behaviour. In C++, accessing unallocated memory is undefined and evil.
Edit: You can't even rely on that value changing after a delete. There's nothing that says a compiler needs to modify the data on delete.
As Josh said, there are a number of values that can be inserted, to make life easier for the debugger with debug builds. These are compiler specific and in no way can be relied on. In a release build, I believe the default behavior of most C++ compilers is to do nothing with the memory that is freed, so, until that address space is allocated again, the contents will basically be what ever was there before, of course, you should NEVER rely on this.
Простой вызов оператора удаления для указателя не означает, что «удаленная» память будет очищена. Он вызовет только деструктор удаленного объекта (ов) и пометит выделенную память кучи как освобожденную. (это поведение оператора удаления по умолчанию.)
Если вам нужно очистить содержимое памяти при удалении, вам нужно переопределить оператор удаления.
Скорее всего, это значение указателя является таблицей vtable базового класса. Когда деструктор производного класса запускается, после того, как он завершает свое обычное тело, он «переделывает» память как базовый тип (в основном, записывая указатель vtable базового класса в объект), а затем вызывает деструктор базового класса.
Обратите внимание, что это поведение является внутренней деталью реализации поддержки C ++ среды выполнения компилятором, поэтому другие компиляторы (или будущие версии того же компилятора) могут делать что-то совершенно другое. Но это «преобразование vtable в базовый класс и вызов деструктора базового класса» довольно распространено и восходит к исходной реализации cfront C ++
Почти наверняка существует определенное внутреннее значение значения, которое появляется каждый раз, когда вы удаляете объект.
Однако оно может измениться в следующей версии Visual C ++ и, безусловно, будет отличается от компиляторов других производителей.
Тот факт, что он выглядит одинаковым каждый раз, когда вы удаляете объект , не означает ничего полезного . Это даже не может быть потенциально полезным. Предположим, вы нашли способ использовать это в своих интересах, это было бы ужасным взломом, и вы в конце концов пожалеете об этом.
Постарайтесь выбросить это из головы!
As Michael Burr said earlier, the memory goes back to the free store. Some free stores are implemented as linked lists, with the ->next pointer placed at the beginning of the free buffer. It is possible that the magic number that you are seeing (0x604751f8) to be the 'end of list' guard. You can check by performing the following experiment:
Foo* f = new Foo();
Bar* b = new Bar();
// make a note of the values of f and b _pointers_
delete b; // check that b points now to 0x604751f8
delete f; // check that f points now to 0x604751f8
// now check that does b point to; it might point to f!
Let us know what you find!
One you delete an object the memory it was using gets put back into the free store (heap). Of course the free store will have its own data structures (and possibly debugging data) that it will apply to that memory.
What the particular value you're looking at means? Could be almost anything.
No, you cannot rely on it being set. You cannot even rely on it being different.
MS-DOS heap managers often allowed using freed memory until the next call to malloc. New and delete in that era called malloc and free.
These days, most heap managers are reasonable about returning memory to the OS, which means you cannot even rely on it being readable! Even one ones that still allow it (glibc has a bwd-compat mode that allows it) you are subject to thread-race conditions.
Also, delete is allowed to change the pointer to NULL if it is an lvalue.
Once you call delete, don't even think about dereferencing the pointer.
Программа пытается вам что-то сказать. Дата, номер телефона, кто знает?
А теперь серьезно, это не указано , полностью зависит от реализации и, конечно же, пытается разыменовать этот указатель после delete приведет к неопределенному поведению. Итак, короче, кого это волнует?
У вас есть доступ к исходному коду CRT в Visual Studio. Вы могли бы взглянуть. Я сделал это один раз, чтобы лучше понять мою ошибку.