Let\'s talk a bit about debugging. As you all have experienced by now, there are
ID: 3589028 • Letter: L
Question
Let's talk a bit about debugging. As you all have experienced by now, there are a lot of things that can go wrong in a C++ program. Over time, effective programmers develop a good sense of where to look for problems.
So let's identify the kinds of things that can go wrong and where to look for them. Please post a discussion point about a specific bug that can occur in C++, and how you think a programmer can best identify those problems. There are a range of things, from simple syntax issues to more subtle problems. Please identify ONE problem.
Explanation / Answer
in c++ so many comman mistacs are raised
some are
most compilers will give three types of compile-time alerts: 1.compiler warnings
2.compiler errors
3. linker errors.
compiler error example
This would create a variable, myStruct, with room to store a struct containing two integers. Unfortunately, this means that if you leave off a semicolon, the compiler will interpret it as though the next thing in the program is intended to be a struct (or return a struct). Something like this
can result in an surprising number of errors (possibly including a complaint about an extraneous "int" being ignored). All this for a single character! best to start at the top.
linker error
Once you've finally cleaned up all those frustrating syntax errors, taken a nap, had a meal or two, and mentally prepared yourself for the program to build correctly, you may still need to deal with linker errors. These can often be more frustrating because they aren't necessarily the result of something written in your program. I'll briefly cover some of the typical types of linker errors you can expect and some of the ways to fix them.
You may have issues with how you set up your compiler. For instance, even if you include the correct header files for all of your functions, you still need to provide your linker with the correct path to the library that has the actual implementation. Otherwise, you will get "undefined function" error messages. Be careful that your compiler doesn't actually support these functions at all (this could happen if you include your own declaration of a function to get around a compile-time error). If your compiler should support the function, then fixing this problem usually requires compiler-specific settings. You'll generally want to look for how to tell the compiler where to look for libraries and make sure that the libraries were actually installed correctly.
Linker errors can also come about in functions that you have declared and defined if you fail to include all of the necessary object files in the linking process. For example, if you write your class definition in myClass.cc, and your main function is in myMain.cc, your compiler will create two object files, myClass.o and myMain.o, and the linker will need both of them to finish the creation of the new program. If you leave out myClass.o, then it will not have the class definition even if you correctly included myClass.h!
A sometimes subtle error is when the linker complains about there being more than one definition for a class, function, or variable. This issue can come up in one of several ways: first, there might actually be two definitions of an object--for instance, two global variables both declared as external variables to be accessible outside of the source code file. This is a legitimate concern for both functions and variables, and it definitely can happen. On the other hand, sometimes the problem is with the directives to the linker; on more than one occasion, I've seen people include multiple copies of the same object file in the linking process. And bingo, you've got multiple definitions. A typical giveaway for this problem is that a whole host of functions have multiple definitions.
The great thing about compiler warnings is that they are often indicators of future bugs that you would otherwise see only at runtime. For instance, if you see your compiler complaining about an "assignment in conditional" then it might mean that you've written
when what you really meant was
you might have figured this out when your code always entered the if statement, but you wouldn't have known exactly why it was doing that. Maybe x wasn't being set properly (for instance, it might have been uninitialized). A scarier situation is one in which you never actually tested that branch of the if statement when x wasn't equal to five. This means that you would have a bug sitting in your code after you thought it was done. So the compiler warning both tells you exactly what is wrong and alerts you to a problem you might never have found!
Just for fun, here's an even more compelling example of when you'd have trouble finding the bug during testing.
Since x would generally not equal zero, the if statement generally wouldn't be expected to execute. Now, since x = 0 evaluates to false, this statement will always be false. If you never test the situation where x actually is 0, then you won't notice that the body of the if statement never executes
Catch Bugs that are Hard to Find in Testing
Compilers will always warn you about things that might be difficult to find during testing. For example, your compiler can warn you that you are using an uninitialized variable; this can be hard to find in testing if you declare your variable far from the spot you first use it. (Note that "using" an uninitialized variable simply means getting its value; it's perfectly fine to initialize it. In fact, that's the solution to the problem.)
Another insidious bug is forgetting to return a value from a function. Sometimes this can be tricky to spot even once your compiler points it out. This might happen when your function has multiple paths through the code and most of them return a value; it's left up to you to find the one that doesn't.
Notice that most of the time, this function will return a value. It's only when the value isn't in the array that you wouldn't find it. This bug can be hard to spot in later testing both because this may be an uncommon occurrence and because the results of not returning a value when one is expected can be extremely weird. For instance, you might get a valid index of the array, or you might get something way too big (more likely). In either case, the problems in the running program wouldn't appear in the function at all.
HOPE MAY IT HELP YOU
THANK YOU
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.