delete[] mechanics

[laserlight]

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?

[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.


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.)

[laserlight]

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.

[ProgrammerC++]

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

so if you would do this..

DWORD * array = new DWORD[5];

then this is true:

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.

[laserlight]

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

That is not universally true.

[ninja9578]

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.

[ProgrammerC++]

That is not universally true.

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

[Paul McKenzie]

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

[Paul McKenzie]

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

[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

[ProgrammerC++]

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

[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

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

[ProgrammerC++]

Without destructor:

#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:

4
CONSTRUCTOR
CONSTRUCTOR
CONSTRUCTOR
CONSTRUCTOR
CONSTRUCTOR
1836896

With destructor:

#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:

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

[ninja9578]

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.

[ProgrammerC++]

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 )