Does the following statement invoke undefined behavior?

[Graham]

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:

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.

[filthy_mcnasty]

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.

[CornedBee]

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

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

[hankdane]

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.'

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:

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.

[Graham]

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.

[mclark]

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)

[filthy_mcnasty]

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.

[Mick]

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?

[mclark]

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?

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".