The notorious "Unhandled exception"
Author
Being totally new in c++ programming (and programming at all) I put the simplest code in Visual Studio 2005:
#include <iostream>
#include <ostream>
int main()
{
std::cout << "Hello, world!" << std::endl;
return 0;
}
and it gives me the mistake:
Unhandled exception at 0x7c942db4 in dima.exe: 0xC0000005: Access violation writing location 0x00040ffc.
It gives me the exact same error when I try to run this:
#include <iostream>
int main()
{
char a;
char b;
char c;
a = 'D';
b = 'N';
c = 'A';
std::cout << a << b << c;
return 0;
}
Can someone please tell me what I'm doing wrong?
Thanks!
what version of visual studio? express/standard/pro? what OS? if vista, did u update to SP1 Vista? what steps did u take to make your project? you just made a simple console application? you didn't check any funky application settings or anything (like check MFC or ATL for a console app)?
Quote:Original post by Antheus
Shouldn't main() have 2 parameters?
The command line args are optional.
Your code should be fine. But get into the habit of using the debugger when you get an error like this - it should show you what part of the code is causing the problem.
Author
I'm using Microsoft Visual Studio 2005 Professional edition.
My OS is Windows XP Pro and I do have SP2 on it.
Creating the project, I created an CLR empty project and the files I created in Source Files folder are .cpp
And it doesn't show me where the mistake in the code is. When I simply build or compile the program, it is done successfully, but when I debug it, it gives me the error that I mentioned above (maybe the code of the error indicates where the mistake is?). Also, if I toggle a breakpoint on the first line of the code, it gives me the same errror again and it doesn't stop at that breakpoint saying "The breakpoint will not currently be hit. Invalid file line:1". The code of the error is always the same...
My OS is Windows XP Pro and I do have SP2 on it.
Creating the project, I created an CLR empty project and the files I created in Source Files folder are .cpp
And it doesn't show me where the mistake in the code is. When I simply build or compile the program, it is done successfully, but when I debug it, it gives me the error that I mentioned above (maybe the code of the error indicates where the mistake is?). Also, if I toggle a breakpoint on the first line of the code, it gives me the same errror again and it doesn't stop at that breakpoint saying "The breakpoint will not currently be hit. Invalid file line:1". The code of the error is always the same...
Mainly I meant that when it gives you that exception, it typically offers you the chance to debug it, at which point you can see exactly where it's broken.
I can only suggest you attempt a full rebuild, as sometimes things get corrupted. Failing that, you may need a fresh install. It might be something to do with the CLR or .NET (can you switch to an unmanaged or native project?) but I'm not qualified to advise on that.
I can only suggest you attempt a full rebuild, as sometimes things get corrupted. Failing that, you may need a fresh install. It might be something to do with the CLR or .NET (can you switch to an unmanaged or native project?) but I'm not qualified to advise on that.
Author
Ok, I reinstalled the whole thing. Now it gives no errors but I don't know how to see what my program looks like.
For example, the second program should put "D N A" on the screeen. Where can I actually see the result of my program?
For example, the second program should put "D N A" on the screeen. Where can I actually see the result of my program?
Quote:Original post by Dimamid
Ok, I reinstalled the whole thing. Now it gives no errors but I don't know how to see what my program looks like.
For example, the second program should put "D N A" on the screeen. Where can I actually see the result of my program?
Run with debugging, putting a breakpoint at the "return 0;" line.
Or navigate to the folder containing the executable in the windows command shell and run it.
Put a breakpoint on the return statement and run the program through the debugger. That will allow the console window to stay open long enough for you to see the results.
Console programs are meant to be run from the console: i.e. the DOS window where you type things to make them run. You program spawns an instance of the console window and closes it when it's done. This all happens faster than you can see it. Hence, place the breakpoint.
-me
Console programs are meant to be run from the console: i.e. the DOS window where you type things to make them run. You program spawns an instance of the console window and closes it when it's done. This all happens faster than you can see it. Hence, place the breakpoint.
-me
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
