== Quote from Petr Janda ([email protected])'s article > Looking at TDPL, placement new can actually take a memory address. > So Im thinking why not do this: > void* mp = alloc!Foo(); // allocate raw memory off the C heap to hold Foo. > Foo* f = new(mp) Foo(); // construct an object in the memory pointed to by mp
It sounds like a fine alternative for construction, except that it can lead to confusion regarding the role of new, which changes drastically depending on whether we pass onto it an address or not. Also, I would prefer if we could avoid explicitly declaring a separate void* pointer. At any rate, it is already an improvement over my clumsy f = Foo(); syntax. Keep in mind that this would probably also be legal code: Foo f = new(alloc!Foo()) Foo(); > and then > clear(f); // call destructor on f, obliterate with Buffer.init and then call > Buffer's default constructor as per TDPL It should be possible with ctor/dtor and alloc/dealloc separation, but in some instances, we should be able to skip the last step of calling the constructor again. Buffer.init is a better state for debugging purposes too. > dealloc(mp); //deallocate memory Again, this would require anybody who wants to manage memory to keep track of two variables per object. Is there a simpler alternative? > We reached the desired removal of delete without breaking TDPL. > Any comments about how possible or not possible it is to do? It all comes together by protecting managed from unmanaged memory in a final analysis. We just need to be sure about how to bring alloc()/dealloc() to the table and how to link construction/destruction to them, without reproducing the C++ new/delete in the process. IMHO, if we are to replace them, make the alternatives even more powerful.
