How do you delete...?

This is a discussion on How do you delete...? within the C++ Programming forums, part of the General Programming Boards category; How do you delete an element of an array of pointers which is pointed at an allocation of memory on ...

  1. #1
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827

    Question How do you delete...?

    How do you delete an element of an array of pointers which is pointed at an allocation of memory on the heap?

    I tried:

    Code:
    delete arrayOfPointers[i];
    inside a for loop, but it outputs the following message:

    memory clobbered before allocated block
    So I guessed that syntax like that only deletes the element of the array of pointers itself, and not what that element is pointing at. So, next I tried:
    Code:
    const char** pointer = &arrayOfPointers[i];
    delete pointer;
    thinking that by retrieving the address of the element of the array of pointers, I could then delete it. But it still outputs the same message. So I guess that using the address-of operator on an element of an array of pointers (or an element of any array) will only retrieve the address of the element, instead of what's stored in the pointer element.

  2. #2
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Hmm...just tried:

    Code:
    const char* pointer = &*arrayOfPointers[i];
    but that outputs the same message too.

  3. #3
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Another hmm...

    Seems an expression like this:
    Code:
    delete [] arrayOfPointers;
    not only deletes the array itself, but it also calls the destructor of every element of the array. So I guess that syntax takes care of even an array of pointers, with each element pointer assigned to a "new" location...
    That's what I originally assumed, but someone else here at the forums seemed to imply to the contrary of this, so I was worried that I had a memory leak. Now I know I don't...

  4. #4
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Quote Originally Posted by Programmer_P View Post
    Another hmm...

    Seems an expression like this:
    Code:
    delete [] arrayOfPointers;
    not only deletes the array itself, but it also calls the destructor of every element of the array. So I guess that syntax takes care of even an array of pointers, with each element pointer assigned to a "new" location...
    This is sort of true and sort of false -- it calls the destructor, yes, but that's about as far away from calling "delete" as you could ever hope to be.

    You'll need to show us your code, because quite frankly at this point none of trust you to have not moved all your pointers around so that they can't be deleted.

  5. #5
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Quote Originally Posted by tabstop View Post
    This is sort of true and sort of false -- it calls the destructor, yes, but that's about as far away from calling "delete" as you could ever hope to be.

    You'll need to show us your code, because quite frankly at this point none of trust you to have not moved all your pointers around so that they can't be deleted.
    Arrays of pointers...

    Its the first code...
    Like already mentioned, I have each element of the array of pointers pointed at *new* strings. So, theoretically, the destructor for each element will be called, and they will be deleted once I do:

    Code:
    delete [] object.arrayOfPointers;
    That is, if the char type is able to delete "this". Never looked at the code for the basic data types before, so have no idea.

  6. #6
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Right. So in that case each of the array of pointers is not pointing at something that came from new, so does not need to be deleted.

  7. #7
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Quote Originally Posted by tabstop View Post
    Right. So in that case each of the array of pointers is not pointing at something that came from new, so does not need to be deleted.
    Come again...?
    Each element of the array of pointers is assigned the address of a "new" string, most definitely...hence the:
    Code:
    object.arrayOfPointers[i] = object.anotherStr->data();
    lines. Each time this happens, anotherStr is pointing at a "new" string. Of course, on second thought, seeing as data() returns a const char* to an array containing the same thing as the string (and not the string itself)...that's probably a different memory address than the ones given to "new" allocations. But, no, it can't be...because I've already tried deleting the anotherStr(s) before outputting the strings. What ends up happening is the strings are deleted before they can be outputted. I don't know why that is.
    Last edited by Programmer_P; 05-24-2010 at 10:37 PM.

  8. #8
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,304
    Quote Originally Posted by Programmer_P View Post
    Come again...?
    Each element of the array of pointers is assigned the address of a "new" string, most definitely...hence the:
    Code:
    object.arrayOfPointers[i] = object.anotherStr->data();
    lines. Each time this happens, anotherStr is pointing at a "new" string. Of course, on second thought, seeing as data() returns a const char* to an array containing the same thing as the string (and not the string itself)...that's probably a different memory address than the ones given to "new" allocations. But, no, it can't be...because I've already tried deleting the anotherStr(s) before outputting the strings. What ends up happening is the strings are deleted before they can be outputted. I don't know why that is.
    No you've got it all wrong. I told you this wasn't doing what you thought it was doing.

    If this were truly an array of pointers to things allocated by new then "delete arrayOfPointers[i];" as per your first guess is 100% correct.
    The issue here is that what you've got is not pointers to things allocated by new. What you've got are pointers to *something* that is internal to a string object. You've essentially tried to rip some of the guts out of a string, leak the string itself, and improperly free pieces of its internals.

    If you were a doctor trying to empty a patient's stomach contents, this would be like cutting the stomach out of the patient, burning it, and calling it a job well done (if you'll excuse the pun).

    In other words you have no business trying to rip the data() out of the string, and pretending that it is akin to the string itself - it isn't! It is povided to view the contents of a string, and that is all. It may be an internal allocation that is shared with other strings, or part of a string pool maintained by the string class, or a pointer to somewhere inside a special global chunk of memory used specifically for providing a read-only copy when data is called, or who knows what else. It in no way corresponds to something you have and responsiblity, or even the ability, to mess with it in any other way whatsoever besides reading it, and even then only until the next call to a non-constant member function of the string object. It is not something you can hold onto beyond the lifetime of the string object itself and certainly not something you can delete. It's more of a quick peek into something that you probably shouldn't actually be peeking at anyway.

    If you delete the "anotherStr" then that string object cleans up after itself, and this can mean that the buffer you were pointing to is sometimes gone. Depending on where it chose to put the buffer, and how the particular runtime library you're using works, the buffer may or may not actually happen to sometimes look like the data is still there. No matter what though, once the string is deleted, that buffer is not allowed to be accessed at all.

    Hopefully soon you'll finally see the light that using pointers to string objects in your program really was a ridiculous thing to do to begin with. Forget doing it with pointers, as I said in the beginning, declaring a pointer to a string object as a class member is almost guaranteed to be the wrong thing to do. Just declare a vector of strings and return that. If you're going to learn C++, you'd be best to learn about vectors and strings sooner rather than later.
    Some of us have been using the language for about a decade, and in very large projects, and some of us have even taught programming at some point. You'd do better off to pay closer attention
    Last edited by iMalc; 05-25-2010 at 03:16 AM.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  9. #9
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Quote Originally Posted by Programmer_P View Post
    Come again...?
    Each element of the array of pointers is assigned the address of a "new" string, most definitely...hence the:
    Code:
    object.arrayOfPointers[i] = object.anotherStr->data();
    Do you see the word "new" there? I don't. That data() pointer is not yours, you did not get it from new, so you cannot delete.

  10. #10
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Quote Originally Posted by iMalc View Post
    No you've got it all wrong. I told you this wasn't doing what you thought it was doing.

    If this were truly an array of pointers to things allocated by new then "delete arrayOfPointers[i];" as per your first guess is 100% correct.
    The issue here is that what you've got is not pointers to things allocated by new. What you've got are pointers to *something* that is internal to a string object. You've essentially tried to rip some of the guts out of a string, leak the string itself, and improperly free pieces of its internals.

    If you were a doctor trying to empty a patient's stomach contents, this would be like cutting the stomach out of the patient, burning it, and calling it a job well done (if you'll excuse the pun).

    In other words you have no business trying to rip the data() out of the string, and pretending that it is akin to the string itself - it isn't! It is povided to view the contents of a string, and that is all. It may be an internal allocation that is shared with other strings, or part of a string pool maintained by the string class, or a pointer to somewhere inside a special global chunk of memory used specifically for providing a read-only copy when data is called, or who knows what else. It in no way corresponds to something you have and responsiblity, or even the ability, to mess with it in any other way whatsoever besides reading it, and even then only until the next call to a non-constant member function of the string object. It is not something you can hold onto beyond the lifetime of the string object itself and certainly not something you can delete. It's more of a quick peek into something that you probably shouldn't actually be peeking at anyway.

    If you delete the "anotherStr" then that string object cleans up after itself, and this can mean that the buffer you were pointing to is sometimes gone. Depending on where it chose to put the buffer, and how the particular runtime library you're using works, the buffer may or may not actually happen to sometimes look like the data is still there. No matter what though, once the string is deleted, that buffer is not allowed to be accessed at all.

    Hopefully soon you'll finally see the light that using pointers to string objects in your program really was a ridiculous thing to do to begin with. Forget doing it with pointers, as I said in the beginning, declaring a pointer to a string object as a class member is almost guaranteed to be the wrong thing to do. Just declare a vector of strings and return that. If you're going to learn C++, you'd be best to learn about vectors and strings sooner rather than later.
    Some of us have been using the language for about a decade, and in very large projects, and some of us have even taught programming at some point. You'd do better off to pay closer attention
    Ok, I get it...
    I'll use a string vector instead of an array of char pointers.

  11. #11
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Quote Originally Posted by tabstop View Post
    Do you see the word "new" there? I don't. That data() pointer is not yours, you did not get it from new, so you cannot delete.
    Well, my reasoning was based on the assumption that data() was pointed at the same location in memory as the string "anotherStr" which WAS allocated with new.

    But I now understand that this is not the case, thanks to iMalc.

    Thanks guys.

  12. #12
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,614
    The thing is that data() returns something from anotherStr, and that alone screams do not delete me, unless explicitly specified somewhere in some documentation (and even so, it would usually be a poor design choice).
    Data that you get from an object of sorts you should never delete unless you have some documentation that says so. The reason is that in C++, the design paradigms say that an object should clean up after itself. So any data it allocates it should also delete. You have no business deleting data that you got from an object.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Proper Usage of the delete Operator
    By thetinman in forum C++ Programming
    Replies: 7
    Last Post: 04-25-2007, 11:53 PM
  2. BST delete again, but this time I think I'm close
    By tms43 in forum C++ Programming
    Replies: 9
    Last Post: 11-05-2006, 05:24 PM
  3. delete and delete []
    By Lionel in forum C++ Programming
    Replies: 8
    Last Post: 05-19-2005, 01:52 PM
  4. why is this prog crashing on delete?
    By Waldo2k2 in forum Windows Programming
    Replies: 2
    Last Post: 12-04-2002, 10:17 PM
  5. Problem need help
    By Srpurdy in forum C++ Programming
    Replies: 1
    Last Post: 07-24-2002, 12:45 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21