|
Nope. By default the CWinThread m_bAutoDelete data member is TRUE, and the pointer is deleted when the thread terminates (see [^]).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi,
initialize the "m_bAutoDelete" data member for your needs.
If you set this member to TRUE, you doesn't need delete the pointer.
Greetings
|
|
|
|
|
As the others already have said: no, you don't.
At least not in the context you provided.
But...
It's considered good practice to make sure all threads have finished before closing an application. By waiting on the thread handle you make sure the thread has finished. To be able to wait on the thread handle with e.g. ::WaitForSingleObject(), the thread handle must be valid. If the CWinThread object has its m_bAutoDelete member set to TRUE the thread handle will be closed when the thread exit its controlling function and the CWinThread object is destroyed.
If you want to avoid this situation you should create the thread suspended and set the m_bAutoDelete memeber to FALSE before resuming thread execution with a call to CWinThread::ResumeThread().
In this case you have to delete the CWinThread object yourself by calling delete after you've waited on the thread handle CWinThread::m_hThread.
Read more here[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi!
I've to call a function from my implementation file. It has two versions in the header file. These are:
Version1:
osg::Switch* GetSwitch(const std::string& name);
const osg::Switch* GetSwitch(const std::string& name) const;
I'm calling this function in my .cpp file as follows:
const std::string SwitchName = SignalNode->getName();
osg::Switch* SignalSwitch = dynamic_cast<osg::Switch*>(NodeCollector::GetSwitch(SwitchName));
It shows error C2668 as shown below:
Macro definition of min detected - undefining
.\testAI.cpp(105) : error C2668: 'dtCore::NodeCollector::GetSwitch' : ambiguous call to overloaded function
C:\Program Files\Delta3D_REL-2.0.0\inc\dtCore/nodecollector.h(177): could be 'osg::Switch *dtCore::NodeCollector::GetSwitch(const std::string &)'
|
|
|
|
|
why are you making the dynamic_cast ?
remove it, the error will go away.
|
|
|
|
|
Hi!
No. The error persits even if I removed dynamic_cast also. What to do?
|
|
|
|
|
Your methods are static?? 
Why are you calling methods using class..
Regards,
Sandip.
modified on Wednesday, September 24, 2008 7:17 AM
|
|
|
|
|
No. It's non-static only.
|
|
|
|
|
Read My previous post again.
Why are you calling non static method using class???
Does it help??
Regards,
Sandip.
|
|
|
|
|
as someone stated (to whom no didn't answer - shame on you) : why are you calling GetSwitch() from the class rather than from an instance of the NodeCollector class ?
you said the function was not static, so why do you do something like NodeCollector::GetSwitch(SwitchName) instead of something like node.GetSwitch(SwitchName) or nodePtr->GetSwitch(SwitchName) ?
|
|
|
|
|
Hi toxcct,
Method seems to be static 
No he is calling them using class 
Regards,
Sandip.
modified on Wednesday, September 24, 2008 7:18 AM
|
|
|
|
|
I am bit confused is there any difference between two methods.
The secret of life is not enjoyment
but education through experience.
- Swami Vivekananda.
|
|
|
|
|
don't you see the constness of the second definition ?! 
|
|
|
|
|
Mahesh Kulkarni wrote: any difference between two methods.
Difference is const
Regards,
Sandip.
|
|
|
|
|
The compiler can't decide whether you want the const or non-const function invoked. Saying you want the non-const explicitly should do the trick.
const std::string SwitchName = SignalNode->getName();
osg::Switch* SignalSwitch = dynamic_cast<osg::switch*>((osg::Switch*) NodeCollector::GetSwitch(SwitchName));
Hope it works.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
|
It might help the constness experts to solve your issue if you say which compiler version you're using. VC6 treats const parameter type matching quite differently from, for example, VS2005.
Is there any difference between what the 2 functions actually do?
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Why none of us noticed that he is calling non static methods using class.. 
Regards,
Sandip.
|
|
|
|
|
Hello everyone,
1.
Sometimes in x64 release code (optimized to full level), even if we defined some global data, variables or member variables for some data structures, we can not see the actual value in debugger. The related error message is -- "Error: expression cannot be evaluated".
I think it is because of x64 code optimization to remove some variables or changed code execution path?
2.
Any ways to "watch" such variables? Currently I am just looking at the asembly code to find what the actual execution is. For example, in source code I pass variable foo to function SetValue, but since in debugger I can not watch such variable foo, then I go to assembly code to watch what values are passed to function SetValue through register or stack.
Any better ideas to debug such x64 optimized code? Is it a common issue in debugging x64 release code?
thanks in advance,
George
|
|
|
|
|
I donot know what is a " x64 release code (optimized to full level)."
you may try this !!
Did u try to check the value in the "Immediate window" which comes when
you run your code, it will be present beside the output window, if u donot find it the go to on the top of the screen near "file, edit " options u get a Break point icon click it it will have Immediate window! click it.
Just while debugging u can just type the name of the variable in this window and press enter it gives the value of the variable !!
modified on Wednesday, September 24, 2008 8:10 AM
|
|
|
|
|
1.
No kapardhi, for some local variables, I can not see its value, the error message is "Error: expression cannot be evaluated". Any comments or ideas? This is why I come here to ask this question.
2.
"x64 release code (optimized to full level)" -- I mean build for x64 platform, open optimization to max level. Clear now?
regards,
George
|
|
|
|
|
You may be able to use the "Stakeout" debugging pattern: Get the address of the variable you want to monitor, then dereference this address in your watch window.
This is useful to monitor variables that go out of scope.
For example, enter "&foo" in the watch window to get the address of foo. Say it's 0x00112233.
Enter *(int *) 0x00112233 in the watch window. This will display the integer at this address.
|
|
|
|
|
Hi Alan!
When making my mouse over the variable, there is error message like "Error: expression cannot be evaluated", and I can not get the value of its address by using operator & in watch window, how could I know its address?
Any comments?
regards,
George
|
|
|
|
|
You might be able to get its address if you used a Debug build. Is there any reason you're trying to debug using a Release build?
|
|
|
|
|
Hi Alan,
The release version is running and serves some users, I do not want to stop it to replace with a debug version. And I can not reproduce the same issue in debug version. Just want to attach to release version running code to see some variable values.
I think debugger is using PDB file to resolve name/symbol correct? But in release version PDB has some issues and not be able to tract the correct value of variable?
regards,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
