Two ways, Which one is better?

Printable View

Hello! Long time no see!

The following two fragments, which is better, why?

Code:

void oneDialog::function()
{
  QTestDialog* pt= new QTestDialog(this);
  // ........
  delete pt;
}
 
 
 
void oneDialog::function()
{
  QTestDialog dialog(this);
  // ........
 
}

Thanks!

29th March 2009, 12:30
wysota

Re: Two ways, Which one is better?

What do you mean "better"? They are perfectly equivalent. The second one is less code to type in. If that counts as "better" then it's better.
29th March 2009, 13:28
talk2amulya

Re: Two ways, Which one is better?

hey, i was wondering if in the second fragment, its done wrongly. cuz 'this' has been set as the parent of the dialog and as every parent deletes its childs when deleting themselves, when it will try to delete the dialog , the app should crash cuz the dialog is actually created on stack..
29th March 2009, 13:54
HelloDan

Re: Two ways, Which one is better?

Quote:

Originally Posted by talk2amulya

hey, i was wondering if in the second fragment, its done wrongly. cuz 'this' has been set as the parent of the dialog and as every parent deletes its childs when deleting themselves, when it will try to delete the dialog , the app should crash cuz the dialog is actually created on stack..

You mean that the dialog should be a modal one?
29th March 2009, 14:03
talk2amulya

Re: Two ways, Which one is better?

no, that wont make difference..all i mean is widgets and dialogs should always be created on heap..AFAIK
29th March 2009, 14:20
wysota

Re: Two ways, Which one is better?

Quote:

Originally Posted by talk2amulya

no, that wont make difference..all i mean is widgets and dialogs should always be created on heap..AFAIK

No, that's not true. A modal dialog will always be destroyed before its parent. Unless of course you explicitely shoot yourself in the leg but then the dialog shouldn't have been modal. It really doesn't matter which way you choose here. The stack based version is simply a few statements shorter to code and a tiny bit faster to execute.
29th March 2009, 15:05
talk2amulya

Re: Two ways, Which one is better?

so will that concept apply even in the case of a normal dialog(non-modal)?
29th March 2009, 15:26
lni

Re: Two ways, Which one is better?

One goes out of scope by itself, one doesn't automatically go out of scope...

If it is a modal dialog, the 2nd one works as good as the 1st one but with less codes... You can't say one is better than the other, it depends on situation...
29th March 2009, 16:10
HelloDan

Re: Two ways, Which one is better?

Does this forum has any utilities to save a thread, such add to favouites?
29th March 2009, 16:12
wysota

Re: Two ways, Which one is better?

Quote:

Originally Posted by talk2amulya

so will that concept apply even in the case of a normal dialog(non-modal)?

No. A non-modal dialog has to be created on heap.

Quote:

Originally Posted by HelloDan

Does this forum has any utilities to save a thread, such add to favouites?

Yeah, there is a "Bookmarks" table at the bottom of the page.
29th March 2009, 18:03
talk2amulya

Re: Two ways, Which one is better?

ok, so that means when i have a model dialog on STACK with another widget as parent..thats not wrong? one would think it should be...when parent will try to delete it, it should be crashing time..or am i getting smth really wrong about model dialog??.or maybe u can create a model dialog on stack and not give it a parent..in these examples, 'this' is parent, so be a dialog model or not, dialog creation on stack should be wrong.
29th March 2009, 19:41
wysota

Re: Two ways, Which one is better?

Quote:

Originally Posted by talk2amulya

ok, so that means when i have a model dialog on STACK with another widget as parent..thats not wrong?

No, it's not. Lifespan of a modal dialog is short - most probably it is born and dies within the same function (method) call. So there is no risk the child will live longer than its parent because it is created on the stack within one of its parent's (sub)methods.

Quote:

one would think it should be...when parent will try to delete it, it should be crashing time..or am i getting smth really wrong about model dialog??

Yes, it would crash. But the parent won't try to delete it because it opened the dialog for a reason and it wants to react on the choice/action performed by the user within the modal dialog.

Quote:

.or maybe u can create a model dialog on stack and not give it a parent..

Yes, you can. But then the dialog will not really be modal.

Quote:

in these examples, 'this' is parent, so be a dialog model or not, dialog creation on stack should be wrong.

No, it's fine :-) The parent lives longer than the child so the child will detach itself from the parent when it goes out of scope and is destroyed thus the parent will not try to delete it when it (the parent this time) goes out of scope.
29th March 2009, 20:24
talk2amulya

Re: Two ways, Which one is better?

ok, i can follow this chain of thoughts..but one thing still bugs me..i read on some of the threads here that one should ALWAYS create widgets and dialogs on heap, layouts also..cuz once they go out of scope and parents try to delete them, crash occurs(obviously!).. so when u say child "detaches" itself from parent when goin out of scope..wont that occur in other cases too and parent wont try to delete ths child? and why the recommendation(in multiple threads) that these things SHOULD be created on stack..how and when(in what cases) would a child detach from parent? my main concern is how would a parent know the child has already gone out of scope and not try to delete it?

another thing thats done here is dialog on heap is given a parent and then deleted in the same function..wont the parent try to delete the dialog object or dialog again detaches?i mean once u give a widget a parent, deleting it yourself should be kinda foolish? i can go on with queries :) but essence of my question is how does a parent know which child to delete and in what cases would a child detach itself from parent?
29th March 2009, 21:29
wysota

Re: Two ways, Which one is better?

Quote:

Originally Posted by talk2amulya

ok, i can follow this chain of thoughts..but one thing still bugs me..i read on some of the threads here that one should ALWAYS create widgets and dialogs on heap, layouts also..cuz once they go out of scope and parents try to delete them, crash occurs(obviously!)..

Only when both the parent and the child are created on the same frame of the stack or the child is created on the stack, the parent on the heap and you delete the parent while the stack frame holding the child is still valid. This is not the case here and it's one of few exceptions when it's ok to create a widget on stack.

Quote:

so when u say child "detaches" itself from parent when goin out of scope..wont that occur in other cases too and parent wont try to delete ths child?

The problem is with double deleting the same object. Consider a situation when the parent is on the heap, the child is on the stack and you delete the parent. When this happens, the parent deletes all its children including the one child residing on the stack. So far this is fine. The trouble begins when the stack frame holding the child widget goes out of scope. The compiler calls destructors of all object residing in the frame including the child widget. Unfortunately the child has already been deleted earlier so we're trying to destroy an object that has already been destroyed which results in aborting the process.

Quote:

and why the recommendation(in multiple threads) that these things SHOULD be created on stack.

With modal dialogs it is easier to create them on the stack because you don't have to worry about deleting them afterwards because the compiler does that for you.

Quote:

.how and when(in what cases) would a child detach from parent?

When it's deleted. The case we're talking about is not related to not detaching from the parent but to double deletion caused by the compiler. And we can't overcome that so you shouldn't create widgets on the stack if you fear the parent might be deleted before the child is deleted.

Quote:

my main concern is how would a parent know the child has already gone out of scope and not try to delete it?

The parent (during runtime) knows. The compiler (during compile time) does not.

Quote:

i mean once u give a widget a parent, deleting it yourself should be kinda foolish?

I'd say it would be foolish if you couldn't delete an object if you wanted to.
29th March 2009, 22:37
talk2amulya

Re: Two ways, Which one is better?
thanks wysota, so i was thinkin that parent might try to delete a child created on stack which should produce crash..so in nutshell, parent would know when a child is deleted and it wont try to delete it..but still, if i create an object on stack like this
Code:

QWidget *someWidget = new QWidget(); QDialog dialog(someWidget); delete someWidget; // crash here?
in the destructor of parent class(QWidget), they are calling delete on children even when they r created on stack which should produce instantaneous crash..it shouldnt even reach the compiler created code for removing the dialog object or would it? i tried something similar and although it sort off showed a weird crash at delete of child..but somehow it went ahead and executed the code further and then crashed later when the stack tried to delete the dialog object..how was this possible? plus doesnt this show real proof that creating qobjects on stack with a parent should be a big no-no? i mean yeh, the case of hellodan survives this, but shouldnt doing this be discouraged?
29th March 2009, 23:20
wysota

Re: Two ways, Which one is better?
Quote:

Originally Posted by talk2amulya

in the destructor of parent class(QWidget), they are calling delete on children even when they r created on stack which should produce instantaneous crash.

it shouldnt even reach the compiler created code for removing the dialog object or would it?

Hmm... I guess it depends on the operating system. It might detect you are trying to delete a pointer that is in stack address space which is obviously going to lead to a crash anyway and might terminate your process. But I guess it doesn't have to at least I'm not aware of any C++ rule about what happens after you delete a non-heap pointer.

Quote:

i tried something similar and although it sort off showed a weird crash at delete of child..but somehow it went ahead and executed the code further and then crashed later when the stack tried to delete the dialog object..how was this possible?

That's the variant I described earlier - a double delete caused by the compiler.

Quote:

plus doesnt this show real proof that creating qobjects on stack with a parent should be a big no-no? i mean yeh, the case of hellodan survives this, but shouldnt doing this be discouraged?

It is discouraged :) My opinion is that you can use any mechanism the language supports if you know what you are doing. You might even use "goto" if you want. And there is always a chance of shooting yourself in the foot and yet nobody prevents you from doing that. Consider this:
Code:

Object o; delete &o;
or:
Code:

Object *o; delete o; // with a bit of luck this will not always crash...
I might offend some of the people here but in general I'm against "enlightened users" writing software. If they implement crashing code, that's their choice, they have been warned. Someone who knows the language well and knows the internal behaviour of computer systems will know when to create something on the heap and when to create it on the stack.
30th March 2009, 06:57
talk2amulya

Re: Two ways, Which one is better?

Quote:

Originally Posted by wysota

Hmm... I guess it depends on the operating system. It might detect you are trying to delete a pointer that is in stack address space which is obviously going to lead to a crash anyway and might terminate your process. But I guess it doesn't have to at least I'm not aware of any C++ rule about what happens after you delete a non-heap pointer.

i believe its not dependent upon operating system. I tried my example with minGW compiler and VC++ compiler, both gave different results. on VC++ compiler, the application crashes while deleting an object created on stack, whereas when using minGW compiler, on the same operating system(Windows xp), it didnt crash there but when compiler is double deleting. Perhaps VC++ takes a stand on the deleting of non-heap pointers. Anyways, i think to answer the question of hellodan, one would say the creation of object on heap would be a better solution but thats just me :)
30th March 2009, 13:20
wysota

Re: Two ways, Which one is better?

Quote:

Originally Posted by talk2amulya

i believe its not dependent upon operating system. I tried my example with minGW compiler and VC++ compiler, both gave different results. on VC++ compiler, the application crashes while deleting an object created on stack, whereas when using minGW compiler, on the same operating system(Windows xp), it didnt crash there but when compiler is double deleting. Perhaps VC++ takes a stand on the deleting of non-heap pointers. Anyways, i think to answer the question of hellodan, one would say the creation of object on heap would be a better solution but thats just me :)

It only means it is also dependent on the compiler.
30th March 2009, 21:51
ktk

Re: Two ways, Which one is better?

Quote:

Originally Posted by wysota

What do you mean "better"? They are perfectly equivalent. The second one is less code to type in. If that counts as "better" then it's better.

It also use one allocation less and has a slightly better chance to be exception save. I can't think of any situation where the first form is better.
30th March 2009, 22:24
wysota

Re: Two ways, Which one is better?

This is really an academic talk. One allocation more or less doesn't make a difference, Qt doesn't use exceptions so only your code can be throwing one so you should know how/where to catch it, etc. These two are practically equivalent, the stack based is simpler to type in which is completely meaningless as well. There is a potential situation when a heap based dialogue would lead to a memory leak but then read my post about "enlightened users" :)