comment/uncomment

hi
i want to comment and uncomment all printfs and couts in C/C++ files. is there any tool to do this

sunil

If you mean within your own project, I'd suggest simply using find + replace (Ctrl+H in visual studio) and replacing all occurences of printf with //printf and vice versa.

write your own :).

It's a little ugly but the way it is often done is to wrap all your debugging statements in pre-processor #IFDEF blocks thus...

Code:

---

#DEFINE DEBUG
...
...
#IFDEF DEBUG
cout << SomeVariable << endl;
#ENDIF

---

... shows the debug value...

Code:

---

#UNDEF DEBUG
...
...
#IFDEF DEBUG
cout << SomeVariable << endl;
#ENDIF

---

... switches them off. You could also use a variable of suitable scope, but that means the program is testing at run time rather than compile time, so would be slower, it does, however, give you the opportunity to turn debugging on and off at run time which is sometimes useful.

Instead of using compiler switches directly, like adrianxw gave, you could also use a macro. In some headerfile for example define:

Code:

---

#define DEBUG 1

#ifdef DEBUG
#define TRACE(d) cout << d << endl;
#else
#define TRACE(d)
#endif

---

Now the macro TRACE is replaced by the cout statement. When commenting out the define of DEBUG, the macro TRACE is replaced by nothing. If you want to do this on file level, you should remove the define of the DEBUG in the headerfile and define the DEBUG switch in each file before including the headerfile.

Putting the conditional directives in the code allows you to decide what you want to put in your debugging section as you are writing your code, you do not need to think of how the macro is written. In all but the most trivial applications, cout/printf is not enough, you will want to post messages, throw up messageboxes, log to trace files and so on.

A brief comment about Shiro's macro.

You might want to right it as follows:
#define TRACE(d) cout << (d) << endl;

Since a macro simply replaces code before compilation, an operator of low-enough precedence could cause problems there (which the extra parentheses fixes)... Other than that though, the debug macros are probably your best bet.

Quote:

---

Originally posted by adrianxw
Putting the conditional directives in the code allows you to decide what you want to put in your debugging section as you are writing your code, you do not need to think of how the macro is written. In all but the most trivial applications, cout/printf is not enough, you will want to post messages, throw up messageboxes, log to trace files and so on.

---

Well, what about:

#ifdef _DEBUG
#define DBG_(d) d
#else
#define DBG_(d)
#endif

It puts no qualifiers on what can be within the macro (and it has no dependance on any headers).

So you could do things like DBG_(::MessageBox(hwnd,"Message","Debug",IDOK));

or really anything you wanted.

Yes Cat, but suppose I want values. Then I have to use sprintf() or strcpy() etc., possibly several times, before I have a buffer which contains the actual debug information I wish to present at that point. I'll end up with a bunch of code inside the brackets which simply looks weirder than having a clearly delimited #IFDEF/#ENDIF pair.

That is my opinion of course, anyone is welcome to do things whatever way they like.

Of course in a professional software house, there will inevitably be installation standards which dictate how you do it.

Well, it's not THAT hard to do multiline stuff; e.g.:

Code:

---

    DBG_(
        std::cout << "Test" << std::endl;
        std::cout << "Line2" << std::endl;
        std::cout << "Line3" << std::endl;
        std::cout << "Line4" << std::endl;
    )

---

Sure, it seems a little odd, what with the ( and the ), but it's pretty easy to read and understand.

Although, I like this a little better:

#ifdef _DEBUG
#define DBG_(d) {d}
#else
#define DBG_(d)
#endif

because it creates a new scope for variables, which minimizes the impact that the debug has on the main program. Otherwise one could accidently declare a variable inside a debug statement and use it outside that debug, which is dangerous because it works. Until you build a release version.

>>> it's not THAT hard to do multiline stuff

I didn't say it was hard, I said it looked weird. The pre-processor directives are fairly standard. Someone coming to maintain my code would know what I was doing. Without checking, they would not with yours.

Whatever, the questioner was asking for suggestions, now s/he has several.

>>> declare a variable inside a debug statement

!