- #1
Israr Ahmad
- 3
- 0
I want to know what kind of programs can be debugged and how to do this?
YES, I want to learn computer programming.DaveC426913 said:That is an extremely broad question.
The short answers, in order, are:
- all of them and
- by myriad methods, depending on the language and tools available.
Perhaps you could refine your question a little.
Do you want to learn computer programming?
Do you have some source code that you want to fix?
Do you have a particular language in mind?
What kind of software do you want to write? This will influence what language you choose, which will in turn influence what books you might buy to read.Israr Ahmad said:YES, I want to learn computer programming.
I want to learn C++.DaveC426913 said:What kind of software do you want to write? This will influence what language you choose, which will in turn influence what books you might buy to read.
Welcome to the PF.Israr Ahmad said:I want to know what kind of programs can be debugged and how to do this?
Well, yeah, if you're using the OOP characteristics of C++ but I've always thought that the BASIC difference between C++ and JAVA is that in JAVA you have no choice about whether you are using OOP whereas in C++ that is not enforced. Code can be written in "C++" that really is just C code. You can't do that in JAVA.jedishrfu said:The basic difference between Java and C++ is in class inheritance where C++ allows for multiple parents whereas Java limits it to one but multiple inheritance is seldom used.
phinds said:Well, yeah, if you're using the OOP characteristics of C++ but I've always thought that the BASIC difference between C++ and JAVA is that in JAVA you have no choice about whether you are using OOP whereas in C++ that is not enforced. Code can be written in "C++" that really is just C code. You can't do that in JAVA.
#include<iostream>
int square( double x){
//returns square of number x
return x*x;
}
int main(){
double sqx = square( 2.0 );
std::cout<< sqx << std::endl;
return 0;
}
I still do this. I'm old school. It actually cost me a potential job. Employer was not impressed to see me debugging using console.log (JavaScipt equivalent of Print)fluidistic said:0) Lots of print statements. I have to make sure what I Think the code is doing is really doing it.
Sometimes the equivalent of print is the only debugging tool available. About four years ago I was trying to write some code samples for SharePoint (a MSFT product), and my code was running against a SharePoint server running on a cloud OS, that would send back a stream of text to populate a web page. For quite a while I wasn't getting anything back, and couldn't figure out any way to set a breakpoint on the server. (There probably is a way, but a fair amount of study on my part didn't unearth it.) My solution was to insert output statements throughout my code, and determine what part of my code was working and where it stopped working by the output I got. Once I figured out where my output statements weren't being hit, I could focus my efforts there and figure out why. After a number of iterations using this process, I was able to get my code working correctly.DaveC426913 said:I still do this. I'm old school. It actually cost me a potential job. Employer was not impressed to see me debugging using console.log (JavaScipt equivalent of Print)
If it was solely because of that, the guy was an idiot anyway. I'm a professional programmer and I've worked with dozens of other great experts. Everybody does cout, prints, var_dump...DaveC426913 said:I still do this. I'm old school. It actually cost me a potential job. Employer was not impressed to see me debugging using console.log (JavaScipt equivalent of Print)
The modern way is to use breakpoints and step through the code, to watch what is happening as it happens.
DaveC426913 said:I still do this. I'm old school. It actually cost me a potential job. Employer was not impressed to see me debugging using console.log (JavaScipt equivalent of Print)
The modern way is to use breakpoints and step through the code, to watch what is happening as it happens.
newjerseyrunner said:If it was solely because of that, the guy was an idiot anyway. I'm a professional programmer and I've worked with dozens of other great experts. Everybody does cout, prints, var_dump...
For me, doing a bunch of variable dumps in real time allow me to intuit the problem far faster than setting breakpoints and stepping could ever.
What would that mean in practice?DaveC426913 said:The modern way is to use breakpoints and step through the code, to watch what is happening as it happens.
DaveC426913 said:The modern way is to use breakpoints and step through the code, to watch what is happening as it happens.
If you insert a breakpoint into your code, and run your code (in a debugger), the program will halt at the breakpoint. The debugger typically will have other windows/panes you can open to see the values of variables, memory, the stack, and many other facets of your program.ChrisVer said:What would that mean in practice?
If you;'re doing web dev, your browser should allow you to open the JavaScript (or whatever) in the browser, and place breakpoints in it (a feature of the Developer tool). Then you serve up the page, and it will stop at the given line, allowing you to test the value of your vars at that moment. Other languages (such as C#) have other developer tools (such as Visual Studio), that allow the same kind of walk-through.ChrisVer said:What would that mean in practice?
No, it wasn't just that. I sort of froze when it came to debugging while they were shoulder-surfing.ChrisVer said:I agree with the others : you were lucky to avoid such an employer...
hmm I guess I should start using some IDE... so far I have been working with codes using vi and text editors... I didn't have the chance to work with any kind of debugger efficiently...Mark44 said:If you insert a breakpoint into your code, and run your code (in a debugger), the program will halt at the breakpoint. The debugger typically will have other windows/panes you can open to see the values of variables, memory, the stack, and many other facets of your program.
Using an IDE is convenient, but you really should be using a debugger, some of which are standalone, not connected with an IDE. Anyone writing code these days who doesn't use a debugger is not working efficiently.ChrisVer said:hmm I guess I should start using some IDE... so far I have been working with codes using vi and text editors... I didn't have the chance to work with any kind of debugger efficiently...
No, the Real Programmer wants a `you asked for it, you got it' text editor -- complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise.
DaveC426913 said:The modern way is to use breakpoints and step through the code, to watch what is happening as it happens.
is valgrind good for debugging? I thought it was for memory control... (so maybe for hunting seg faults?)newjerseyrunner said:valgrind
It's not a debugger in the same way that gdb is, but it's invaluable for hunting multi threading and weird memory bugs.ChrisVer said:is valgrind good for debugging? I thought it was for memory control... (so maybe for hunting seg faults?)
newjerseyrunner said:valgrind
The first step in debugging a program is to identify the problem or error. This can be done by carefully reading any error messages or examining the code for any obvious mistakes. It is also helpful to have a clear understanding of the program's intended functionality.
There are many tools available for debugging programs, such as debuggers, code editors, and IDEs. Some popular options include Visual Studio, Eclipse, and Xcode. These tools offer features such as breakpoints, step-by-step execution, and variable inspection to help identify and fix errors.
Preventing bugs in code is an important part of the debugging process. Some strategies for preventing bugs include writing clear and organized code, testing code regularly, and using version control to track changes. It is also helpful to get feedback from others and to thoroughly test the program before releasing it.
A successful debugging process results in the program running without any errors or unexpected behavior. It is important to thoroughly test the program after making changes and to check for any new errors that may have been introduced. It can also be helpful to get feedback from others to ensure the program is functioning as intended.
Debugging is a skill that can be improved with practice. Some ways to improve include studying and understanding common programming errors, learning how to effectively use debugging tools, and seeking feedback and guidance from more experienced programmers. It is also helpful to reflect on the debugging process and identify areas for improvement.