Back to General and Gameplay Programming

Fun With C++ [Beginners Stay Away, Lest Ye Be Corrupted]

John Vidziunas · 2010-03-12T08:39:35

Have more time off today, and decided I'd test an interesting little idiom out to help with const-correctness. It turns out you can actually do a lot of neat (and admittedly very dangerous) tricks with placement new, up to and including re-instantiating objects using the this pointer. As far as I can tell, there do not appear to be any adverse effects so long as the idiom itself is used correctly; since we're using the this pointer from an already-constructed object we're guaranteed to have proper alignment and size and recreating the object in this fashion doesn't appear to muck up any lifetimes, etc. Code: main.cpp #include "SomeClass.h" #include <iostream> int main() { { SomeClass stackClass; stackClass.ReInstantiate(); stackClass.WriteSomeData(); } std::cout << "---" << std::endl; SomeClass* heapPtr = new SomeClass(); heapPtr->ReInstantiate(); heapPtr->WriteSomeData(); delete heapPtr; int i; std::cin >> i; return 0; } SomeClass.h: #pragma once class SomeClass { public: SomeClass(); virtual ~SomeClass(); void ReInstantiate(); void WriteSomeData(); private: char* const dataChunk; const unsigned long moreData; const bool evenMoreData; }; SomeClass.cpp: #include "SomeClass.h" #include <memory> #include <iostream> SomeClass::SomeClass() : dataChunk(new char[32]), moreData(0), evenMoreData(true) { std::cout << "SomeClass()" << std::endl; } SomeClass::~SomeClass() { std::cout << "~SomeClass()" << std::endl; if(dataChunk) delete[] dataChunk; } void SomeClass::WriteSomeData() { std::cout << "WriteSomeData()" << std::endl; for( size_t i = 0; i < 32; i++ ) { dataChunk = '3'; } } void SomeClass::ReInstantiate() { std::cout << "ReInstantiate()" << std::endl; //void* thisPtr = this; this->~SomeClass(); new(this) SomeClass; } I would appreciate if someone could test this on something other than MSVC9 (VS2008) to see what happens. No guarantees if it's actually even practical or actually works elsewhere, it just seems interesting.

General and Gameplay Programming Programming

Started by InvalidPointer March 09, 2010 11:06 AM

30 comments, last by SiCrane 14 years, 1 month ago

visitor

643

March 11, 2010 04:40 AM

Placement new and explicit destructor calls naturally do have a place, but even boost::variant doesn't do it with itself.

Quote:
It allows a reasonable copy constructor/assignment operator to be defined for classes with const member variables (and reference member variables).

For const members you could use a const_cast (which should show how fishy the idea is conceptually) and for reseatable reference members you could use pointers.

DevFred

840

March 11, 2010 08:41 AM

What's the point of making a member const if you intend to modify it? That's like making something private and complain that it isn't public...

SiCrane

11,840

March 11, 2010 10:19 AM

Quote:Original post by cache_hit
I haven't actually looked at the source code, but it sure sounds to me like they're doing this.

I have and they don't.

Nitage

1,107

March 11, 2010 02:29 PM

Quote:For const members you could use a const_cast (which should show how fishy the idea is conceptually) and for reseatable reference members you could use pointers.

Yes, you could - and you probably should. I was just suggesting why some people think this is a good idea.

Quote:I don't believe any good ever comes from using the object rebirth techinque.

But isn't it the technique that std::vector uses to seperate construction/destruction from allocation/dealloaction?

Object rebirth:
aVector.pop_back();
aVector.push_back(my_struct());

SiCrane

11,840

March 11, 2010 02:47 PM

Quote:Original post by Nitage
But isn't it the technique that std::vector uses to seperate construction/destruction from allocation/dealloaction?

No, when you call pop_back() it invalidates all iterators, pointers and references to the last element. If you follow a pop_back() with a push_back() those are two different objects. And more importantly, std:vector doesn't destroy itself just to recreate itself in the same location.

cache_hit

614

March 11, 2010 04:30 PM

Kind of a minor distinction IMO. if you agree it's ok and there are legitimate use cases for manually invoking destructors of owned objects, and you agree that it's ok to write 'delete this', indicating that an object owns itself, then i dont see why this is anything other than a natural extension. Granted, a natural extension that you likely will never need, but its no stranger to me than "delete this"

SiCrane

11,840

March 11, 2010 04:38 PM

Quote:Original post by cache_hit
Kind of a minor distinction IMO.

What is?

cache_hit

614

March 11, 2010 05:00 PM

Manual destruction / in-place construction of yourself as opposed to some arbitrary child you claim ownership of. Either way if ownership semantics are well defined, i think this is no stranger than delete this, albeit maybe a little more rare as far as use cases are concerned

visitor

643

March 12, 2010 01:46 AM

Quote:
Kind of a minor distinction IMO. if you agree it's ok and there are legitimate use cases for manually invoking destructors of owned objects, and you agree that it's ok to write 'delete this', indicating that an object owns itself, then i dont see why this is anything other than a natural extension.

I suppose the difference is that in one case you'd be doing it with an automatic object and therefore you must at any cost succeed in replacing this. You can't avoid the destructor being called on the object.

When you do it with an owned object (as vector and variant do), those wouldn't be destroyed automatically when the owner goes out of scope. They were explicitly created and have to be explicitly destroyed (and you can easily omit the last step if you lost the object in the meantime).

delete this also wouldn't be done on an automatic object.

-------

Go ahead and use with objects whose construction cannot fail. But still there might be a better use case than just hiding const_cast, and reseating references.

cache_hit

614

March 12, 2010 01:52 AM

Quote:Original post by visitor
Go ahead and use with objects whose construction cannot fail.

You can even enable such logic at compile-time by using meta-programming magic to detect if a class has a nothrow constructor, in which case performing the operation actually would support a stronger exception guarantee.

Fun With C++ [Beginners Stay Away, Lest Ye Be Corrupted]

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Fun With C++ [Beginners Stay Away, Lest Ye Be Corrupted]

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines