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:

hankdane: yes, but is that ctor anything more than a potentially time-consuming no-op?

filthy_mcnasty: I disagree - I'm struggling to come up with any sensible reason for doing that - even if you do fix the leak:

Code:

---

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

    // this seems really perverse..
    int* p2 = p1;
    p1 = new int(*p1); // clone

    delete p2;
    return 0;
}

---

or, if a copy was really wanted, why not "int* p2 = new int(*p1)". It's just that every time I try to think of some reason for doing that, there's a less awkard way to do the same thing.

So I maintain that you can't ignore the leak, because I can't see any purpose to the statement other than to leak memory. If anyone can think of a valid purpose for that statement, please post it here.

ok so the first line creates a new object right? an integer w/ value 3. then the second call to new will simply dereference the value at that pointer and create another new chunk with the same value.

based on what you're saying Gabriel this should crash....

int *p1, *p2;
p1 = new int(4);
p2 = p1;
p1 = new int(*p1);
delete p1;
delete p2;

not only does it not crash but that's how it should be

-edit-
ooops just saw your last post gabriel =).
Graham i'm not saying to ignore the leak by any means, you're entirely right that you should never ever do that i'm just saying it doesn't really pertain to what the poster is asking *whether or not the statement is valid, the OP is only concerned in his example with whether or not the RHS is evaluated properly before assignment to p1. i hope to god he's not actually touching a computer if he blatantly ignores a leak like that* and we've gone off on a tangent on him.

Graham: a possible situtation where this syntax can save 4 bytes of stack space is this:

Code:

---

int *p = get_pointer_from _secret_place();
p = new int(*p);
++*p;
add_pointer_to_secret_place();

---

Quote:

---

Originally posted by Graham
hankdane: yes, but is that ctor anything more than a potentially time-consuming no-op?

---

Not as I wrote it out, no. I was trying to imply that there would be something in the copying operation that would be something more. That is what I meant by 'semantical importanct.'

Quote:

---

If anyone can think of a valid purpose for that statement, please post it here.

---

I maintain that I did, in the abstract. If you want a more detailed example, it could look something like:

Code:

---

CFoo::CFoo(CFoo* pFoo)
{
  if (pFoo->SomeProp())
    Initialize(pFoo->GetPropSet1());
  else
    AlternateInitialize(pFoo->GetPropSet2());
  //Done with pFoo
  delete pFoo;
}

---

I realize this still doesn't answer why the new CFoo* has to get assigned back to the pFoo actual parameter, but I assumed there was something in the overall design that would make that an advantage. Like I indicated, this type of approach is not my own modus operandi, so I can't think of a good design example that would illustrate.

As a parallel example, I rarely if ever use or generate deep copies of my objects, and off the top of my head, I could not think of a good situation where that would be required. Yet, deep copies are often used.

Quote:

---

I realize this still doesn't answer why the new CFoo* has to get assigned back to the pFoo actual parameter, but I assumed there was something in the overall design that would make that an advantage.

---

But that's the reason I asked the question... obviously, there's a point to the constructor - it's just that overwriting the old address with the address of the new object means that you can only now access the "copy" and you have no access to the "original". How is that an improvement on modifying the original according to whatever rules the ctor uses to contruct the "copy", or to planting the address in a new variable and having access to both old and new? Other than introducing a memory leak, of course. ;)

My question about the validity of the statement was not about the bit on the right of the equals sign, it was about the whole statement. You admit that you haven't answered why the new CFoo* gets assigned back the original pointer variable, so my question still stands:

If anyone can think of a valid purpose for that statement (the whole statement, that is), please post it here.

IOW, I'm questioning the assumption that something in the overall design makes it an advantage - I can't conceive of anything that would.

Quote:

---

Originally posted by Graham
If anyone can think of a valid purpose for that statement (the whole statement, that is), please post it here.

IOW, I'm questioning the assumption that something in the overall design makes it an advantage - I can't conceive of anything that would.

---

Wow, pretty uncreative. If you must know this code is for cloning. It comes from a reference implementation of C++ Library Extensions Technical Report 1 (tr1) - polymorphic function object adaptors.

And this work is not done in the ctor. It's done in a templated free function called by reference from classes of seperate types. Again, I'm not going to go into details but the design is well thought out and in wide use. The code I posted was intentionally simplified as to highlight the issue I had a question about - not to demonstrate the utility of the statement's idiom. That is why I asked responders to ignore the memory leak as a way of focusing them on the question at hand and not off on tangents on the purpose of the statement (because no sufficently succinct example would adequately demonstrate its full purpose and because the example is not the exact form of the production statement).

Thank you all for promptly ignoring my request and plunging headlong into a discussion of the statement's objective value - a question that was entirely hopelessly unanswerable without understanding the context in which the statement occurs. But alas, blind speculation has brought us here - to post page 2 and the short-sighted conclusion the my example code statement (of which I was only concered with semantic validity) has no useful place in any software design.

Moderator - please kill this thread.

(sorry to be harsh - didn't get much sleep last night and I'm in a bad mood)

Quote:

---

That is why I asked responders to ignore the memory leak as a way of focusing them on the question at hand and not off on tangents on the purpose of the statement (because no sufficently succinct example would adequately demonstrate its full purpose and because the example is not the exact form of the production statement).

Thank you all for promptly ignoring my request and plunging headlong into a discussion of the statement's objective value - a question that was entirely hopelessly unanswerable without understanding the context in which the statement occurs

---

I've been saying this all along. On behalf of the others I would appologize for what became thread hijacking.

Quote:

---

Originally posted by mclark

Moderator - please kill this thread.

(sorry to be harsh - didn't get much sleep last night and I'm in a bad mood)

---

Perhaps if you exfoliated early on, you wouldn't have gotten certain responses. The first 4 posts I believe provided the consensus, or did I miss something? :D

Quote:

---

Originally posted by Mick
Perhaps if you exfoliated early on, you wouldn't have gotten certain responses. The first 4 posts I believe provided the consensus, or did I miss something? :D

---

I thought it was pretty clear from the first 4 posts that the question had indeed been answered. I guess next time I'll explicitly state "ok - thank you - I understand - the end".