The preprocessor is just a pass

[Sam of California]

Is it accurate to say that "the preprocessor is just a pass in the parsing
of the source file"?

I responded to that comment by saying that the preprocessor is not just a
pass. It processes statements that the compiler does not process. The good
people in the alt.comp.lang.l earn.c-c++ newsgroup insist that the
preprocessor is just one of many passes. The preprocessor processes a
grammer unique to the preprocessor and only that grammer.

The discussion is at:

What in fact is the preprocessor?
http://groups.google.com/group/alt.c...1df10e2b29fbc2

[John Harrison]

Sam of California wrote:

Is it accurate to say that "the preprocessor is just a pass in the parsing
of the source file"?

I responded to that comment by saying that the preprocessor is not just a
pass. It processes statements that the compiler does not process. The good
people in the alt.comp.lang.l earn.c-c++ newsgroup insist that the
preprocessor is just one of many passes. The preprocessor processes a
grammer unique to the preprocessor and only that grammer.

The discussion is at:

What in fact is the preprocessor?
http://groups.google.com/group/alt.c...1df10e2b29fbc2

What I don't understand is your statement

"The preprocessor is not just a pass. It processes statements that the
compiler does not process. The language is very clear that the
preprocessor's statements are totally different from the compiler."

The second sentence is true, the third sentence is true. I don't
understand how the first sentence follows.

The preprocessor is just a pass, as far as I am concerned. By 'just a
pass' I mean that the preprocessor can be totally seperated from the
other phases (or passes) that proceed and follow it, i.e. the output of
each pass is the input to the next pass that follows it. Maybe you have
a different definition of 'just a pass'.

john

[Sam of California]

"John Harrison" <jo************ *@hotmail.comwr ote in message
news:Ek******** *********@newsf e7-gui.ntli.net...

>
"The preprocessor is not just a pass. It processes statements that the
compiler does not process. The language is very clear that the
preprocessor's statements are totally different from the compiler."

The second sentence is true, the third sentence is true. I don't
understand how the first sentence follows.

Of course the first sentence is vague. It can be interpreted in many ways. I
clarify the first sentence with the subsequent sentences.

[John Harrison]

Sam of California wrote:

"John Harrison" <jo************ *@hotmail.comwr ote in message
news:Ek******** *********@newsf e7-gui.ntli.net...

>"The preprocessor is not just a pass. It processes statements that the
compiler does not process. The language is very clear that the
preprocessor 's statements are totally different from the compiler."

The second sentence is true, the third sentence is true. I don't
understand how the first sentence follows.

Of course the first sentence is vague. It can be interpreted in many ways. I
clarify the first sentence with the subsequent sentences.

Well it seems to me that you are defining 'a pass' in a certain way. And
as a consequence of the way you have defined 'a pass' it is true that
preprocessing is not just a pass.

No doubt those who disagreed with you (me included) defined 'a pass' in
a different way, so they are right as well.

This kind of argument about definitions is very boring, so I'm not
taking any further part, unless you have a substantive point to make. At
the moment I don't see it.

john

[Gennaro Prota]

On Sun, 27 May 2007 08:11:04 -0700, Sam of California wrote:

>Is it accurate to say that "the preprocessor is just a pass in the parsing
of the source file"?

I responded to that comment by saying that the preprocessor is not just a
pass.

How can a processor be a pass; something which performs a pass, at
most.

Informally, I use the terms "preprocess ing" or "preprocess ing phase"
to identify --roughly-- the sequence of what the ISO standard defines
as phase 3 and phase 4 of translation -- but only when there isn't any
need to be more precise (it is also the name of one of the directories
in the Breeze source tree, for instance). In any case, the standard
doesn't use the term "preprocess or", nor "preprocess ing" as a
standalone noun (it uses expressions such as "preprocess ing
directive", though, which may make somewhat reasonable the personal
terminology choice explained above. It arose exactly because I didn't
like to use the term "preprocessor") .

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/

[Phlip]

Sam of California wrote:

Is it accurate to say that "the preprocessor is just a pass in the parsing
of the source file"?

Very casually, yes.

I responded to that comment by saying that the preprocessor is not just a
pass. It processes statements that the compiler does not process. The good
people in the alt.comp.lang.l earn.c-c++ newsgroup insist that the
preprocessor is just one of many passes. The preprocessor processes a
grammer unique to the preprocessor and only that grammer.

Historically, the preprocessor was a separate program. It read
preprocessor-ready code and wrote processed C code, without the extra #
statements and such. Then the C compiler read the raw C code.

Nowadays we naturally use only one compiling program. The vestiges of the
CPP filter have migrated into it, including a separate lexing system. So the
CPP does respect "" quotes and // comment markers, but does not respect
delimiters like {}. It is unaware they delimit blocks.

Explaining the system gets easier if you treat the preprocessor as a second
pass thru the text of the program. The historical note helps.

--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html

[James Kanze]

On May 27, 7:36 pm, Gennaro Prota <address@spam_t his.comwrote:

On Sun, 27 May 2007 08:11:04 -0700, Sam of California wrote:

Is it accurate to say that "the preprocessor is just a pass in the parsing
of the source file"?

I responded to that comment by saying that the preprocessor is not just a
pass.

How can a processor be a pass; something which performs a pass, at
most.

Informally, I use the terms "preprocess ing" or "preprocess ing phase"
to identify --roughly-- the sequence of what the ISO standard defines
as phase 3 and phase 4 of translation -- but only when there isn't any
need to be more precise (it is also the name of one of the directories
in the Breeze source tree, for instance). In any case, the standard
doesn't use the term "preprocess or", nor "preprocess ing" as a
standalone noun (it uses expressions such as "preprocess ing
directive", though, which may make somewhat reasonable the personal
terminology choice explained above. It arose exactly because I didn't
like to use the term "preprocessor") .

To quote the standard (§2.1/7): "[In phase 7] Each preprocessing
token is converted into a token." I've always understood
everything which preceded this (i.e. phases 1-6) to be
"preprocessing" , and the "preprocess or" whatever does the
"preprocessing" . With regards to "passes", I rather suspect
that very few compilers today use a separate pass for this; it's
generally integrated one way or another into the tokenization of
the input. Which doesn't mean that we can't speak of the
preprocessor, just because it isn't a separate pass.

--
James Kanze (Gabi Software) email: ja*********@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Marcin Kalicinski]

Is it accurate to say that "the preprocessor is just a pass in the parsing

of the source file"?

The C++ preprocessing step is very well defined, and every C++ programmer
knows precisely what it does. On the other hand, a "pass" is not a well
defined term. So, question "is preprocessing a pass" makes no sense. The
question you have to answer first is "what is a pass". Then, the answer to
your original question will follow automatically.

Alternatively, you can spend two weeks discussing whether preprocessor is
something you don't know, or if it isn't it. Good luck.

[Sam of California]

"Marcin Kalicinski" <ka****@poczta. onet.plwrote in message
news:pI******** *************** *******@eclipse .net.uk...

>
The C++ preprocessing step is very well defined

Yes, thank you.

On the other hand, a "pass" is not a well defined term.

Yes.

So, question "is preprocessing a pass" makes no sense. The question you
have to answer first is "what is a pass". Then, the answer to your
original question will follow automatically.

Yes. The problem is that everyone is putting emphasis on "pass" and
commenting on that only. Then they say, using various terminology, that my
question is nonsense (makes no sense).

Everyone is ignoring the important part, except for brief commenst such as
yours. You say that the "C++ preprocessing step is very well defined", and
that is the important part that is ignored or only briefly commented on.

I am sorry if I fail at using the correct terminology. What I am saying is
that describing the preprocessor as (just) a pass is saying that there is
nothing unique about preprocessor statements or directives. If "preprocess or
statements" is incorrect terminology then what should I say? Is
"preprocess or directives" correct? Is it correct to say that the
preprocessor's grammer is separate from all the rest of the grammer for
C/C++?

[John Harrison]

>

I am sorry if I fail at using the correct terminology. What I am saying is
that describing the preprocessor as (just) a pass is saying that there is
nothing unique about preprocessor statements or directives. If "preprocess or
statements" is incorrect terminology then what should I say? Is
"preprocess or directives" correct? Is it correct to say that the
preprocessor's grammer is separate from all the rest of the grammer for
C/C++?

Yes that last statement is true. In fact the tokens that the
preprocessing grammar operates on are different from the tokens that the
main C++ grammar operates on.

But you introduced this terminaolgy 'just a pass'. I still don't think
that 'the preprocessor's grammer is separate from all the rest of the
grammer' justifies the statement 'the preprocessor is not just a pass',
quite the opposite I would say. The very fact that the two grammars are
unrelated *encourages* me to describe preprocessing as just a pass.

At least I'm sure you can agree that using this terminolgy is confusing,
just look at this thread and the last. So if you want to find out more
about preprocessing I suggest you drop it.

john