ok first number output. sometimes you have to make several lines that output the same string of text say for a message box or for cout. sometimes (happened to me tonight infact) you get several lines being outputted because of a bug errrr.. random occurance in your program. so if you put a unique number at the end of each line to fix it you can tell where the problem is. another tip i have been doing lately is say i need to paste a few things i got online for offline use. (i do most of my programming when im offline) i make a deleteme.txt file otherwise i get a ton of files in a short amount of time. and it says deleteme you delete them so you dont have tons of accumulated junk.(or you at least use the same file)

Along the lines of tip #1, rather than just append a number I would recommend always having your error messages be like this:

So that you know exactly where they are coming from. MessageBeep(0); can also be very helpful in a similar way.

You mean:

Well that's way to much tiping in my eyes. I would prefere spending on real programming (and not debuging <_< ).

I normaly only include 1 error message in the whole program so I exactly know where it is :D and once it's working I remove it.

what I do is make for each error that could occur in each class an error msg

for example:

this way you immediatly identify the location of the error
especialy usefull with highly nested classes

Real programming IS debugging! In a large program, you MUST have debugging code. Both for your own benefit and so you can find out what is wrong on the user of your programs computer. It is much faster if you #define a macro like this:

Then you should just be able to say:

Incubator, errno is a C relic that has no more use in C++ except using the standard C library. Use a return code or exception handling.

btw it's kind of odd to have a class try to print out it's own error information. Typically they simply do something (return code, exception handling, etc.) to change the environment upon an error so that the calling code can check for the error that are likely to occur.

Depends on the size of the program. When I write a program and have lots of bugs then I often rewrite it faster (bugfree) than debugging the original code because I then know what can cause which problems.

yes, i guess you´re right. some bad habit i picked up by doing too much VB where I needed to use err.raise (wich displayed an error box that crashed your prog) I found that a bit strange and simply used printf´s where ever an error could occur.

Yes. Definetely. In a very small (<1000 lines) program, I usually don't put in debug stuff. If it's any longer it would just be too much of a pain to rewrite error-free.