How compiling is different from debugging.
Printable View
How compiling is different from debugging.
Almost the same way as dressing is different from walking. :cool:
Are you serious? What do you think the difference is?
I'll give you a quick answer. Compiling (and linking) is the process of converting the code you have written into an executable program. In order to compile, the code must be free of syntax errors. That is, your code has to follow the rules of the language.
Being free of syntax errors is absolutely no guarantee that the program works correctly or does what you want it to. Debugging is the process of finding and removing logic errors and making the program behave correctly.
what do you mean? please answer in c++ way not in metaphorical way.
does logical errors remain in code if that is compiled not debugged. :Lightbulb:
consider this condition
I make two projects project1 and project2 (same as project1) now I put same code in both. In first code i press Ctr+F5 (start without debugging) and in second code i press F5 (start debugging). Will there any difference in .exe file and other files of project1 and project2.(I think no change in .exe file)
.
The first thing I can think about, is that starting 6 letters are different.
However, looking at your second post, I guess you wanted to know the difference between Run and Debug commands. At least, such question may be answered.
Coding errors fall into two general categories: compile-time errors (missing semicolons, misspelled variables, incorrect parameter types, etc) and runtime errors (segfaults, unexpected program behavior, null pointer dereferences, etc).
One of the big advantages of taking a type-safe approach to programming is that it shifts some errors which would have only appeared at runtime so that they are detectable as compile time errors. Compiler errors are much easier to pinpoint and fix than runtime errors.
However, there are plenty of ways in which your program can crash or otherwise not behave the way you want it to, despite compiling. Debugging is the catch-all word for finding and fixing these mistakes. One of the most common tools to help with debugging is a debugger, which allows you to pause execution of the program at various times ("breakpoints"), examine variable values and call stacks, and even modify some variables if you wish.
Think of compiling as being similar to the process of building a car. The first time you build it, the windscreen might leak, the wheels might be out of alignment, the engine timing might be a bit rough and there might be a few serious problems - like you forgot to fit the brakes, or you accidentally poked a hole in the radiator but didn't notice. Or you couldn't quite find the right bolt for something so you needed to fit a temporary one until the correct one comes into stock. So when you go for your first drive in the car it might not work exactly as you'd hoped.
Now think of debugging as being similar to the process of putting all those problems right and making the car run exactly how you'd envisaged it.
Here's a simple code way to determine the difference.
Say you have a integer that holds the value of 100 and you want to display the value to a user (console, GUI app, it doesn't matter).
Say you want to access the integer value through a pointer.
Now say you forgot to set the pointer to the address of the integer (so the pointer was uninitialized or set to NULL).
So the program will compile fine.
However, when you run the program (or debug the program), the program will crash because derefencing the pointer to get the integer value will cause the program to crash.
There are some IDE commands to compile and to start your executable.
(just a little bit simplified I know...)
F5: start debug:
(1) if needed compiles your source code (create some temporary and a .obj file for each .cpp file)
(1a) succeeded links the executable file together (put all the pieces to one .exe or .dll file)
(2) starts a tool called "debugger" which then will start your executable.
This tool is capable of controlling the execution of your exe (which is not so if you start it without debugging): It can execute it step-by-step, it can show values of variables, the stack and much more.
Ctrl+F5:
does the steps (1) and (1a) if needed/possible exactly as "F5"
(2) starts the executable (not the debugger tool).
How your executable will be build depends not on these two commands, instead it depends on the settings (like GCDEF told you alredy). Usually the settings for the "debug" build configuration are so that there is some extra code/information in your exe to make it possible to use the debugger tool to debug it. Nevertheless you can start such a "debug builded" exe without the debugger tool too. It is also possible for the MSVC IDE to start the debugger and load an alredy running executable.
If you "debug" an executable that has been compiled/linked without debug info (and there is no extra debug information file provided) then you can execute it "step by step" only in assembly mode and you won't see the names of all your functions, variables and other symbols.
Hope I made some things a bit clearer.
regards
PA
that is what i was trying to know. some days ago i use breakpoint in my VC++ this give information about working of code but only when i debug it not in case when i press Ctr+F5(as i usually do). this tends me to ask this question. Red region gives me correct information. brown region still does not come in my mind but let it go (it is seeming technical info). I will see such things when i will have better knowledge of computing in future.
thanks to ProgramArtist, GCDEF, Arjay, John E, lindley for their valuable replies.
Dear vkash,
Thx for your commendation but let me add a little bit to this thread.
In your original post you wrote:
Can you (now) see that you did not provide enough information to get the right answer?Quote:
Originally Posted by vkash
The sentence you gave is missing the question tag (In my codeguru-forum-question-analyzer this will produce a warning, but no error :)).
You asked for the difference between compiling and debugging. This question will be interpreted by other users not the way you intended. At least for people using the compiler, linker and debugger every day. Some of the users here (including myself) have been programing for such a long time that they do remember these old times, when there wasn't an IDE (Integrated Development Environment) available. You had to use a (stand alone) editor for creating/editing the source code. Then you started (manually) a program that compiled it, if it didn't write errors to your console you started the linker. The debugger (if there was one) had to be started manually these times too.
Later you could make your life easier using make files (especially in *NIX systems, but there were equivalents in DOS/Windows too).
Nowadays many of us use the IDE's which are multi-purpose-tools. They are resource editors, source editors, auto source ident tools, source analyzers, compilers. linkers and debuggers as well. They are used for project management too. The problem resulting from that comfort is that newer users often don't know the differences/meanings of compile, link, debug, run etc.
Back to your original post:
Try to be more detailed when questioning. Say what you want to achieve, what you want to know. "Will pressing Ctrl+F5 create the same executable then pressing F5? And if so what's the difference?" could be a better approach.
regards
PA
Man, not to offend, but the first thing you should really learn is how to ask questions to be given with the right answers. As your original question was absolutely and totally misguiding. Your interest was about IDE behavior while your asking was seemingly about abstract terms having very special meanings for programmers.Quote:
Red region gives me correct information.
But that isn't the answer to the question you asked originally. It is just that someone stumbled onto something you liked the answer to.
Compiling is the action of taking source code, checking to see if the source code follows the rules of the language being used. If the source code follows the rules of the language, the compiler usually creates an intermediate file (object code of some type). If the rules are violated, the compiler may issue some sort of error diagnostics about the violation in the syntax rules.
Debugging is a term used to take a running program and diagnosing any errors, logical inconsistencies, bottlenecks, etc. by using automated means (an interactive debugger for example), pencil and paper, or even by spotting logical errors in the code by plain sight.
That is the difference between compiling and debugging. Note that I mention nothing about linking, since you didn't ask about linking, only compiling and debugging.
Regards,
Paul McKenzie
first of all sorry for wrong method of asking question.
i think now i understood little meaning of VictorN's answer that is
he want to say that you dress before walking (get ready) similarly you compile code before debugging. Am i correct programmers.Quote:
Originally Posted by VictorN
for new persons who answer new question is
give me some detail on linking and other things(if they are). Knowledge in any technical field(which i can understand) is always welcomed by me.
when i pres Ctr+F5 this thing come in output windows
you have already told about compiling so tell about others.Code:------ Build started: Project: test, Configuration: Debug Win32 ------
Compiling...
main.cpp
Linking...
Embedding manifest...
Build log was saved at "file://e:\Users\Vikash Chandola\Documents\Visual Studio 2008\Projects\test\test\Debug\BuildLog.htm"
test - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
specially blue region.
debugging output window is somewhat difference following.
many files are loaded during the whole process what are these files(some files are seeming to be of windows OS).Code:'test.exe': Loaded 'E:\Users\Vikash Chandola\Documents\Visual Studio 2008\Projects\test\Debug\test.exe', Symbols loaded.
'test.exe': Loaded 'E:\Windows\System32\ntdll.dll'
'test.exe': Loaded 'E:\Windows\System32\kernel32.dll'
'test.exe': Loaded 'E:\Windows\System32\KernelBase.dll'
'test.exe': Loaded 'E:\Program Files\AVAST Software\Avast\snxhk.dll'
'test.exe': Loaded 'E:\Windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb\msvcp90d.dll'
'test.exe': Loaded 'E:\Windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb\msvcr90d.dll'
The program '[3184] test.exe: Native' has exited with code 0 (0x0).
during process even my antivirus is loaded why it was loaded. It has no relation with VC++ ? is it's my antivirus real time protection that let it to come here to test everything. (it's guess)
@Paul:
Sorry, I didn't want to criticise your reply. Just couldn't help to add "something" to that thread.
I just don't like responses like
orQuote:
Originally Posted by vkash
KurtQuote:
Originally Posted by vkash
That's because the antivirus is a bad kid who is looking at you trough the keyhole. ;)
In other words, it injects code in your process to monitor it.
Anyhow, try first to understand general programming concepts like:
Just looking "in the keyhole" (i.e. in the IDE windows), is not the best method to learn.