I have encountered the following code:
class a {
public:
void * operator new(size_t l, int nb);
double values;
};
void *a::operator new (size_t l,int n)
{
return new char[l+ (n>1 ? n - 1 : 0)*sizeof(double)];
}
From what I get it is then used to have an array like structure that start at "values":
double* Val = &(p->a->values) + fColumnNumber;
My question is :
is there a memory leak? I am very new to overloading new operator, but I'm pretty sure that the memory allocated is not deallocated properly. Also does that mean I can never create a "a" class on the stack?
thanks
I believe it technically produces UB as it is, though it's a form of UB that will probably never cause a visible side effect (it's using new [], but I believe that'll get matched up with delete -- but for char, this usually won't cause a visible problem).
IMO, it's almost worse that it's using a new expression to allocate what should really be raw bytes instead of objects. If I were doing it, I'd write it like:
void *a::operator new (size_t l,int n)
{
return ::operator new(l+ (n>1 ? n - 1 : 0)*sizeof(double));
}
You'd match that up with:
void a::operator delete(void *block)
{
::operator delete(block);
}
I don't see why the default operator delete called on an a * wouldn't be able to correctly deallocate the memory allocated by this custom operator new. The best way to check would be to actually write some code and find out, although rather than rob05c's technique I'd probably run it in a profiler such as valgrind. I assume the questioner sees a memory leak happening and suspects this as the cause, so writing a test case around this operator seems like a worthwhile endeavour.
Obviously it will leak if nobody gets around to actually deleting it afterwards...
I'd question the necessity of overriding new for this kind of functionality, but I also assume this was somebody else's code.
It's fairly easy to find out. Write a loop that constructs and deconstructs lots of a's, and watch your memory usage. It'll go up pretty fast if it's leaking.
Its fine as it is, but you'd need to use delete[], not delete, from the code that uses this class as it allocates an array. Note that the user wouldn't get any hints that they need to do this - so overloading a delete operator for them would be a good idea.
You can definitely create Class "a" on the stack.
There are 4 (actually more but will stick with the basics) new & delete method signatures you should know.
void* operator new (std::size_t size) throw (std::bad_alloc);
void* operator new[] (std::size_t size) throw (std::bad_alloc);
void operator delete (void* ptr) throw ();
void operator delete[] (void* ptr) throw ();
You are allocating an array within the "operator new" method which should be done in the "operator new[]" method. This will get rid of your nasty check. Write both, "operator new" and "operator new[]"
Don't forget you want to give the caller an object of type "a" ( a myA = new a) so make sure you return "a" not char*, therefore you need to also be casting.
You need to write the corresponding delete[] and delete methods.
To answer your question, I believe it does leak memory. The new signature you've provided is called the "placement new". This allows you to allocate a new pointer without allocating memory but to give it a location to point to. Example: If you needed a pointer to a specific point in memory.
long z = 0x0F9877F80078;
a myA = new (z) a[5]; // 5 pointers that point to 0x0F9877F80078
By definition the placement-new operator is not supposed to allocate memory and since you have you make be leaking. Get rid of your second argument, which you can do now since you have 2 versions of operator new and you're good to go. Don't forget to return an object "a".
Check out IBM's Info Center:
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr318.htm
And the reference or references, cpluplus.com:
http://www.cplusplus.com/reference/std/new
Related
Assuming I'm using a struct to be allocated on heap and used as
new [] and delete[]
shared_ptr(new [])
then can I simply overload its new array operator and don't touch any delete [] operator
struct alignas(256) MyStruct
{
Item i1,i2;
void * operator new[](unsigned long int size)
{
return aligned_alloc(256,size);
}
void * operator new (unsigned long int size)
{
return aligned_alloc(256,size);
}
};
and consider it done without any leaks?
GCC 6.3 and c++0x.
The truth is, there is no guarantee on how your standard library implements those operator new() functions, whatsoever. Your standard implementation might just call through to malloc() and free(), but it's not required to do so. It may just as well use the sbreak() syscall itself to back the memory objects it manages. Or it could use the mmap() syscall.
Either of these three is perfectly possible, and incompatible with the other two implementations. And, just as bad, your standard operator delete() implementation may consult some hidden data fields in front of the pointer that you pass into it to perform its internal bookkeeping. If the pointer that is passed into your standard operator delete() is not actually a pointer that was returned by the matching operator new(), you have undefined behavior. And the probability of something really bad happening is very high.
There is really no way around it: If you supply operator new(), you must also supply operator delete(). Otherwise, all hell may break loose.
If you overload new on a object, you should overload delete as well. Likewise, if you overload new[], you should overload delete[]. This is because the object will use the default delete, which may lead to a crash, depending on how you've messed with new.
Depending on your compiler, delete may call free() anyway, but you should get into the habit of overloading both new and delete, especially if you change how your object gets allocated.
In his new book TC++PL4, Stroustrup casts a slightly different light on a once usual practice regarding user-controlled memory allocation and placement new—or, more specifically, regarding the enigmatical "placement delete." In the book's sect. 11.2.4, Stroustrup writes:
The "placement delete" operators do nothing except possibly inform a garbage collector that the deleted pointer is no longer safely derived.
This implies that sound programming practice will follow an explicit call to a destructor by a call to placement delete.
Fair enough. However, is there no better syntax to call placement delete than the obscure
::operator delete(p);
The reason I ask is that Stroustrup's sect. 11.2.4 mentions no such odd syntax. Indeed, Stroustrup does not dwell on the matter; he mentions no syntax at all. I vaguely dislike the look of ::operator, which interjects the matter of namespace resolution into something that properly has nothing especially to do with namespaces. Does no more elegant syntax exist?
For reference, here is Stroustrup's quote in fuller context:
By default, operator new creates its object on the free store. What
if we wanted the object allocated elsewhere?... We can place objects
anywhere by providing an allocator function with extra arguments and
then supplying such extra arguments when using new:
void* operator new(size_t, void* p) { return p; }
void buf = reinterpret_cast<void*>(0xF00F);
X* p2 = new(buf) X;
Because of this usage, the new(buf) X syntax for supplying extra
arguments to operator new() is known as the placement syntax.
Note that every operator new() takes a size as its first argument
and that the size of the object allocated is implicitly supplied.
The operator new() used by the new operator is chosen by the
usual argument-matching rules; every operator new() has
a size_t as its first argument.
The "placement" operator new() is the simplest such allocator. It
is defined in the standard header <new>:
void* operator new (size_t, void* p) noexcept;
void* operator new[](size_t, void* p) noexcept;
void* operator delete (void* p, void*) noexcept; // if (p) make *p invalid
void* operator delete[](void* p, void*) noexcept;
The "placement delete" operators do nothing except possibly inform a
garbage collector that the deleted pointer is no longer safely
derived.
Stroustrup then continues to discuss the use of placement new with arenas. He does not seem to mention placement delete again.
If you don't want to use ::, you don't really have to. In fact, you generally shouldn't (don't want to).
You can provide replacements for ::operator new and ::operator delete (and the array variants, though you should never use them).
You can also, however, overload operator new and operator delete for a class (and yes, again, you can do the array variants, but still shouldn't ever use them).
Using something like void *x = ::operator new(some_size); forces the allocation to go directly to the global operator new instead of using a class specific one (if it exists). Generally, of course, you want to use the class specific one if it exists (and the global one if it doesn't). That's exactly what you get from using void *x = operator new(some_size); (i.e., no scope resolution operator).
As always, you need to ensure that your news and deletes match, so you should only use ::operator delete to delete the memory when/if you used ::operator new to allocate it. Most of the time you shouldn't use :: on either one.
The primary exception to that is when/if you're actually writing an operator new and operator delete for some class. These will typically call ::operator new to get a big chunk of memory, then divvy that up into object-sized pieces. To allocate that big chunk of memory, it typically (always?) has to explicitly specify ::operator new because otherwise it would end up calling itself to allocate it. Obviously, if it specifies ::operator new when it allocates the data, it also needs to specify ::operator delete to match.
First of all: No there isn't.
But what is the type of memory? Exactly, it doesn't have one. So why not just use the following:
typedef unsigned char byte;
byte *buffer = new byte[SIZE];
Object *obj1 = new (buffer) Object;
Object *obj2 = new (buffer + sizeof(Object)) Object;
...
obj1->~Object();
obj2->~Object();
delete[] buffer;
This way you don't have to worry about placement delete at all. Just wrap the whole thing in a class called Buffer and there you go.
EDIT
I thought about your question and tried a lot of things out but I found no occasion for what you call placement delete. When you take a look into the <new> header you'll see this function is empty. I'd say it's just there for the sake of completeness. Even when using templates you're able to call the destructor manually, you know?
class Buffer
{
private:
size_t size, pos;
byte *memory;
public:
Buffer(size_t size) : size(size), pos(0), memory(new byte[size]) {}
~Buffer()
{
delete[] memory;
}
template<class T>
T* create()
{
if(pos + sizeof(T) > size) return NULL;
T *obj = new (memory + pos) T;
pos += sizeof(T);
return obj;
}
template<class T>
void destroy(T *obj)
{
if(obj) obj->~T(); //no need for placement delete here
}
};
int main()
{
Buffer buffer(1024 * 1024);
HeavyA *aObj = buffer.create<HeavyA>();
HeavyB *bObj = buffer.create<HeavyB>();
if(aObj && bObj)
{
...
}
buffer.destroy(aObj);
buffer.destroy(bObj);
}
This class is just an arena (what Stroustrup calls it). You can use it when you have to allocate many objects and don't want the overhead of calling new everytime. IMHO this is the only use case for a placement new/delete.
This implies that sound programming practice will follow an explicit call to a destructor by a call to placement delete.
No it doesn't. IIUC Stroustrup does not mean placement delete is necessary to inform the garbage collector that memory is no longer in use, he means it doesn't do anything apart from that. All deallocation functions can tell a garbage colector memory is no longer used, but when using placement new to manage memory yourself, why would you want a garbage collector to fiddle with that memory anyway?
I vaguely dislike the look of ::operator, which interjects the matter of namespace resolution into something that properly has nothing especially to do with namespaces.
"Properly" it does have to do with namespaces, qualifying it to refer to the "global operator new" distinguishes it from any overloaded operator new for class types.
Does no more elegant syntax exist?
You probably don't ever want to call it. A placement delete operator will be called by the compiler if you use placement new and the constructor throws an exception. Since there is no memory to deallocate (because the pacement new didn't allocate any) all it does it potentially mark the memory as unused.
I can override global operator new with different parameters, so for example I can have:
void* operator new (std::size_t size) throw (std::bad_alloc);
void* operator new (std::size_t size, int num) throw (std::bad_alloc);
which can be called separately as
int* p1 = new int; // calls new(size_t)
int* p2 = new(5) int; // calls new(size_t, int)
since each of these can potentially use some different allocation scheme, I would need a separate delete() function for each. However, delete(void*) cannot be overloaded in the same way! delete(void*) is the only valid signature. So how can the above case be handled?
P.S. I am not suggesting this is a good idea. This kind of thing happened to me and so I discovered this "flaw" (at least in my opinion) in c++. If the language allows the new overrides, it must allow the delete overrides, or it becomes useless. And so I was wondering if there is a way around this, not if this a good idea.
I can override global operator new with different parameters
Those are called placement allocation functions.
delete(void*) is the only valid signature.
No.
First, some terminology: A delete expression such as delete p is not just a function call, it invokes the destructor then calls a deallocation function, which is some overload of operator delete that is chosen by overload resolution.
You can override operator delete with signatures to match your placement allocation function, but that overload will only be used if the constructor called by the placement new expression throws an exception e.g.
struct E {
E() { throw 1; }
};
void* operator new(std::size_t n, int) throw(std::bad_alloc) { return new char[n]; }
void operator delete(void* p, int) { std::puts("hello!"); delete[] (char*)p; }
int main()
{
try {
new (1) E;
} catch (...) {
puts("caught");
}
}
The placement deallocation function which matches the form of placement new expression used (in this case it has an int parameter) is found by overload resolution and called to deallocate the storage.
So you can provide "placement delete" functions, you just can't call them explicitly. It's up to you to remember how you allocated an object and ensure you use the corresponding deallocation.
If you keep track of the different memory regions you allocate with your different new overloads, you can tag them with the version of new that was called.
Then at delete time you can look the address up to find which new was called, and do something different in each case.
This way you can guarantee that the correct logic is automatically associated with each different new overload.
As pointed out by baruch in the comments below, there is a performance overhead associated with the maintenance of the data you use for tracking, and this logic will also only work as long as the overloaded delete is not passed anything allocated using the default delete.
As far as tracking overhead, it seems to me that the minimum overhead method of tracking the type of the allocation is to allocate the amount requested, plus a small amount of additional space at the start of the allocated region in which to tag the request type (sized according to conservative alignment requirements). You can then look at this tag region on delete to determine which logic to follow.
There is a placement delete which matches the placement operator new. And you can't call it directly. This is because the placement delete is only used to deallocate memory when the constructor of the new'ed object throws.
void *operator new(size_t, Area&); // placement new
void operator delete(void*, Area&); // matching placement delete
...
Area &area;
SomeType *t=new(area) SomeType();
// when SomeType() throws then `delete(t,area)` from above is called
// but you can't do this:
delete (area) t;
A common way to overcome this, is to use write an overloaded "destroy" function, which accepts all kinds of parameters.
template<class T> void destroy(Area &a, T* &pt) //<-you can't do this with 'delete'
{
if (pt) {
pt->~T(); // run the destructor
a.freeMem(pt); // deallocate the object
pt=NULL; // nulls the pointer on the caller side.
}
}
The simple answer is: Do not do this. All forms of non-placement new are redundant in C++11 and horrifically unsafe, for example, return raw pointer. If you want to allocate objects in a custom place, then use a class with an allocate function if stateful or a free function if not. The best treatment for new and indeed, delete, is to excise them from your program with prejudice, with the possible exception of placement new.
Edit: The reason why it's useless for you is because you're trying to use it for a purpose which it was not intended for. All you can use the extra params for is stuff like logging or other behaviour control. You can't really change the fundamental semantics of new and delete. If you need stateful allocation, you must use a class.
You're wrong. It is possible to provide a placement delete.
I have written a simple function as following:
void *operator new(size_t size) throw(std::bad_alloc)
{
void *p;
p = malloc(size);
if(!p)
throw bad_alloc();
return p;
}
What else can i do to improve this? Would malloc be more effective than new? If I want to write new[] do I only need to change just the function signature?
This code will work the way it is, but if you do this, you pretty much need to write a matching ::operator delete that will work with it:
void operator delete(void *block) throw() {
::free(block);
}
Personally, I'd probably modify your code to something more like:
void *operator new(size_t size) throw(std::bad_alloc)
{
void *p = malloc(size);
if(!p)
throw bad_alloc();
return p;
}
I prefer to initialize everything I can, rather than create an uninitialized variable, and only later assign a value to it. In this case, the difference is pretty minor, but I consider it a habit worth cultivating.
As far as being more effective than the default implementation of operator new, I'd say chances are that no, it won't be more effective, and might well be less effective. What you've provided is basically how many standard libraries were implemented toward the dawn of C++, but since then, many (most?) have done more work on their implementation of ::operator new to tailor it more closely to how dynamically allocated memory tends to be used in C++ (where malloc is mostly oriented toward how it's used in C, which is typically at least a little different).
As far as new[] goes, yes, it's just a change of function signature. Despite being used for single vs. multiple allocations, the requirements on operator new and operator new[]` are identical.
If you replace global operator new you also should replace the nothrow variant. And, of course, global operator delete (both the normal and nothrow variant, because if the constructor of the object throws, the nothrow variant of operator delete is called for nothrow operator new).
I guess in most implementations the built-in operator new looks more or less exactly like your replacement. Anyway, in general I'd not expect that you can beat the internal implementation of operator new.
operator new is responsible for allocating the underlying memory of an object. Some applications use other allocation schemes than malloc to allocate memory. One example is pool allocation: The application requests a large amount of memory from the operating system and manages how that memory itself. This can safe the overhead of a system call, prevent fragmentation or provide time guarantees for memory allocation that the operating system usually wont.
If you don't know if this could improve the performance of your program, it probably does not matter for you.
I came across this kind of code once in a while - I suspect the creator is/was afraid that table delete would iterate over the table and "cost performance" (which imho will not be done either way)... is there any real benefit one might get/consider/imagine from not using the the table delete here?
myClass** table = new myClass* [size];
... //some code that does not reallocate or change the value of the table pointer ;)
delete table; // no [] intentionally
If you do this, you will get what the C++ Standard calls undefined behaviour - anything could happen.
That is a memory leak. A new [] must be matched by a delete []. Further, since table is a pointer to the first element of an array of pointers, any array member, if it's an array by itself will need to be de-allocated using a delete [].
Not only is there no benefit, the code is just plain wrong -- at best, it leaks memory, and at worst, it can crash your program or open up a hard-to-find security hole. You must always match new with delete and new[] with delete[]. Always.
There's really no reason to write like that and a serious reason to never do so.
It's true that for types with trivial destructors (like raw pointers in your case) there's no need to know the actual number of elements in the array and so the compiler might decide to map new[] and delete[] onto new and delete to reduce the overhead. If it decides this way you can't stop it without extra steps taken, so this compiler optimization will take place without your notice and will be free.
At the same time someone using your code might wish to overload the global operators new and delete (and new[] and delete[] as well). If that happens you run into big trouble because this is when you may really need the difference between the delete and delete[].
Add to this that this compiler-dependent optimization is unportable.
So this is the case when you get no benefits displacing delete[] with delete but risk big time relying into undefined behaviour.
It's definitely wrong as a s new[] needs to be paired with delete[]. If you don't you will get undefined behavior.
It may work (partially), because most implementations use new to implement new[]. The only difference for such an implementation would be that it would only call 1 destructor (for the first element instead of all destructors. But avoid it as it is not legal c++.
In theory you should call delete [].
EDIT: The following applies only to Microsoft Visual C++ (I should have said this).
In practice, in Microsoft Visual C++ , it doesn't matter which delete you use when the objects in the array don't have destructors. Since you have an array of pointers, and pointers can't have destructors, you should be OK.
However, as others have pointed out, it is incorrect C++ to mix new [] and delete without []. Although it may work in Visual C++ in this case, the code is not portable and may fail in other compilers.
But going back to the specific case of Visual C++, even if you call delete [], the compiler will realize that it doesn't need to iterate through the array calling destructors when it's an array of primitive types like int, char, or pointers. Calling delete in that case actually works and won't break anything. It would not be slower to do the right thing and call delete [], but it won't be faster either.
In fact, in MSVC++, delete[] p immediately calls the regular operator delete(void *p) when p is a pointer to a simple type, or one without destructors.
Those who don't believe me, step through this code into the CRT code for the first two calls to delete[].
#include "stdafx.h"
#include <malloc.h>
#include <iostream>
using namespace std;
class NoDestructor
{
int m_i;
};
class WithDestructor
{
public:
~WithDestructor()
{
cout << "deleted one WithDestructor at " << (void *) this<< endl;
}
};
int _tmain(int argc, _TCHAR* argv[])
{
int **p = new int *[20];
delete [] p;
p = (int**) malloc(80);
free(p);
NoDestructor *pa = new NoDestructor[20];
delete [] pa;
WithDestructor *pb = new WithDestructor[20];
delete [] pb;
return 0;
}
that statement will leave all of the myClass objects that were pointed to by all the pointers in the array hanging around in memory. It also leaves the array of pointers in memory. There is no way that can be helpful, as it only frees up 32 bits of memory, and the OS still thinks you have (size) myClasses and pointers to each in use. This is just an example of a programmer not cleaning up after themself properly.
Check with the section [16.11] "How do I allocate / unallocate an array of things?" and beyond in C++ FAQ Lite,
http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.11
They explain that the array delete is a must when an array is created.
The instanced of myClass pointed to by the elements of your array should also be deleted where they are created.