commenting out 'cout' using preprocessor macro

[qazmlp]

I hope comp.lang.c will not find the following question as a
complete off-topic.

I would like to remove ie.comment out the 'cout' statements during
compilation(actually preprocessing) time.


The statements like this:
cout<<"something\n" ;
should be made as
// cout<<"something\n" ;


I tried for the following. But, It doesn't seem to be working.


//--------START
#ifdef DEBUG
#define COUT std::cout
#else
#define COUT \/\/
#endif

int main()
{
COUT<<"HELLO\n"<<std::endl ;
}

//--------END


If you can solve the above problem, please suggest a way for taking
care of
commenting out the 'cout' statements that spans in more than 1 line.
eg:

12 COUT<<"HELLO\n"
13 <<"WORLD\n" ;

 

[Allan Bruce]

I hope comp.lang.c will not find the following question as a
complete off-topic.

I would like to remove ie.comment out the 'cout' statements during
compilation(actually preprocessing) time.


The statements like this:
cout<<"something\n" ;
should be made as
// cout<<"something\n" ;


I tried for the following. But, It doesn't seem to be working.


//--------START
#ifdef DEBUG
#define COUT std::cout
#else
#define COUT \/\/
#endif

int main()
{
COUT<<"HELLO\n"<<std::endl ;
}

//--------END


If you can solve the above problem, please suggest a way for taking
care of
commenting out the 'cout' statements that spans in more than 1 line.
eg:

12 COUT<<"HELLO\n"
13 <<"WORLD\n" ;

This is most definately a c++ question, but the same concept works in c.
The preprocessor directly copies across what you have in a define, so why
not just have
#define COUT //
Allan

 

[Jeff]

I hope comp.lang.c will not find the following question as a
complete off-topic.

I would like to remove ie.comment out the 'cout' statements during
compilation(actually preprocessing) time.


The statements like this:
cout<<"something\n" ;
should be made as
// cout<<"something\n" ;

Sorry, it is off-topic here. cout is a part of C++, not C.

[snip]

 

[Victor Bazarov]

Sorry, it is off-topic here. cout is a part of C++, not C.

Sorry, Jeff, statements explaining what is off-topic in
comp.lang.c are off-topic in comp.lang.c++. And give "qazmlp"
a break, he expressed his hope, didn't he?

Victor

 

[Victor Bazarov]

[...]
This is most definately a c++ question, but the same concept works in c.

Why is it "definately" a C++ question? C has end-of-line comments.
Depending on how 'cout' is declared, it can be seen as a valid C
construct as well (just as in C++ I can declare it whatever I want

The preprocessor directly copies across what you have in a define, so why
not just have
#define COUT //

Why not? Simple. Comments are replaced with a single space char
before macro processing is ever begins. So, the directive you
wrote will be

#define COUT

after the phase 3 of the translation in both languages.

Victor

 

[Victor Bazarov]

# //--------START
# #ifdef DEBUG
# #define COUT std::cout
# #else
# #define COUT \/\/
# #endif

How about
#ifdef DEBUG
#define COUT if (1) std::cout
#else
#define COUT if (0) std::cout
#endif

If you optimise, the unexecutable code after if (0) should be excised.

# 12 COUT<<"HELLO\n"
# 13 <<"WORLD\n" ;

if (1) std::cout <<"HELLO\n"
<<"WORLD\n" ;

if (0) std::cout <<"HELLO\n"
<<"WORLD\n" ;

This approach has a major flaw. Imagine what this will expand into

if (somecondition)
COUT << "HELLO";
else
puts("condition is not met");

This is why it's better to use 'while' for that:

#ifdef WHATEVER
#define COUT std::cout
#else
#define COUT while(0) std::cout
#endif

However, that doesn't address the OP's concern that the code still
remains not compileable by a C compiler. It would be much better
to remove any reference to 'std::cout' whatsoever.

#ifdef __cplusplus
#define COUT std::cout
#else
#define COUT ????
#endif

I don't have a solution. The biggest problem in such case is how
you deal with user-define types that can be output using the C++
shift operator:

SomeUDT udt;
std::cout << udt; // is not uncommon in C++ programs

Making the whole statement invisible to the compiler (after the
preprocessing stage) is the task at hand (or at least how I see
it)...

Victor

 

[Alan Balmer]

[...]
This is most definately a c++ question, but the same concept works in c.

Why is it "definately" a C++ question? C has end-of-line comments.
Depending on how 'cout' is declared, it can be seen as a valid C
construct as well (just as in C++ I can declare it whatever I want
without including the <iostream>)...

I'm curious - just how would you declare 'cout" to make

std::cout<<"HELLO\n"<<std::endl ;

a valid C construct?

 

[Victor Bazarov]

[...]
This is most definately a c++ question, but the same concept works in

c.

Why is it "definately" a C++ question? C has end-of-line comments.
Depending on how 'cout' is declared, it can be seen as a valid C
construct as well (just as in C++ I can declare it whatever I want
without including the <iostream>)...

I'm curious - just how would you declare 'cout" to make

std::cout<<"HELLO\n"<<std::endl ;

a valid C construct?

I didn't say that the entire statement is a valid construct.
I said 'cout' could be a valid construct. To make 'cout' valid
all you need to do is

int cout;

In the context of the thread there was no requirement to make
'std::cout<<"HELLO\n"<<std::endl ;' a valid C construct.

Victor

 

[Victor Bazarov]

On Fri, 8 Aug 2003 11:24:26 -0400, "Victor Bazarov"

[...]
This is most definately a c++ question, but the same concept works

in
c.

Why is it "definately" a C++ question? C has end-of-line comments.
Depending on how 'cout' is declared, it can be seen as a valid C
construct as well (just as in C++ I can declare it whatever I want
without including the <iostream>)...

I'm curious - just how would you declare 'cout" to make

std::cout<<"HELLO\n"<<std::endl ;

a valid C construct?

I didn't say that the entire statement is a valid construct.
I said 'cout' could be a valid construct. To make 'cout' valid
all you need to do is

int cout;

In the context of the thread there was no requirement to make
'std::cout<<"HELLO\n"<<std::endl ;' a valid C construct.

Victor

The context of the thread was that you were contesting the statement
that the OP's question concerned C++.

No, I wasn't. That's something you just invented. The OP's question
concerns both C++ and C. Off-topicality of the OP's question in
comp.lang.c is what I was contesting.

Victor

 

[Samuele Armondi]

I hope comp.lang.c will not find the following question as a
complete off-topic.

I would like to remove ie.comment out the 'cout' statements during
compilation(actually preprocessing) time.


The statements like this:
cout<<"something\n" ;
should be made as
// cout<<"something\n" ;


I tried for the following. But, It doesn't seem to be working.


//--------START
#ifdef DEBUG
#define COUT std::cout
#else
#define COUT \/\/
#endif

int main()
{
COUT<<"HELLO\n"<<std::endl ;
}

//--------END


If you can solve the above problem, please suggest a way for taking
care of
commenting out the 'cout' statements that spans in more than 1 line.
eg:

12 COUT<<"HELLO\n"
13 <<"WORLD\n" ;

Maybe you could create your own stream and use that as cout, i.e
#if !defined(DEBUG) && defined(__cplusplus)
class MyStream : public std:stream \
{ \
template <class T> \
MyStream& operator << (const T& obj) \
{ return *this; } \
}; \
#define COUT MyStream
#else
#define COUT std::cout
#endif
I'm not sure if the above code will work, I'm especially not too sure about
the template bit. And it most definitely would not work on c systems! Maybe
you could define cout to be an int and the << operator to be + , i.e
#if !defined(DEBUG) && !defined(__cplusplus)
int bogus_cout;
#define COUT bogus_cout=
#define << +
#elif !defined(DEBUG) && defined(__cplusplus)
class MyStream : public std:stream \
{ \
template <class T> \
MyStream& operator << (const T& obj) \
{ return *this; } \
}; \
#define COUT MyStream
#else
#define COUT std::cout
#endif
But you would need to be 100% sure that the code in question does not use
the << _anywhere_. Hope this helps anyway!
S. Armondi

 

[Samuele Armondi]

I hope comp.lang.c will not find the following question as a
complete off-topic.

[snip...]
But you would need to be 100% sure that the code in question does not use
the << _anywhere_. Hope this helps anyway!
S. Armondi

Sorry, ignore all the \ in the declaration of the MyStream class. They are
not needed.
S. Armondi

 

[Bill Cunningham]

after the phase 3 of the translation in both languages.

Victor

What exactly is phase 3 translation? Into assembly or RTL perhaps?

Bill

 

[Jeff]

Sorry, Jeff, statements explaining what is off-topic in
comp.lang.c are off-topic in comp.lang.c++. And give "qazmlp"
a break, he expressed his hope, didn't he?

Sorry, Victor, statements explaining the other is off-topic here is also off-topic.

Unfortunately, you are off-topic now.

(Just to remind you, we have the right to protect our c.l.c group from off-topic by kindly notifying
the OP. It is usual on Usenet and I am not the first one. If you insist that the OP is not off-topic
here, you can give your opinion)

 

[Jack Klein]

What exactly is phase 3 translation? Into assembly or RTL perhaps?

Bill

The original ANSI/ISO C language standard (1989/1990) provided a
high-level definition of the translation process that an
implementation performs in producing executable code from a source
file. These have persisted to the present in later versions of the C
standard and have been incorporated into the C++ standard.

Like everything else in C and C++, the "as-if" rule applies, meaning
that a compiler does not have use separate passes to perform all of
these operations. It can do them in parallel as long as the proper
ordering is used.

They are too long to quote here in full, but the two that are relevant
to this question are that in phase 3, "Each comment is replaced by one
space character", and in phase 4, "Preprocessing directives are
executed and macro invocations are expanded".

So there is no way of including a comment in the expansion of a macro.
The early lexical analysis step removes comments before the
preprocessor expands macros.

An overview of the 8 phases of translation:

1 through 6 deals with parsing and preprocessor issues. At the end of
phase 6 the program is a series of tokens, without white space, with
all comments removed and macros expanded.

Phase 7 actually analyses and translates the program into some sort of
output format, generally referred to as an object file.

Phase 8 is after compilation, usually performed by a separate tool
called a linker. It resolves references between different source
files and to library modules and generally produces the final
executable output file.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Victor Bazarov]

[...]
Sorry, Victor, statements explaining the other is off-topic here is also off-topic.

REALLY?

Unfortunately, you are off-topic now.

(Just to remind you, we have the right to protect our c.l.c group from off-topic by kindly notifying
the OP. It is usual on Usenet and I am not the first one. If you insist that the OP is not off-topic
here, you can give your opinion)

I already have. If you need it again, go to my first reply to you
and re-read it.

 

[John L Fjellstad]

I would like to remove ie.comment out the 'cout' statements during
compilation(actually preprocessing) time.

I saw this in a computer mag once (either C++ journal or something like
that):

#ifdef DEBUG
#define SLASH(s) /##s
#define COMMENT SLASH(/)
#else
#define COMMENT std::cout
#endif

Unfortunately, I don't know how portable this is (someone could probably
explain why it won't work). I could get it working on VisualC++ v6, but
had problems with GCC v2.9x. Think it worked in aCC (the HPUX compiler)

 

[Martin Dickopp]

I saw this in a computer mag once (either C++ journal or something like
that):

#ifdef DEBUG
#define SLASH(s) /##s
#define COMMENT SLASH(/)
#else
#define COMMENT std::cout
#endif

Unfortunately, I don't know how portable this is (someone could probably
explain why it won't work).

Comments are removed (or rather replaced by a whitespace character) in
translation phase 3, while preprocessing directives are executed and macros
are expanded in translation phase 4. Therefore, `//' is not a meaningful
preprocessing token at the point when `COMMENT' is expanded.

Martin

 

[John L Fjellstad]

Comments are removed (or rather replaced by a whitespace character) in
translation phase 3, while preprocessing directives are executed and
macros are expanded in translation phase 4. Therefore, `//' is not a
meaningful preprocessing token at the point when `COMMENT' is expanded.

Do you know if this is in the C++ standard, or if it is left to the
implementation?

 

[Martin Dickopp]

Do you know if this is in the C++ standard, or if it is left to the
implementation?

This behavior is required by the C++ standard (section 2.1#1) as well as the
C standard (section 5.1.1.2#1).

Martin


(Followup-To: comp.lang.c++ ignored, since the discussion seems meaningful
to both C and C++.)