delete[] mechanics

Hey all,

I've looked all over for how delete[] *exactly* works. I *thought* it just performed the delete operation until it found a null, but this seems wrong.

Could someone explain if this leaks memory or not?

char a = new char[50];
a[0] = '\0';
delete[] a;

Also, what is there a defined behavior for
char a = new char[50];
delete[] &a[7];

When delete[] is called, does it look up how much memory was allocated to this starting address then clean it all up? All the documentation just says it frees memory for the corresponding new[].

Thanks!

Quote:

---

Originally Posted by spelltwister

Could someone explain if this leaks memory or not?

char a = new char[50];
a[0] = '\0';
delete[] a;

---

It shouldn't even compile.
You can't assign a char pointer to a char.

Quote:

---

Also, what is there a defined behavior for
char a = new char[50];
delete[] &a[7];

---

It shouldn't even compile.
If a was a char * then the answer is no!

Quote:

---

When delete[] is called, does it look up how much memory was allocated to this starting address then clean it all up?

---

Yes

Yes, I did mean
char* a = new char[50];

Do you have any source you can reference where it says it looks up allocated space to delete it? I've looked on msdn, and various other places and nothing mentions how it actually does the freeing of memory.

Thanks!

delete[] also calls destructors, btw, it doesn't just free memory. new and delete eventually end up using malloc and free. The operating system actually determines how to allocate and deallocate memory. It will be different on different platforms.

Quote:

---

Originally Posted by spelltwister

Yes, I did mean
char* a = new char[50];

Do you have any source you can reference where it says it looks up allocated space to delete it? I've looked on msdn, and various other places and nothing mentions how it actually does the freeing of memory.

Thanks!

---

That's because it is 100% implementation defined. And the OS is usually involved too.

There are papers out there that explain the different ways of doing it, but onless you are a compiler writter, you have no need to know.

Quote:

---

Originally Posted by spelltwister

Yes, I did mean
char* a = new char[50];

Do you have any source you can reference where it says it looks up allocated space to delete it? I've looked on msdn, and various other places and nothing mentions how it actually does the freeing of memory.

Thanks!

---

This took less than a minute to find.
http://www.parashift.com/c++-faq-lit...html#faq-16.14

Quote:

---

Originally Posted by GCDEF

This took less than a minute to find.
http://www.parashift.com/c++-faq-lit...html#faq-16.14

---

I like the short answer :)

Looks like g++ doesn't use the first approach. A quick inspection of the memory just before a test array doesn't show any signs of it's size.

Quote:

---

Originally Posted by GCDEF

This took less than a minute to find.
http://www.parashift.com/c++-faq-lit...html#faq-16.14

---

Thanks for the reply. I'm glad ur skills of using searching exceed mine ;D Is there a way to query for the allocated space? For instance, is there a way to:

char* c = new char[50];
... more code that may affect c ...
int space = query_for_space_allocated(c);
int chars_allocated = space / sizeof(char);

I didn't think this was possible, but if the system knows, why can't we get that information?

Quote:

---

Originally Posted by spelltwister

If the system knows, why can't we get that information?

---

Because not all pointers point to dynamically allocated memory, and hence, the information is not always available.

If you create an array on the stack, and pass it to a function, the array decays into a pointer, and there is absolutely no information about the size associated.

Quote:

---

Originally Posted by spelltwister

Thanks for the reply. I'm glad ur skills of using searching exceed mine ;D Is there a way to query for the allocated space? For instance, is there a way to:

char* c = new char[50];
... more code that may affect c ...
int space = query_for_space_allocated(c);
int chars_allocated = space / sizeof(char);

I didn't think this was possible, but if the system knows, why can't we get that information?

---

The answer is to quit using raw arrays and use container classes such as std::vector that has all of this information.

Regards,

Paul McKenzie

Hmm, that is an interesting question. It is strange that you can't get that information. It's possible that such a function does exist on some of the platforms. Obviously it would have to return an error case or throw an exception for stack arrays.

Anyway, what are you doing that you require the size anyway? You could always create a wrapper class:

Code:

---

template <typename T>
class array{
    public:
          array(size_t size){
                  internal = new _array(size);
          }
          array(const array & orig){
                  internal = orig.internal;
                  ++internal -> refcount;
          }
          ~array(void){
                      deref();
          }
          size_t size() const{
                  return internal -> size();
          }
          T & operator[](size_t pos){
                  CopyOnWrite();
                  return internal -> at(pos)
          }
          const T & operator[](size_t pos) const {
                  return internal -> at(pos);
          }

    private:
          void CopyOnWrite(void){
                  if (internal -> refcount > 1){
                        _array * orig = internal;
                              --orig -> refcount; 
                        internal = new _array(orig -> size());
                       
                        //can't memcopy because these are objects
                        for(unsigned int i = 0; i < size(); ++i){
                                internal -> at(i) = orig -> at(i);
                        }
                  }
          }
          void deref(void){
                      --internal -> refcount;
                      if (!internal -> refcount) delete internal;
          }
          _array * internal;
   
          struct _array {
                  public:
                        _array(size_t _size){
                                mysize = _size;
                                myarray = new T[_size];
                                refcount = 1;
                        }
                        ~_array(void){
                                assert(refcount == 0;)
                                delete[] myarray;
                        }
                        size_t size() const {
                                return mysize;
                        }
                        T & at(size_t pos){
                                assert(pos > size());
                                return myarray[pos]
                        }
                        const T & at(size_t pos) const {
                                assert(pos > size());
                                return myarray[pos];
                        }
                  private:
                        T * myarray;
                        size_t mysize;
                        size_t refcount;
          };
}

---

Wrote it fast, have no idea if it's right, but you get the idea. I wrote a reference counting wrapper around the wrapper because it makes it faster to pass around by value, but you can just use the _array structure if you'd like.

Quote:

---

Originally Posted by ninja9578

Wrote it fast, have no idea if it's right, but you get the idea. Even better, you could wrap another wrapper around this one to do reference counting to make passing it around even faster.

---

Reference counting will not make passing it around even faster, because you cannot really beat the compiler generated copy constructor and copy assignment operator's shallow copying ;)

If you really do want such a class, I suggest that it be named something other than array, and have its constructor declared explicit.

Too late, I edited it with a reference counting. And it's not a shallow copy, there is stuff in the array.

Quote:

---

Originally Posted by ninja9578

Too late, I edited it with a reference counting. And it's not a shallow copy, there is stuff in the array.

---

Ah, but before you added reference counting, it would be mere shallow copying. Now you still have missed out the copy assignment operator.

EDIT:
Yes, I recall something like this in Boost: boost::shared_array.

Ah yes, the copy assignment operator, I always forget to write that one.

Code:

---

array & operator = (const array & orig){
        internal = orig.internal;
        ++internal -> refcount;
        return *this;
}

---

Yes, my original code was using a shallow copy, but then I realized how dumb that was, seeing as the destructor deleted the array and anything that had been shallow copied would become invalid.

Oh, actually, not really. boost::shared_array does not track the size. It would be much better to modify it to do that than to try and come up with something from scratch, off the top of your head.

But what is spelltwister really looking for, anyway?

The point of my code WAS to track the size.

I'm sure that boost:shared_array is very similar to the code that I just wrote.


Anyway, spelltwister, why do you need that size of the array anyway? The common way to pass arrays around is to pass both the size of the array and the pointer itself. This is how almost all C functions that deal with arrays work, and C++ is a superset of C. (sort of, there are some discrepancies, but not many.)

Quote:

---

Originally Posted by ninja9578

The point of my code WAS to track the size.

I'm sure that boost:shared_array is very similar to the code that I just wrote.

---

As you have posted your disclaimer, you know your code is more likely to have bugs (and it does, e.g., the copy assignment operator is not correctly implemented) than boost::shared_array :)

Using a boost::shared_array<T> member with a size_t member for the size will probably eliminate most of that. You can afford to have shallow copying for the size, so you can ignore the copy constructor, copy assignment operator and destructor, and these I think are the most likely places for bugs where reference counting is concerned.

the number of elements is placed in a DWORD 4 bytes before the returned pointer...

so if you would do this..

Code:

---

DWORD * array = new DWORD[5];

---

then this is true:

Code:

---

array[-1] == 5

---

this way it is know to the compiler how many elements are in the array, used only for the constructors and even more the destructors...



note: this is not completely true.. see discussion below.

Quote:

---

Originally Posted by ProgrammerC++

the number of elements is placed in a DWORD 4 bytes before the returned pointer...

---

That is not universally true.

It's not true for g++, I can guarantee you that, at least not on the mac platform. I'm looking at the actually memory right now.

Quote:

---

Originally Posted by laserlight

That is not universally true.

---

It's 100% true for win32 applications (and probably also for 64bit)

Quote:

---

Originally Posted by ProgrammerC++

the number of elements is placed in a DWORD 4 bytes before the returned pointer...

---

It is? So which compiler does it this way?

Nowhere is it stated in ANSI C++ specification how this is implemented. How a compiler implements this is up to the compiler.

Regards,

Paul McKeinzie

Quote:

---

Originally Posted by ProgrammerC++

It's 100&#37; true for win32 applications (and probably also for 64bit)

---

Win32 is not a C++ compiler. There are different compiler brands, and you've tested all of them? Even if you did, there is no guarantee that any compiler implements this in the way you stated. That is what's 100% true.

Regards,

Paul McKenzie

Ok well every standard Visual Studio compiler does it that way.

ofcourse it depends on the compiler, and microsoft again got the smartest way with their compilers ;)

Ok I just checked what I said and what I said only counts when you allocate an array of a class which has a destructor.

So this means the number is only stored for later at the destruction so it knows how many destructors to call

If there's no destructor or its a primitive type then the number of elements is not stored.

Note: I speak for Visual Studio standard compiler

Quote:

---

Originally Posted by ProgrammerC++

Ok well every standard Visual Studio compiler does it that way.

ofcourse it depends on the compiler, and microsoft again got the smartest way with their compilers ;)

---

It is disputed if this is the smartest way (if it's done this way). How would a debugging version of a library detect a memory overwrite if [-1] is a vald location? Or maybe a debugging version uses [-1] as a "guard" location, watching to see if it's overwritten.

Regards,

Paul McKenzie

Without destructor:

Code:

---

#include "stdafx.h"
#include <iostream>
using namespace std;

#define DWORD unsigned int

class ABC
{
public:
        int bla;

        ABC() { cout << "CONSTRUCTOR" << endl; }
};

int _tmain(int argc, _TCHAR* argv[])
{
        cout << sizeof( ABC ) << endl;

        ABC * arr = new ABC[5];

        DWORD * bla = (DWORD *)arr;
        cout << bla[-1] << endl;                // NUMBER MEANS NOTHING

        delete[] arr;

        cin.get();
        return 0;
}

---

Output:

Code:

---

4
CONSTRUCTOR
CONSTRUCTOR
CONSTRUCTOR
CONSTRUCTOR
CONSTRUCTOR
1836896

---

With destructor:

Code:

---

#include "stdafx.h"
#include <iostream>
using namespace std;

#define DWORD unsigned int

class ABC
{
public:
        int bla;

        ABC() { cout << "CONSTRUCTOR" << endl; }
        ~ABC() { cout << "DESTRUCTOR" << endl; }
};

int _tmain(int argc, _TCHAR* argv[])
{
        cout << sizeof( ABC ) << endl;

        ABC * arr = new ABC[5];

        DWORD * bla = (DWORD *)arr;
        cout << bla[-1] << endl;

        delete[] arr;

        cin.get();
        return 0;
}

---

Output:

Code:

---

4
CONSTRUCTOR
CONSTRUCTOR
CONSTRUCTOR
CONSTRUCTOR
CONSTRUCTOR
5
DESTRUCTOR
DESTRUCTOR
DESTRUCTOR
DESTRUCTOR
DESTRUCTOR

---

It's possible that VC++ is only doing that for debugging purposes. VC++ does a lot of weird stuff in debugging mode.

Do all allocation functions do that in VC++? Try malloc.

Still, it's never a good idea to use non-standard practices, especially if it's not a compiler feature. Just because VC++ 6 does one thing doesn't mean that VC++ 7 will.

Also, did you write in *** to be a wildcard, or does VC++ accept that? That is NOT acceptable in any other compiler I've ever seen. If you just meant it to be a wildcard, then foo is the usual nomenclature.

It's done in Release Mode aswell

Well it is logic that when the array is deleted the run-time needs to know how many elements are there so it can loop through it and call destructors.



malloc(int) wont do that because malloc() doesnt call constructors / destructors



(ninja9578: it was *** because I named the class 'W'T'F' which is censored on this forum.. I changed it to ABC just now, I'll use FOO next time :p)

Don't have to call destructors on primitives.

Code:

---

char * array = new char[5];
delete[] array;

---

No dtors.

Also, you don't need to know the number of elements to call of the destructors. You can easily determine that by total_allocated_space / sizeof(element). In fact, the iterating is probably done by using a running pointer, not an index anyway. My guess is that most compilers record the size of the space, not the number of items, because in the end, new[]/delete[] uses malloc / free. free doesn't care how many items is in it, just how many bytes.

You're right, my example shows if there's no destructor, then the number of elements is not stored at all, because it is not needed anyway.

What you say about total_allocated_space etc is correct, but I guess it's faster for the run-time to store the number of elements like the way I said, than to ask the heap handler for the size of the space given a pointer...

Plus there's no such thing as

Code:

---

int GetSizeOfSpace( void * ptr );

---

Quote:

---

Originally Posted by ProgrammerC++

Plus there's no such thing as

Code:

---

int GetSizeOfSpace( void * ptr );

---

---

I never said that there was. But the compiler and/or operating system knows how much space is allocated by ptr.

An int can't tell you how much space anyway, ints aren't big enough is most casts, and a size would certainly be unsigned :P

Yes the compiler know how much space is allocated, that's why the number of elements is stored, but only when an array of a class is allocated of which the class has a destructor, else it won't because it's never needed anyway.

The OS ofcourse knows how much bytes is allocated for a specific pointer, but I guess it's faster for the run-time to store the number of elements this way than to ask the OS how much bytes the size of space is for a specific pointer

Now I'm curious. Put this into your compiler:

Code:

---

DWORD * array = new DWORD[0x1FFFFFFFFUL];
std::cout << array[-1] << std::endl;

---

If I remember correctly, DWORD is only 32 bits, what happens if you go outside of it's range?


Also, don't be so sure that the compiler knows how much space is allocated, it might be asking a runtime library or something.

Quote:

---

Originally Posted by ProgrammerC++

Yes the compiler know how much space is allocated, that's why the number of elements is stored,

---

You think that compiler stores that number?
Try this modified version of your code:

Code:

---

int _tmain(int argc, _TCHAR* argv[])
{
        cout << sizeof( ABC ) << endl;

        ABC * arr = new ABC[argc];

---