Does the following statement invoke undefined behavior?

The example uses built-in types but of course what I really care about are user-defined types.

This is a question about evaluation rules... I believe it is well behaved because the rhs argument to operator= must be fully evaluated before the assignment occurs. But does the copy constructor complete before new returns?

int
main(void)
{
int * p1 = new int(3);

// is this legal? (ignore the memory leak)
p1 = new int(*p1); // clone

return 0;
}

I'm not an expert on the standards, but I'm pretty sure the constructor is supposed to complete before the assignment occurs.

aside from your note about the memory leak, yes that should work just fine so long as the copy constructor does in fact exist *you said you dont care about POD types*

AFAICT it's legal, but why would you want to do it? You can't ignore the memory leak...

p1 = new int(*p1);
is as legal as
a = a+1;

First the rhs of = is completely evaluated, then it is assigned to the lhs.

Quote:

---

Originally posted by Graham
You can't ignore the memory leak...

---

Sure you can! I've seen many people ignore memory leaks! (Far too many!)

Before anyone jumps on me, I am not encouraging anyone to actually ignore memory leaks. I was more making a (hopefully ammusing) comment about how many applications I have seen that have (and ignore) memory leaks.

I understood it...

Quote:

---

Originally posted by Graham
AFAICT it's legal, but why would you want to do it? You can't ignore the memory leak...

---

I suspect the OP wants to do something of semantic importance in the c'tor. You could do something like this:

Code:

---

CFoo::CFoo(CFoo* pFoo)
{
    DeepCopy(this, pFoo);
    delete pFoo;
}

---

Then you would not have a memory leak.

Personally, I would not use or advocate this type of design, but it's legal and you can make it clean.

i think we have done exactly what the OP was trying to make us not do by his statement "aside from the memory leak". in other words, he knows it's a memory leak and that issue is irrelevant for the scope of his other question and he simply didn't feel like typing the delete line.

Quote:

---

Originally posted by KevinHall
Before anyone jumps on me, I am not encouraging anyone to actually ignore memory leaks. I was more making a (hopefully ammusing) comment about how many applications I have seen that have (and ignore) memory leaks.

---

such a simple thing that causes so many problems....or maybe it's just simple developers...

GDI object leaks, file handle leaks, new/delete, malloc/free, using API's that say you must call this when you are finished with the buffer to free it...and you don't... :(

whats even more sad is when it happens in a product that's regulated by the FDA because it runs in hospitals... :mad:

/Amused by your statement, not amused that it happens.

In fact, the second "new" is a placement new, if I am not mistaken, and it is not the cause of the memory leak per se, but rather the missing "delete" is. Or am I wrong?

the second new call wouldn't be a problem per se if he saved the original pointer (p1) somewhere else so he could access (delete) it later. however, his code does not do this from what we see and immediately after the second new call there is a reserved chunk of space that he no longer has any means of accessing (the first new call) and thus, a memory leak. gabriel you are entirely right (like usual =) ) that the problem is simply a missing delete call on something that was allocated. but in this case the reason that the delete cant be called is because the 2nd new has changed p1 to point to something else so i guess it really just depends on how you look at it. a lack of a delete call or the new call itself can 'cause' the memory leak here depending on your point of view.

buuuuut, i still think we have taken this way out of context though and the OP is aware of all the issues we are raising.

Quote:

---

Originally posted by filthy_mcnasty
the second new call wouldn't be a problem per se if he saved the original pointer (p1) somewhere else so he could access (delete) it later. however, his code does not do this from what we see and immediately after the second new call there is a reserved chunk of space that he no longer has any means of accessing (the first new call) and thus, a memory leak. gabriel you are entirely right (like usual =) ) that the problem is simply a missing delete call on something that was allocated. but in this case the reason that the delete cant be called is because the 2nd new has changed p1 to point to something else so i guess it really just depends on how you look at it. a lack of a delete call or the new call itself can 'cause' the memory leak here depending on your point of view.

buuuuut, i still think we have taken this way out of context though and the OP is aware of all the issues we are raising.

---

The second new is a placement new, that is, it won't change the pointer value {p1 = new int(*p1); -- note that p1 is passed to new()}, so we won't have a memory block that we can't access (or delete) any more. The placement new is, of course, useles, for ints (or other PODs). In the general case, it would construct the object at the address passed to it.

A delete p1 before the return eliminated the leak.

Dang! Forget what I said -- it's wrong. I haven't noticed the dereferencing of p1.:blush: