Is preprocessor output file a valid C/C++ file

Question

I have 2 files as qwe.h

#ifndef QWE_H
#define QWE_H
//#include <iostream>
int asd();
#endif

qwe.cc

#include "qwe.h"
int asd()
{
std::cout<<"asdasd";
}

Running preprocessor only as g++ -E qwe.cpp > op4 gives following output

# 1 "qwe.cpp"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "qwe.cpp"
# 1 "qwe.h" 1




int asd();
# 2 "qwe.cpp" 2
int asd()
{
 std::cout<<"asdasd";
}

Shouldn't preprocessor output be a valid C/C++ file ? what is meaning of statements "# int string int"

Answer 1

They are line numbers used to track where files are included within other files, which is useful when generating compiler warnings and errors.

See this article on Wikipedia.

Answer 2

GCC makes a reasonable effort to make the preprocessor output dump still be valid source code. But the general answer is no, it's not intended for that purpose.

You can also pass the -P option along with -E to make it more machine-readable, and less human-readable. More whitespace will be stripped and the # 234 "blah.h" markers won't appear.

Shouldn't preprocessor output be a valid c/c++ file?

A big part of what the preprocessor does is lexing, or division of source into tokens. Then it expands macros, which generate tokens and whitespace according to certain rules. It's possible for a macro to generate tokens not separated by whitespace. According to the standard, preprocessor output rendered directly as text would not generally be possible to divide back into the correct tokens.

GCC goes an extra mile to try to satisfy the expectation that preprocessor output can be expressed as text, by introducing more whitespace, but it's not really a good thing to rely on, and certainly not portable to other compilers.