Suppose we have a situation like this. Suppose instead of "p = &global;" we called some function(written by someone which invalidate our pointer). How to handle this problem? How to protect code from crashes? I know about and use boost smart pointers. But what to do if we have this situation.
struct Test
{
int a;
int b;
int c;
};
Test global;
int main()
{
Test *p = new Test;
p->a = 1;
p->b = 2;
p->c = 3;
p = &global;
delete p;
return 0;
}
You handle it by fixing the bug and recompiling your program. Anything else makes no sense.
You can't and you shouldn't try to deal with this situation other then not letting it occur in the first place.
There are some basic rules in C++ that simply have to be obeyed.
Nothing. If you do this, then you get what you get. Don't do this.
Once you reassign p, you leak the Test object that p originally pointed at. You've now lost that memory for the duration of this app's runtime. Then when you delete a non-heap object, you're running into undefined behaviour and anything at all can happen (usually the runtime library will crash trying to delete non-heap memory - but you have no guarantees). There's absolutely nothing reliable that you can do once you've tried to delete non-heap memory.
You've already mentioned smart pointers, which is part of the solution. The other part is just being careful.
Unfortunately there's nothing you can do. The C++ compiler can't tell from your code whether or not you might delete a pointer in the future, so you have to be sure to manage them correctly in your code. This means that if you put the address of a non-heap-allocated item into a pointer, it's your responsibility nto to delete that pointer.
In short, C++ can't protect you from every possible mistake you can write.
You can use the code below to find out if a pointer points to a stack area or heap area:
bool IsMemoryOnStack( void* p )
{
void* dwStackTop = 0;
void* dwStackLowCurrent = 0;
__asm {
mov EAX, FS:[4]
mov dwStackTop, eax
mov EAX, FS:[8]
mov dwStackLowCurrent, eax
}
return ( p<= dwStackTop && p>= dwStackLowCurrent );
}
You need to swap the assignment and delete statements:
delete p;
p = &global;
BUT I would suggest never using the same variable to point at data that requires an explicit free and data that does not. Pick one or the other for each variable, so you can either always delete the memory before reassigning it or never delete it. If you try to keep track of how you're pointers got set, you'll wind up spending all your time whining about how C++ provides no memory management and forces you to write unmaintainable code.
The primary way to avoid this is to simply avoid using new or delete under any but the most tightly controlled circumstances.
Using new inside of main is particularly suspect -- the reason to use new in C++ is when you need to create an object that needs to outlive the scope in which it's being created (e.g., when you reach the end of that function, it must not be destroyed). In the case of main, the only reason to do what would be if you were allocating something in main that would not be deleted in main, but used by some the destructor of some global object as it ran after you returned from main (which is rarely done and even more rarely a good idea).
Most uses of new should be in the ctor of an object, and most uses of delete should be in the dtor of an object. If you have something like a collection, it can also make sense to use new and/or delete in some other member function(s) that handle(s) things like re-sizing the collection.
Other than that, there are entity objects that generally aren't ever assigned or copied. For example, consider a call routing system, where you create a "call" object when somebody dials their phone, and you destroy the object when they hang up. In nearly every such case, you have a global collection (or more than one) that holds pointers to these objects, so as soon as you create the object, its address goes into the (correct) global collection. Interesting point: nearly all code that I've seen where this pattern made sense did not have any external code that destroyed the object -- rather, the object itself was responsible for removing itself from the global connection, and using the (much argued-about) delete this; to destroy itself when the real-world connection (or whatever) it was attached to ended.
It is possible to overload delete. In theory you could have your overloaded delete refuse to do anything unless the address is valid. But how do you know if it's valid? The best you can say is "this wasn't allocated with new," but you'll probably have to overload new to do that.
For the record, the standard new and delete crash in this case because delete determines the address didn't come from new and assumes the worst. Assuming the worst is probably the best thing to do in that situation, though; at least it beats assuming the best.
So I'll second the advice to not protect against this in code, and simply don't do that.
Related
I have seen the following construction in many code reviews:
ClassX *pObj;
ClassX obj;
pObj = &obj; //obj is not used in the rest of the code
Is the line below only used for initialization purposes?
pObj = &obj;
Why is it not initialized to NULL?
pObj = &obj; here pObj is pointer and it is pointing to obj.
Like below,
Note: Only for illustration purpose I have chosen address of obj,pObj as 0x1000,0x2000 respectively.
Why they do not initialize to NULL.
pObj can be initialized to NULL but eventually overwritten by pObj = &obj and hence no side effect occurs. But access to pObj before assignment causes UB.
pObj is a pointer to a properly initialised instance that can be used by the rest of the function or any called functions. NULL would mean there is no instance, a very different thing.
But why would you do this? One answer is that the rest of the code uses pointers and the author feels happier using pObj than using &obj.
Another may be that the pointer later gets assigned to a real object "usually". You didn't show us the later code so we have to speculate (or downvote). Perhaps the author thinks that having a valid temporary is less prone to crashes than having a null ptr if the assignment fails and the later code that uses the pointer is allowed to run, but this really is lazy programming, paying to initialise an object you never intend to use. If the real object is dynamically allocated, then the pointer might be valid outside the scope of this code, but the default instance would not be.
Sometimes construction/copy/move of objects is costly or impossible; thus pointer ClassX* pObj; can serve as a tool to quickly change target - as copying pointers is simple and cheap overall.
Say, in a loop pObj is frequently used and sometimes you need it to point to one object, then to another, and carryover it to next iterations. Or you have some complex rules that determine to which variable the pointer points to.
If one could've simply used obj instead of the pObj in the method without any issues - then it is simply poor coding practices to use pObj. Some might use it to save & when passing pointers... but that's barely an excuse. Regardless, I don't see much harm except for clutter.
Or they simply copied the code from elsewhere (that was also copied from another place...) without dwelling on it much as to why it is written in this way.
Is it allowed to delete this; if the delete-statement is the last statement that will be executed on that instance of the class? Of course I'm sure that the object represented by the this-pointer is newly-created.
I'm thinking about something like this:
void SomeModule::doStuff()
{
// in the controller, "this" object of SomeModule is the "current module"
// now, if I want to switch over to a new Module, eg:
controller->setWorkingModule(new OtherModule());
// since the new "OtherModule" object will take the lead,
// I want to get rid of this "SomeModule" object:
delete this;
}
Can I do this?
The C++ FAQ Lite has a entry specifically for this
https://isocpp.org/wiki/faq/freestore-mgmt#delete-this
I think this quote sums it up nicely
As long as you're careful, it's OK for an object to commit suicide (delete this).
Yes, delete this; has defined results, as long as (as you've noted) you assure the object was allocated dynamically, and (of course) never attempt to use the object after it's destroyed. Over the years, many questions have been asked about what the standard says specifically about delete this;, as opposed to deleting some other pointer. The answer to that is fairly short and simple: it doesn't say much of anything. It just says that delete's operand must be an expression that designates a pointer to an object, or an array of objects. It goes into quite a bit of detail about things like how it figures out what (if any) deallocation function to call to release the memory, but the entire section on delete (§[expr.delete]) doesn't mention delete this; specifically at all. The section on destructors does mention delete this in one place (§[class.dtor]/13):
At the point of definition of a virtual destructor (including an implicit definition (15.8)), the non-array deallocation function is determined as if for the expression delete this appearing in a non-virtual destructor of the destructor’s class (see 8.3.5).
That tends to support the idea that the standard considers delete this; to be valid -- if it was invalid, its type wouldn't be meaningful. That's the only place the standard mentions delete this; at all, as far as I know.
Anyway, some consider delete this a nasty hack, and tell anybody who will listen that it should be avoided. One commonly cited problem is the difficulty of ensuring that objects of the class are only ever allocated dynamically. Others consider it a perfectly reasonable idiom, and use it all the time. Personally, I'm somewhere in the middle: I rarely use it, but don't hesitate to do so when it seems to be the right tool for the job.
The primary time you use this technique is with an object that has a life that's almost entirely its own. One example James Kanze has cited was a billing/tracking system he worked on for a phone company. When you start to make a phone call, something takes note of that and creates a phone_call object. From that point onward, the phone_call object handles the details of the phone call (making a connection when you dial, adding an entry to the database to say when the call started, possibly connect more people if you do a conference call, etc.) When the last people on the call hang up, the phone_call object does its final book-keeping (e.g., adds an entry to the database to say when you hung up, so they can compute how long your call was) and then destroys itself. The lifetime of the phone_call object is based on when the first person starts the call and when the last people leave the call -- from the viewpoint of the rest of the system, it's basically entirely arbitrary, so you can't tie it to any lexical scope in the code, or anything on that order.
For anybody who might care about how dependable this kind of coding can be: if you make a phone call to, from, or through almost any part of Europe, there's a pretty good chance that it's being handled (at least in part) by code that does exactly this.
If it scares you, there's a perfectly legal hack:
void myclass::delete_me()
{
std::unique_ptr<myclass> bye_bye(this);
}
I think delete this is idiomatic C++ though, and I only present this as a curiosity.
There is a case where this construct is actually useful - you can delete the object after throwing an exception that needs member data from the object. The object remains valid until after the throw takes place.
void myclass::throw_error()
{
std::unique_ptr<myclass> bye_bye(this);
throw std::runtime_exception(this->error_msg);
}
Note: if you're using a compiler older than C++11 you can use std::auto_ptr instead of std::unique_ptr, it will do the same thing.
One of the reasons that C++ was designed was to make it easy to reuse code. In general, C++ should be written so that it works whether the class is instantiated on the heap, in an array, or on the stack. "Delete this" is a very bad coding practice because it will only work if a single instance is defined on the heap; and there had better not be another delete statement, which is typically used by most developers to clean up the heap. Doing this also assumes that no maintenance programmer in the future will cure a falsely perceived memory leak by adding a delete statement.
Even if you know in advance that your current plan is to only allocate a single instance on the heap, what if some happy-go-lucky developer comes along in the future and decides to create an instance on the stack? Or, what if he cuts and pastes certain portions of the class to a new class that he intends to use on the stack? When the code reaches "delete this" it will go off and delete it, but then when the object goes out of scope, it will call the destructor. The destructor will then try to delete it again and then you are hosed. In the past, doing something like this would screw up not only the program but the operating system and the computer would need to be rebooted. In any case, this is highly NOT recommended and should almost always be avoided. I would have to be desperate, seriously plastered, or really hate the company I worked for to write code that did this.
It is allowed (just do not use the object after that), but I wouldn't write such code on practice. I think that delete this should appear only in functions that called release or Release and looks like: void release() { ref--; if (ref<1) delete this; }.
Well, in Component Object Model (COM) delete this construction can be a part of Release method that is called whenever you want to release aquisited object:
void IMyInterface::Release()
{
--instanceCount;
if(instanceCount == 0)
delete this;
}
This is the core idiom for reference-counted objects.
Reference-counting is a strong form of deterministic garbage collection- it ensures objects manage their OWN lifetime instead of relying on 'smart' pointers, etc. to do it for them. The underlying object is only ever accessed via "Reference" smart pointers, designed so that the pointers increment and decrement a member integer (the reference count) in the actual object.
When the last reference drops off the stack or is deleted, the reference count will go to zero. Your object's default behavior will then be a call to "delete this" to garbage collect- the libraries I write provide a protected virtual "CountIsZero" call in the base class so that you can override this behavior for things like caching.
The key to making this safe is not allowing users access to the CONSTRUCTOR of the object in question (make it protected), but instead making them call some static member- the FACTORY- like "static Reference CreateT(...)". That way you KNOW for sure that they're always built with ordinary "new" and that no raw pointer is ever available, so "delete this" won't ever blow up.
You can do so. However, you can't assign to this. Thus the reason you state for doing this, "I want to change the view," seems very questionable. The better method, in my opinion, would be for the object that holds the view to replace that view.
Of course, you're using RAII objects and so you don't actually need to call delete at all...right?
This is an old, answered, question, but #Alexandre asked "Why would anyone want to do this?", and I thought that I might provide an example usage that I am considering this afternoon.
Legacy code. Uses naked pointers Obj*obj with a delete obj at the end.
Unfortunately I need sometimes, not often, to keep the object alive longer.
I am considering making it a reference counted smart pointer. But there would be lots of code to change, if I was to use ref_cnt_ptr<Obj> everywhere. And if you mix naked Obj* and ref_cnt_ptr, you can get the object implicitly deleted when the last ref_cnt_ptr goes away, even though there are Obj* still alive.
So I am thinking about creating an explicit_delete_ref_cnt_ptr. I.e. a reference counted pointer where the delete is only done in an explicit delete routine. Using it in the one place where the existing code knows the lifetime of the object, as well as in my new code that keeps the object alive longer.
Incrementing and decrementing the reference count as explicit_delete_ref_cnt_ptr get manipulated.
But NOT freeing when the reference count is seen to be zero in the explicit_delete_ref_cnt_ptr destructor.
Only freeing when the reference count is seen to be zero in an explicit delete-like operation. E.g. in something like:
template<typename T> class explicit_delete_ref_cnt_ptr {
private:
T* ptr;
int rc;
...
public:
void delete_if_rc0() {
if( this->ptr ) {
this->rc--;
if( this->rc == 0 ) {
delete this->ptr;
}
this->ptr = 0;
}
}
};
OK, something like that. It's a bit unusual to have a reference counted pointer type not automatically delete the object pointed to in the rc'ed ptr destructor. But it seems like this might make mixing naked pointers and rc'ed pointers a bit safer.
But so far no need for delete this.
But then it occurred to me: if the object pointed to, the pointee, knows that it is being reference counted, e.g. if the count is inside the object (or in some other table), then the routine delete_if_rc0 could be a method of the pointee object, not the (smart) pointer.
class Pointee {
private:
int rc;
...
public:
void delete_if_rc0() {
this->rc--;
if( this->rc == 0 ) {
delete this;
}
}
}
};
Actually, it doesn't need to be a member method at all, but could be a free function:
map<void*,int> keepalive_map;
template<typename T>
void delete_if_rc0(T*ptr) {
void* tptr = (void*)ptr;
if( keepalive_map[tptr] == 1 ) {
delete ptr;
}
};
(BTW, I know the code is not quite right - it becomes less readable if I add all the details, so I am leaving it like this.)
Delete this is legal as long as object is in heap.
You would need to require object to be heap only.
The only way to do that is to make the destructor protected - this way delete may be called ONLY from class , so you would need a method that would ensure deletion
Is it allowed to delete this; if the delete-statement is the last statement that will be executed on that instance of the class? Of course I'm sure that the object represented by the this-pointer is newly-created.
I'm thinking about something like this:
void SomeModule::doStuff()
{
// in the controller, "this" object of SomeModule is the "current module"
// now, if I want to switch over to a new Module, eg:
controller->setWorkingModule(new OtherModule());
// since the new "OtherModule" object will take the lead,
// I want to get rid of this "SomeModule" object:
delete this;
}
Can I do this?
The C++ FAQ Lite has a entry specifically for this
https://isocpp.org/wiki/faq/freestore-mgmt#delete-this
I think this quote sums it up nicely
As long as you're careful, it's OK for an object to commit suicide (delete this).
Yes, delete this; has defined results, as long as (as you've noted) you assure the object was allocated dynamically, and (of course) never attempt to use the object after it's destroyed. Over the years, many questions have been asked about what the standard says specifically about delete this;, as opposed to deleting some other pointer. The answer to that is fairly short and simple: it doesn't say much of anything. It just says that delete's operand must be an expression that designates a pointer to an object, or an array of objects. It goes into quite a bit of detail about things like how it figures out what (if any) deallocation function to call to release the memory, but the entire section on delete (§[expr.delete]) doesn't mention delete this; specifically at all. The section on destructors does mention delete this in one place (§[class.dtor]/13):
At the point of definition of a virtual destructor (including an implicit definition (15.8)), the non-array deallocation function is determined as if for the expression delete this appearing in a non-virtual destructor of the destructor’s class (see 8.3.5).
That tends to support the idea that the standard considers delete this; to be valid -- if it was invalid, its type wouldn't be meaningful. That's the only place the standard mentions delete this; at all, as far as I know.
Anyway, some consider delete this a nasty hack, and tell anybody who will listen that it should be avoided. One commonly cited problem is the difficulty of ensuring that objects of the class are only ever allocated dynamically. Others consider it a perfectly reasonable idiom, and use it all the time. Personally, I'm somewhere in the middle: I rarely use it, but don't hesitate to do so when it seems to be the right tool for the job.
The primary time you use this technique is with an object that has a life that's almost entirely its own. One example James Kanze has cited was a billing/tracking system he worked on for a phone company. When you start to make a phone call, something takes note of that and creates a phone_call object. From that point onward, the phone_call object handles the details of the phone call (making a connection when you dial, adding an entry to the database to say when the call started, possibly connect more people if you do a conference call, etc.) When the last people on the call hang up, the phone_call object does its final book-keeping (e.g., adds an entry to the database to say when you hung up, so they can compute how long your call was) and then destroys itself. The lifetime of the phone_call object is based on when the first person starts the call and when the last people leave the call -- from the viewpoint of the rest of the system, it's basically entirely arbitrary, so you can't tie it to any lexical scope in the code, or anything on that order.
For anybody who might care about how dependable this kind of coding can be: if you make a phone call to, from, or through almost any part of Europe, there's a pretty good chance that it's being handled (at least in part) by code that does exactly this.
If it scares you, there's a perfectly legal hack:
void myclass::delete_me()
{
std::unique_ptr<myclass> bye_bye(this);
}
I think delete this is idiomatic C++ though, and I only present this as a curiosity.
There is a case where this construct is actually useful - you can delete the object after throwing an exception that needs member data from the object. The object remains valid until after the throw takes place.
void myclass::throw_error()
{
std::unique_ptr<myclass> bye_bye(this);
throw std::runtime_exception(this->error_msg);
}
Note: if you're using a compiler older than C++11 you can use std::auto_ptr instead of std::unique_ptr, it will do the same thing.
One of the reasons that C++ was designed was to make it easy to reuse code. In general, C++ should be written so that it works whether the class is instantiated on the heap, in an array, or on the stack. "Delete this" is a very bad coding practice because it will only work if a single instance is defined on the heap; and there had better not be another delete statement, which is typically used by most developers to clean up the heap. Doing this also assumes that no maintenance programmer in the future will cure a falsely perceived memory leak by adding a delete statement.
Even if you know in advance that your current plan is to only allocate a single instance on the heap, what if some happy-go-lucky developer comes along in the future and decides to create an instance on the stack? Or, what if he cuts and pastes certain portions of the class to a new class that he intends to use on the stack? When the code reaches "delete this" it will go off and delete it, but then when the object goes out of scope, it will call the destructor. The destructor will then try to delete it again and then you are hosed. In the past, doing something like this would screw up not only the program but the operating system and the computer would need to be rebooted. In any case, this is highly NOT recommended and should almost always be avoided. I would have to be desperate, seriously plastered, or really hate the company I worked for to write code that did this.
It is allowed (just do not use the object after that), but I wouldn't write such code on practice. I think that delete this should appear only in functions that called release or Release and looks like: void release() { ref--; if (ref<1) delete this; }.
Well, in Component Object Model (COM) delete this construction can be a part of Release method that is called whenever you want to release aquisited object:
void IMyInterface::Release()
{
--instanceCount;
if(instanceCount == 0)
delete this;
}
This is the core idiom for reference-counted objects.
Reference-counting is a strong form of deterministic garbage collection- it ensures objects manage their OWN lifetime instead of relying on 'smart' pointers, etc. to do it for them. The underlying object is only ever accessed via "Reference" smart pointers, designed so that the pointers increment and decrement a member integer (the reference count) in the actual object.
When the last reference drops off the stack or is deleted, the reference count will go to zero. Your object's default behavior will then be a call to "delete this" to garbage collect- the libraries I write provide a protected virtual "CountIsZero" call in the base class so that you can override this behavior for things like caching.
The key to making this safe is not allowing users access to the CONSTRUCTOR of the object in question (make it protected), but instead making them call some static member- the FACTORY- like "static Reference CreateT(...)". That way you KNOW for sure that they're always built with ordinary "new" and that no raw pointer is ever available, so "delete this" won't ever blow up.
You can do so. However, you can't assign to this. Thus the reason you state for doing this, "I want to change the view," seems very questionable. The better method, in my opinion, would be for the object that holds the view to replace that view.
Of course, you're using RAII objects and so you don't actually need to call delete at all...right?
This is an old, answered, question, but #Alexandre asked "Why would anyone want to do this?", and I thought that I might provide an example usage that I am considering this afternoon.
Legacy code. Uses naked pointers Obj*obj with a delete obj at the end.
Unfortunately I need sometimes, not often, to keep the object alive longer.
I am considering making it a reference counted smart pointer. But there would be lots of code to change, if I was to use ref_cnt_ptr<Obj> everywhere. And if you mix naked Obj* and ref_cnt_ptr, you can get the object implicitly deleted when the last ref_cnt_ptr goes away, even though there are Obj* still alive.
So I am thinking about creating an explicit_delete_ref_cnt_ptr. I.e. a reference counted pointer where the delete is only done in an explicit delete routine. Using it in the one place where the existing code knows the lifetime of the object, as well as in my new code that keeps the object alive longer.
Incrementing and decrementing the reference count as explicit_delete_ref_cnt_ptr get manipulated.
But NOT freeing when the reference count is seen to be zero in the explicit_delete_ref_cnt_ptr destructor.
Only freeing when the reference count is seen to be zero in an explicit delete-like operation. E.g. in something like:
template<typename T> class explicit_delete_ref_cnt_ptr {
private:
T* ptr;
int rc;
...
public:
void delete_if_rc0() {
if( this->ptr ) {
this->rc--;
if( this->rc == 0 ) {
delete this->ptr;
}
this->ptr = 0;
}
}
};
OK, something like that. It's a bit unusual to have a reference counted pointer type not automatically delete the object pointed to in the rc'ed ptr destructor. But it seems like this might make mixing naked pointers and rc'ed pointers a bit safer.
But so far no need for delete this.
But then it occurred to me: if the object pointed to, the pointee, knows that it is being reference counted, e.g. if the count is inside the object (or in some other table), then the routine delete_if_rc0 could be a method of the pointee object, not the (smart) pointer.
class Pointee {
private:
int rc;
...
public:
void delete_if_rc0() {
this->rc--;
if( this->rc == 0 ) {
delete this;
}
}
}
};
Actually, it doesn't need to be a member method at all, but could be a free function:
map<void*,int> keepalive_map;
template<typename T>
void delete_if_rc0(T*ptr) {
void* tptr = (void*)ptr;
if( keepalive_map[tptr] == 1 ) {
delete ptr;
}
};
(BTW, I know the code is not quite right - it becomes less readable if I add all the details, so I am leaving it like this.)
Delete this is legal as long as object is in heap.
You would need to require object to be heap only.
The only way to do that is to make the destructor protected - this way delete may be called ONLY from class , so you would need a method that would ensure deletion
class A
{
private:
A(){};
~A(){};
public:
static A* GetInstance( void )
{
static A obj;
return& obj;
}
};
I was supposing if something bad happens would only happen at the first time, since the class constructor is only initialized the first time a call to GetInstance happens, I don't know the great depths of C++ and I do not trust C++, so when I need a pointer to this class that will be used many times in a function I'm currently doing:
A* ptr = A::GetInstance();
if( ptr )
{
Checking for the pointer validity, I believe that the method returns the address where the value of obj is stored so that ptr will point to it, which I guess it can't fail.
Please observe that I'm not talking about a small application, I'm currently developing on a 500,000+ lines MMO server application that handles thousand of clients and has to stay opened for weeks without crashing, defensive programming is the least minimum required. Is it for sure, 100% safe to use ptr without checking its validity?
There is certainly no way that that function will ever return a null pointer, so there's no point checking for that. It might make more sense to return a reference, to make it clear that it won't be null.
However, there's no guarantee that the function will always return a pointer to a valid object. If it's called from the destructor of a static object, then obj might already have been destroyed. This is one reason why globally accessible objects are a very bad idea, whether or not you wrap them up in the Singleton anti-pattern like this.
The function will always return a pointer to an object that exists. The only danger is if the object itself is invalid, and this should have been indicated by a throw from the object constructor. In your case you do not catch an exception from the constructor so the program should halt in that case, otherwise it should be good to go.
Checking for NULL is pointless because you always return a valid address.
Adding a check for the pointer is unlikely to cause significant performance degradation but should be unnecessary. Add it if it will make you feel better. However, I would be more concerned about buffer overflows, memory leaks and other more likely issues than whether the static keyword is implemented by the compiler correctly.
I have an object which needs to destroy itself.
Can it be done?
Is the example wrong?
void Pawn::specialMoves(Coordinate const& from, Coordinate const& to, int passant)
{
/*...*/
m_board->replace(to, new Queen(m_colour));//replace pawn by queen
}
void Board::replace(Coordinate const &to, Piece* newPiece)
{
delete tile[to.x()][to.y()];
tile[to.x()][to.y()] = newPiece;
}
Yes, it's legal to call delete this from inside a member function. But there's very rarely a good reason to do so (especially if you're writing idiomatic C++ where most memory-management tasks should be delegated to containers, smart pointers, etc.).
And you need to be very careful:
the suicide object must have been allocated dynamically via new (not new[]).
once an object has committed suicide, it is undefined behaviour for it to do anything that relies on its own existence (it can no longer access its own member variables, call its own virtual functions, etc.).
Here's a good sanity check for performing delete this.
Yes, it should work. Even delete this; is allowed.
But the code calling specialMoves() could be in for a nasty surprise.
Q: Can an object destroy itself?
A: Sure. "delete this" is a popular idiom in COM/ActiveX
As far as your algorithm, I'd suggest:
a "board" object has "tiles". Perhaps just a simple 2-D array.
You start out with n "pieces"
Some controller (perhaps a "game" object), moves a "piece" with respect to a "tile".
Each "tile" has a reference to 0 or 1 "pieces"
I'm not sure I see any reason to create or delete anything on a per-move basis.
IMHO...
As long as you don't access member variables or the this pointer after the call to destroy the object, you should be fine. Since it doesn't appear you're doing either of these things, the example should work.