C / C++ / MFC

22-Dec-09 6:50

transoft wrote:
I think my query is very clear.

You sure can have your opinion, but you'll know if the community thinks your query is clear when they balance out your 1 votes on my posts.

Not to mention you posted a COM question on the C++ forum.

transoft wrote:
Just because you don't know it?

I mentioned COM Interop in my previous post. Did you even bother reading up on that, instead making of affronting comments?

“Follow your bliss.” – Joseph Campbell

Re: .NET and COM

Maximilien22-Dec-09 7:42

Maximilien

22-Dec-09 7:42

Rajesh R Subramanian wrote:
You sure can have your opinion, but you'll know if the community thinks your query is clear when they balance out your 1 votes on my posts.

I think this is very rude and uncalled for.

M.

This signature was proudly tested on animals.

Re: .NET and COM

Rajesh R Subramanian22-Dec-09 7:46

Life span of a Object????

22-Dec-09 7:46

You did not have a chance to read his entire post, did you?

Maximilien wrote:
I think this is very rude and uncalled for.

You know what is rude? Posting a completely vague query on a wrong forum, and insulting someone who tells you to post it in the correct forum (that, I told along with a suggestion on what should he start reading up on) is rude.

I only said that if everyone else agrees with me, they'll balance out his unjustified low-votes. I don't see how was that rude, but if that's rude, so be it. I'm done with this thread.

“Follow your bliss.” – Joseph Campbell

ForNow22-Dec-09 4:29

ForNow

22-Dec-09 4:29

Hi I know when you create a object
on the stack e.g CDialog mydailog
whitin a method of another Dialog
and method ends the object you created
whitin it is destroyed
However what if you create the object
on the heap e.g. Via new operator
would the object remain
I guess you create a thread via
AFXbeginthread it rerun a pointer
to a CWinThread and I have noticed that
after the object which created it end
the thread is stil around

Maximilien22-Dec-09 4:37

Maximilien

22-Dec-09 4:37

AFXbeginthread creates an object on the heap.

so what is the question ?

This signature was proudly tested on animals.

ForNow22-Dec-09 5:44

ForNow

22-Dec-09 5:44

So when the function that creates it goes
the Thread still exists

Rajesh R Subramanian22-Dec-09 4:45

22-Dec-09 4:45

Yes, if you create an object on the heap, it will remain until you clear it off manually (I mean - by using delete if created with new or with free if created with malloc).

ForNow wrote:
I guess you create a thread via AFXbeginthread it rerun a pointer to a CWinThread and I have noticed that after the object which created it end the thread is stil around

No, after the thread function returns, the CWinThread object deletes itself (unless you manually set the m_bAutoDelete to false).

“Follow your bliss.” – Joseph Campbell

LunaticFringe22-Dec-09 5:27

LunaticFringe

22-Dec-09 5:27

Rajesh R Subramanian wrote:
Yes, if you create an object on the heap, it will remain until you clear it off manually (I mean - by using delete if created with new or with free if created with malloc).

An addendum, if I may...

If you create an object on the heap, it'll remain there until you clean it up... or the process under which it was allocated is terminated, at which point it'll be cleaned up by the OS.

The critical point to understand is this. If you allocate memory once in the course of your program and don't delete (or free, whichever is appropriate) it, it's not a big deal - the OS will clean it up. You get into trouble when you allocate blocks repeatedly and don't free (or delete) them. It's true that the OS will still clean it all up when the process terminates, but the longer the process runs the more memory it 'leaks', with detrimental effect on the whole system for the duration of the process' lifetime. This is why it's considered to be good form to always free any memory you've allocated.

L u n a t i c F r i n g e

Rajesh R Subramanian22-Dec-09 6:02

22-Dec-09 6:02

LunaticFringe wrote:
at which point it'll be cleaned up by the OS.

I had kept that off deliberately in order for the OP to come up with a query of "What happens if I do not clean it up?". Also, it would do good go the OP if you replied to his query directly (because he will receive an email notification - now, I've received it).

“Follow your bliss.” – Joseph Campbell

Re: Life span of a Object???? [modified]

LunaticFringe22-Dec-09 6:14

LunaticFringe

22-Dec-09 6:14

Rajesh R Subramanian wrote:
I had kept that off deliberately in order for the OP to come up with a query of "What happens if I do not clean it up?".

Sorry I messed up your subtle plotting.

Big Grin | :-D

Rajesh R Subramanian wrote:
Also, it would do good go the OP if you replied to his query directly (because he will receive an email notification - now, I've received it).

Meh. My reponse was meant to be an addendum to your response - it's at the right place in the thread as far as I'm concerned. If the OP turns out to be too lazy to read the thread he started, I'm not going to lose sleep over it.

Wink | ;)

L u n a t i c F r i n g e

Nelek22-Dec-09 4:48

Nelek

22-Dec-09 4:48

Well, usually a ~~new~~ heap creation should be ended with a free, delete and/or other "destructions" to avoid overflow or undesired remanence. Specially with pointers.

Regards.
--------
M.D.V. Wink | ;)

If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.

modified on Tuesday, December 22, 2009 2:04 PM

Rajesh R Subramanian22-Dec-09 5:14

22-Dec-09 5:14

Nelek wrote:
Well, usually a new creation should be ended with a free, delete and/or other "destructions" to avoid overflow or undesired remanence.

Well, except for the fact that memory allocated with new should be cleaned up with delete, and NOT with free...

“Follow your bliss.” – Joseph Campbell

Nelek22-Dec-09 8:04

Nelek

22-Dec-09 8:04

Right. Instead of "new" should be "heap". My bad

Regards.
--------
M.D.V. Wink | ;)

Rajesh R Subramanian22-Dec-09 18:49

Stack corruption - STRANGE PROBLEM!!

22-Dec-09 18:49

Hehe. But I am not going to miss a good chance to nitpick. Wink | ;)

“Follow your bliss.” – Joseph Campbell

Shailesh H22-Dec-09 3:44

Shailesh H

22-Dec-09 3:44

I am launching a worker thread . Inside the thread function i open CDialog's using DoModal().There is no problem in the first launch of the thread.
But in second launch the stack seems to get corrupted, the CString member variable of the Dialogs show values like "C4".. "D5" etc before even they r initialized in the Dialogs contructor(i.e when the execution is within the constructor).Even after Initializing the dialog's CString variables in constructor the variables do not get initialized, they still show "C4" etc

psuedo code below:

line 1:CWelcomeDlg dlg;
line 2:dlg.SetTitle(strDialogTitle);//Set the dialog Title
line 3 :ret = dlg.DoModal();//show dialog

//Constructor
CWelcomeDlg::CWelcomeDlg(CWnd* pParent /*=NULL*/)
: CDialog(CWelcomeDlg::IDD, pParent)
{

m_strData1=_T("");---->m_strData1 shows value "C4" and cannot b initialized to empty string.

m_strData2=_T("");--->m_strData1 shows value "C4"
m_strData3=_T("");--->m_strData1 shows value "C4"
}

Re: Stack corruption - STRANGE PROBLEM!! [modified]

Shailesh H22-Dec-09 4:07

Shailesh H

22-Dec-09 4:07

Pls note that the above problem is seen only in the Release mode

Code-o-mat22-Dec-09 4:30

Code-o-mat

22-Dec-09 4:30

Does your program otherwise work ok? If yes, then take into account that the debugger might fool you, afterall, it IS a release build, we sadly have seen such "odd" occurances many times when trying to debug release builds, the "tooltips" VS displays when pointing at a variable during runtime to show you the value of the variable (or the quick watch window, or or or...) would show all kinds of exotic, strange values which clearly aren't there (you can for example check this if you bring up a message box showing the value you are interested in formatted into a string, in your case, the string itself i guess...).

p.s: ah yes, and as others said, try to avoid creating secondary UI threads because they mean a lot of trouble...

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <

modified on Tuesday, December 22, 2009 12:36 PM

Rajesh R Subramanian22-Dec-09 4:42

22-Dec-09 4:42

Shailesh H wrote:
Pls note that the above problem is seen only in the Release mode

Please note that you have an article to read[^]. Smile | :)

In addition to that, I'd second the opinion of other poster, who asked you not to touch the UI from within a worker thread.

“Follow your bliss.” – Joseph Campbell

Maximilien22-Dec-09 4:11

Maximilien

22-Dec-09 4:11

don't do UI in the worker thread; ask the main application thread to do it by sending messages and using event and things like that to keep everything synchronized.

read :

http://www.flounder.com/workerthreads.htm[^]
and everything thread related on that site.

This signature was proudly tested on animals.

Nelek22-Dec-09 4:17

Nelek

22-Dec-09 4:17

Is the second launch waiting for the first to be ended?

If not... you may have problems with DoModal () multiple calls. Would not be better to use ModalLess dialogs?

Regards.
--------
M.D.V. Wink | ;)