c++

Pages: 1234
closed account (3qX21hU5)
Its much easier to use watches and step through the code then to write and delete a while bunch of cout statements just to see what a value is... so no not every programmer does that cause I know I don't.
Last edited on
^ This.
Zereo wrote:
Its much easier to use watches and step through the code then to write and delete a while bunch of cout statements just to see what a value is...

Think defines....much easier to wrap the cout statements in defines and then define it so it compiles with the cout statement acknowledged and once you have it 100% done just remove or comment out #define MYDEBUGS and call it a day.
BHXSpecter wrote:
Yes. IDEs only bypass the commands, and only give you the most common commands by default. If you want to run other tests you have to either go in and add them every time you realize you need a new (assuming your IDE allows you to edit them) or you can open the terminal and punch in the commands you think of without having to stop to tweak your IDE to add the new shortcuts.
What are you talking about? Every debugger interface I've used has breakpoints, watch windows, stack traces, etc... available by default. What "tests" are you referring to?


Then every programmer is a poor man because that is the normal for all error testing in code.
I'll admit I may not know many professional programmers but I have a pretty good feeling your wrong about this.

@DTSCode
There is absolutely nothing wrong with not using an IDE, but not using a debugger is insane. You may not have needed one yet, but sooner or later you will and you will wish you learned how to use GDB before you needed it.
Last edited on
Or you don't even have to recompile and you can simply just run it with breakpoints and check the values of your variables.
BHXSpecter wrote:
I agree that using the tools properly is key, but I feel that productivity ultimately is the programmer and not the tools. If the programmer is lazy they aren't going to be productive no matter what tools you give them.


This just doesn't jive with me. Tools matter.

A car mechanic (even a lazy one) will be more productive with power tools than with manual tools. Effortlessly pressing a button to drive in a bolt vs. manually ratcheting a bolt into place makes the difference of a job taking 5 minutes vs a job taking an hour.

Programming is no different. If you have to do everything manually, it would take forever.

We use tools like makefiles to automate builds. We use tools like intellisense and syntax highlighting to clarify code. We use tools like debuggers to fix logic errors.

All of it aids in productivity.

To claim that tools do not make programmers more productive is just simply not true. I suspect you make that claim because you do not know how to effectively use the tools in question.

DTSCode wrote:
and narrow it down through printf/cout tests


Breakpoints + Watch is just about in every way superior to cout tests.

Process with cout tests:
=============
1) Stop the program if it's already running
2) Change the code to log whatever variables you think you need to see
3) Rebuild
4) Rerun the program and recreate the bug
--- if you need to see more variables Repeat steps 1-4
5) Fix bug in code
6) Go back and remove all added cout statements.


Process with breakpoints & watch:
=============
1) Set a breakpoint on the line of code where you want to examine execution
2) Recreate the bug in the program
3) Add whatever variable you want to see to the Watch
--- if you need to see more variables, repeat step 3
4) Fix bug in code



One is clearly more efficient than the other. Especially if you forget to remove a cout log. Or if you keep thinking of more and more variables you want to examine (when adding one requires a rebuild.. and if a rebuild takes a full minute... you could easily be wasting 5 minutes doing absolutely nothing)

Not to mention breakpoints + StepInto/StepOver let you step through and examine the program at every single line of code. Dumping to cout only lets you examine the program wherever you decide to put the log statements.


BHXSpecter wrote:
IDEs only bypass the commands, and only give you the most common commands by default. If you want to run other tests you have to either go in and add them every time you realize you need a new (assuming your IDE allows you to edit them) or you can open the terminal and punch in the commands you think of without having to stop to tweak your IDE to add the new shortcuts.


Can you give me an example of a debugging feature that is not available by default in whatever IDE you're referring to?
Last edited on
naraku9333 wrote:
What are you talking about? Every debugger interface I've used has breakpoints, watch windows, stack traces, etc... available by default. What "tests" are you referring to?
Disch wrote:
Can you give me an example of a debugging feature that is not available by default in whatever IDE you're referring to?

As far as I know, all debuggers use the older debugger commands and none have the new reverse-debugging stuff that was added in GDB 7 (think that is the version) so I have to add it to each IDE I end up using. (http://www.gnu.org/software/gdb/news/reversible.html)

As for MSVC, last I read, MSVC++12 doesn't support C++11 at all unless they finally got around to patching it.

naraku9333 wrote:
I'll admit I may not know many professional programmers but I have a pretty good feeling your wrong about this.

That is the whole idea behind running a 'debug' console in a game or terminal window when testing things in a different app that outputs data while it runs to watch variables.

For example,
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <iostream>
using namespace std;
//#define DEBUG  // comment out to disable debug code
int main(){
	int x = 0, y = 0;
	while (x != 20){
		x++;
		y = x * 2;
		cout << "X: " << x << endl;
		#ifdef DEBUG
			cout << "Y: " << y << endl;
		#endif
	}
	return 0;
}

The cout << "Y: " << y << endl; line will only print if you either uncomment #define DEBUG or pass it in the compile line -DDEBUG to make it print. In college, we even learned how to use boost and another lib for creating a game with a debug console to watch values in our test games.
Last edited on by closed account z6A9GNh0
closed account (Dy7SLyTq)
or you know
#define TEST_ cout<<"line "<< LINE << endl;

//code
TEST_

then later just
#define TEST_ /**/
What if you decide you want to view another variable? Then you'll have to recompile.
closed account (Dy7SLyTq)
you mean i have to spend a whole five seconds recompiling? i understand that perfectly well fred.
closed account (3qX21hU5)
You might not understand it now when your compiling only takes a few seconds but wait until you get to larger projects then you will understand why people hate recompiling.
BHXSpecter wrote:
As far as I know, all debuggers use the older debugger commands and none have the new reverse-debugging stuff that was added in GDB 7 (think that is the version) so I have to add it to each IDE I end up using.


Okay. Admittedly I'm not as familiar with GDB as I could be, so I'll take your word on this.

But I still fail to see how you could be more productive by not using GDB (a tool) at all.

As for MSVC, last I read, MSVC++12 doesn't support C++11 at all unless they finally got around to patching it.


2012's support for C++11 is maybe around 80% complete. The only things I can think of that it's missing (that I've wanted to use but aren't there) are initializer lists, constexpr, and <thread>.

Even 2010 had partial C++11 support.

So it's better than you give it credit for... but admittedly it's still lacking.

DTSCode wrote:

or you know
#define TEST_ cout<<"line "<< LINE << endl;

//code
TEST_

then later just
#define TEST_ /**/


Or you know...

[press F9]



I don't know how you can debate that modifying the code is easier than setting a breakpoint.

Besides... if you litter your code with a bunch of TEST_ macro calls that you don't remove to hunt down one bug... what do you do for the next bug? Do you use TEST_ again and then get dumps for all the bugs you previously worked on (instead of just the one bug you're interested in)? Or you do create TEST_2? TEST_16?

And talk about a maintainability nightmare. How would you like to work with someone else's code where there's some TEST_ macro every 10 lines?


And logging CPU execution with a simple line dump is one thing. Examining the program state (ie: contents of all variables, the call stack, execution point/vars/stacks in all other running threads) is another.



I really think that anyone who thinks debuggers aren't worth using just hasn't actually used one.
Last edited on
*facepalm*

@Fredbill30 My method makes it so you could output every variable in a table format if you wanted for the entire program like it was a spreadsheet.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#include <iostream>
#include <string>
using namespace std;
#define DEBUG  // comment out to disable debug code
int main(){
	int x = 0, y = 0, iteration = 0;
	bool yoMomma = false;
	string strLines = "Debug testing!";
	#ifdef DEBUG
		 cout << "X\t\tY\t\tJoke\t\t\tStrings\t\tIteration\n";
	#endif
	while (x != 20){
		x++;
		y = x * 2;
		//cout << "X: " << x << endl;
		#ifdef DEBUG
			iteration++;
			cout << x << "\t\t"
                 << y << "\t\t"
                 << yoMomma << "\t\t\t"
                 << strLines << "\t   " << iteration  << endl;
		#endif
	}
	return 0;
}
BHX: yes but then you have to stop/recompile/rerun/retrigger the bug in order to get all the new vars.

Whereas in a watch window you can just add/remove vars on demand.
@Dish I never had to. That example shows a simpler form of my method. I use file io so that everything is constantly put to a log and when my app crashes I go straight to the log where I have my data in spreadsheet format to scan through to see the changes in variables. Only then do I mess with the debugger so I can change data to see why it is crashing.

If you are wanting to use a debugger you have two options with GDB7 though. You can do the normal method and when a program crashes, set a breakpoint where you think the crash is and then single step the code up to the crash. On the other hand you can use the reverse debugging that runs up to the crash and then lets you step backwards through the code to find it (I've only used this a few times but like the second one better).

As far as I know, if you use any other debugger you are stuck with the tried and true method of stepping one line of code at a time toward the bug.
Just admit that using a manual debugger is less productive than VC++'s.

Really. That's like saying a solider shooting a musket is just as effective as a solider using a m4.
Fredbill30 wrote:
Just admit that using a manual debugger is less productive than VC++'s.

Actually it's not. See with using a debugger you would have to guess where the crash is and step through until you hit crash again while with manual debugging (especially to log files) when the program crashes the log file will end at the crash or have a spike in the variables data it holds so it will actually give you quicker idea of where the crash is to start using a debugger on. Why else do you think so many companies that offer support have tools or commands in their programs that print out data they can use to solve the problem? DX has diagnostic tools to help pinpoint where their code is crashing on your configuration, some games have a very similar setup where when the game crashes it outputs a file that explains what the application was doing at the time of the crash. Think google even has a service that you can use that effectively does the same thing, collects data for when you application crashes on another computer and then sends it to your email so you can figure out what happened.
BHXSpecter wrote:
See with using a debugger you would have to guess where the crash is and step through until you hit crash again


No you don't. When you crash while running a debugger the debugger snaps at the exact line it crashed on. Can instantly see where it crashed and the contents of all variables at the time of the crash.

Infinite loop? Just hit "Break All" and the debugger will snap in the loop, and you can see why it's stuck.



All of that said... you're right that debug logging can be useful, especially for remote debugging. But that kind of logging is different from the kind of debugging I'm talking about.
BHXSpecter wrote:
Why else do you think so many companies that offer support have tools or commands in their programs that print out data they can use to solve the problem? DX has diagnostic tools to help pinpoint where their code is crashing on your configuration, some games have a very similar setup where when the game crashes it outputs a file that explains what the application was doing at the time of the crash. Think google even has a service that you can use that effectively does the same thing, collects data for when you application crashes on another computer and then sends it to your email so you can figure out what happened
I would say this is useful for generating crash reports on end user systems, not debugging locally.

You have mentioned several times the only programming you do is small toy programs. Maybe none of your projects have been large enough to show the failings of that type of debugging (couts not GDB).


But in the end, too each his own.
Last edited on
@Dish
I should point out the methods I use is what I was taught when I was in college. We were encouraged to do debugging logs, use the debugger in junction with the logs, and in the game related courses we had to use in-game debugging consoles to watch data. Guess I'm just set in my ways, which were solidified even more for me when I read that idSoftware used almost identical methods for their games and found out that Ed Boon used similar methods when making Mortal Kombat.

I use all the methods: logs, debugger, and valgrind when I do anything (like a simple particle system I made the other day). Ran fine, but found out I forgot to initialize the variables to 0 so I was getting memory crashes, which valgrind found after the debugger and logs showed nothing. Only clue I had was terminal would give errors about a lib.

DeVry instructors, at the time I was there (don't know if they still are), had use us debugging things that didn't even need debugging with both methods (they even had use us debug the Hello World program with both methods). Used to joke with my wife that I was going to have nightmares about debugging.
Last edited on by closed account z6A9GNh0
Pages: 1234