|
IMHO your analysis is correct (both point 1 and 2. However, with regard to point 1, my interpretation is: since Goo copy constructor declares its argument const, then its content cannot be modified, but assigment operator of auto_ptr modify its argument, hence the problem).
George_George wrote: What makes me confused is it seems the compile error message does not reflect my analysis (1) and (2) above. Any ideas?
I think that (it's just an hypothesis), since no auto_ptr copy constructor can match the this -> pf = input.pf;, the compiler tries to search for an assignment operator match, but it fails again and gives such error.
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
|
|
|
|
|
Cool, CPallini!
1.
CPallini wrote: I think that (it's just an hypothesis), since no auto_ptr copy constructor can match the this -> pf = input.pf;, the compiler tries to search for an assignment operator match, but it fails again and gives such error.
You mean compiler search for all forms of assignment operator of auto_ptr, then no one matches so the compile errors come?
2.
The source of error is because the basic C++ ruls is violated -- can not assign const reference (input.pf) to non-const reference (input parameter of assignment operator of class auto_ptr)?
regards,
George
|
|
|
|
|
George_George wrote: 1.
CPallini wrote:
I think that (it's just an hypothesis), since no auto_ptr copy constructor can match the this -> pf = input.pf;, the compiler tries to search for an assignment operator match, but it fails again and gives such error.
You mean compiler search for all forms of assignment operator of auto_ptr, then no one matches so the compile errors come?
Yes, I think so.
George_George wrote: 2.
The source of error is because the basic C++ ruls is violated -- can not assign const reference (input.pf) to non-const reference (input parameter of assignment operator of class auto_ptr)?
Yes.
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
|
|
|
|
|
Thanks CPallini,
Question answered! Cool!!
regards,
George
|
|
|
|
|
say i have a function int fun(int *a),
and other function int fa(); int fb(), int fc(),....int fn();
all the them will call the fun(int *a),
but the problem is, when I run the program, the vc++ tells me some of them pass the NULL pointer to the fun(int *a) which make mistake, but could not tell me which function calls the fun(int *a) and then pass the NULL pointer to it,
so dear guys, how could I know which one call the fun(int *a) that pass the NULL pointer?
Thanks.
|
|
|
|
|
 I didn't really understand your problem. Do you have a crash and would like to find the problem ? If yes, did you use your debugger to track the problem ? Using the callstack you'll be able to find which function passed a NULL pointer.
|
|
|
|
|
Hi,
If your program stops with runtime error, as Cedric said, use the "call stack" window and see which one of fa(), fb().. fn() is called just before fun().
Or try using only one function from fa(), fb() ... fn() at a time
and find out.
If you have problem still post the relevant code snippet.
Best Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
Well one way like others said, if you are programming in Visual Studio, you can set break point and check the call stack when program crashes.
Another way is to do it like this:
int fa()<br />
{<br />
int* a;<br />
.<br />
.<br />
.<br />
if(a == NULL)<br />
{<br />
cout << "fa is the culprit";<br />
}<br />
fun(a);<br />
}
-Saurabh
|
|
|
|
|
Use the debugger to set a breakpoint in fun(). When a equals NULL, check the call stack.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Did you get runtime error?
|
|
|
|
|
Without asking how to do it, I'd like to ask if it's theoretically possible for me to create my own version of the C++ runtime, and have VC++ link my programs to that instead of the usual one.
Is such a thing possible?
“Cannot find REALITY.SYS...Universe Halted.”
~ God on phone with Microsoft Customer Support
|
|
|
|
|
Yes it's possible.
See the /ENTRY linker option...
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
|
Do you want to make an exe file yourself without vc++ compiler?
|
|
|
|
|
Hi,
I recently moved application resources (dialogs and strings) into a resource only DLL and came across a problem that I don't fully understand... thanks for some help.
As soon as I created my main dialog from the loaded DLL it failed and the debug output showed something like: >>> If this dialog has OLE controls: AfxEnableControlContainer has not been called yet. I traced it back to an owner draw control in the dialog, when I removed this control all worked fine. So I played around a bit with my owner draw control. It is derived from CWnd and tries to register a window class, here is the code:
WNDCLASS wndcls;
HINSTANCE hInst = AfxGetInstanceHandle();
if(!(::GetClassInfo(hInst, MY_CONST_CLASSNAME, &wndcls)))
{
wndcls.style = CS_DBLCLKS | CS_HREDRAW | CS_VREDRAW;
wndcls.lpfnWndProc = ::DefWindowProc;
wndcls.cbClsExtra = wndcls.cbWndExtra = 0;
wndcls.hInstance = hInst;
wndcls.hIcon = NULL;
wndcls.hCursor = AfxGetApp()->LoadStandardCursor(IDC_ARROW);
wndcls.hbrBackground = NULL;
wndcls.lpszMenuName = NULL;
wndcls.lpszClassName = MY_CONST_CLASSNAME;
AfxRegisterClass(&wndcls)
}
After I replaced AfxGetInstanceHandle() with AfxGetResourceHandle() it works. This was just try and error, am I doing it right? Because MSDN says hInstance = "Handle to the instance that contains the window procedure for the class".
/Moak
|
|
|
|
|
Moak wrote: After I replaced AfxGetInstanceHandle() with AfxGetResourceHandle() it works.
It's interesting that it works, since DefWindowProc() isn't in either of your modules
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark now I am more confused 
...did I do something stupid?
|
|
|
|
|
Moak wrote: ...did I do something stupid?
Heh not that I can see off hand. I'm just curious why it works with one HINSTANCE and not
the other...unless one is NULL?
Do you use AfxSetResourceHandle() somewhere?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: Do you use AfxSetResourceHandle() somewhere?
Yup, the resources are loaded from a satellite DLL with LoadLibrary() and AfxSetResourceHandle(). The HINSTANCE for both (application or DLL) is not NULL.
|
|
|
|
|
I just found something. Looks like my code for registering the window class is like in Chris Maunder's article Creating Custom Controls[^] and someone mentions the same problem there.
Thanks for help
/M
|
|
|
|
|
Hei Moak,
Yes, you have made the correct fix. Now let me explain why. I will try to be very detailed so forgive me if I walk at too low of a level.
You see... at the very root it all has to do with Protected Mode[^] and how the operating system handles virtual addresses. When you load a resource, naturally the operating system needs to know where this resource is located in memory before you can use it. Normally if the resource is located in the executable you can simply pass AfxGetInstanceHandle() and at the lower levels the translation lookaside buffer[^] looks for the location for your processes virtual address. If there is a TLB-miss then it would have to access the page table to find this physical memory offset.
Essentially what I am saying is that AfxGetInstanceHandle() is nothing more than the module base address. These addresses are used for finding the resource.
You can see this by doing the following experiment:
#define MyGetInstanceHandle((HINSTANCE)&__ImageBase)
You can do something similar inside the DLL to see that all your actually passing is the module base address:
__inline HINSTANCE MyGetResourceHandle(LPCTSTR lpModuleName)
{
HINSTANCE h;
GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS, lpModuleName, &h);
return h;
}
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks for the detailed feedback!
/Moak
|
|
|
|
|
That's all cool info, but how does it affect the failed creation of the window using the OP's registered
window class?
Thanks,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Moak explained that he was creating a resource-only DLL[^] for his dialogs and other misc resources. How can you instantiate a dialog if you cannot locate the dialog resources. The WNDCLASS structure is populated with information from the resource section. Therefore his call to GetClassInfo() failed.
AfxGetInstanceHandle() will return the base address of MyApplication.EXE
AfxGetResourceHandle() will return the base address of MyModule.DLL
So when he used AfxGetInstanceHandle() the window creation failed because it was searching for the dialog resources in MyApplication.EXE when they were actually located in MyModule.DLL
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Therefore his call to GetClassInfo() failed.
That's the part I was missing!
Thanks man!
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
