what is difference in compiling and debugging.

[vkash]

How compiling is different from debugging.

[VictorN]

Almost the same way as dressing is different from walking.

[GCDEF]

How compiling is different from debugging.

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.

[vkash]

Almost the same way as dressing is different from walking.

what do you mean? please answer in c++ way not in metaphorical way.

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.

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)

.

[GCDEF]

what do you mean? please answer in c++ way not in metaphorical way.

[quoue=GCDEF;2021236]
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.

does logical errors remain in code if that is compiled not debugged.

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 their executive file and other files.(I think no change in .exe file)

.

What the executables look like depends on the project settings you have selected, not whether you press whether you press F5 or ctrl+F5. The differences is one will run the program in the debugger and the other won't.

[Igor Vartanov]

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.

Well, in not metaphorical way please give us definitions for compiling and debugging as you understand those.

[Alex F]

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.

[vkash]

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.

then answer it.
I am waiting for a good reply.

[GCDEF]

then answer it.
I am waiting for a good reply.

I've answered you twice. What else do you want?

[Lindley]

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.

[Alex F]

then answer it.
I am waiting for a good reply.

Starting 6 letters are different.
Good enough?

[John E]

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.

[Arjay]

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.

[ProgramArtist]

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

[vkash]

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.