In article <3A30F130.96B9A9D6@student.uni-kl.de>,
  strieder@student.uni-kl.de wrote:
> "Fran=E7ois-Xavier Callewaert" wrote:

> > Why does the standard C++ require that a preprocessor directive be
> > the only "thing" on a line(16.1) ?

> >  I can readily understand why it should be the last "thing" on a
> > line, but why should it also be the first ?

> >  Appart from the fact that the following line of code is probably
> > harder to read then the legal alternative is it somehow bad ?

> cout<<"#define BAR"<<endl;

> The preprocessor would have to first scan the line completely to
> recognize whether and where a preprocessor directive starts. Here
> there is none, but a string constant that would have to be
> recognized at first.

It has to do this anyway, at least according to the standard.  The
first thing the preprocessor does is break the line down into
preprocessor tokens, and string literals are preprocessor tokens.

> With the current rule it can decide by the first non-whitespace of a
> line, if there is a preprocessor directive or not. Preprocessing
> directives are removed during preprocessing, this is very easy to do
> with the current rules.

> The lexical analysis would become remarkably more complex if the
> rules allowed appending directives to other lines of code, since
> alle lines would have to be fully scanned to find all
> directives. This slows the preprocessor down.

> So nobody really wants it. It's quite unreadable for programmers, it
> adds complexity to the preprocessor, and it slows it down.

I'm not sure that it would really add that much complexity to the
preprocessor.  Given that preprocessing directives are scanned using
slightly different rules than the rest of the program, and that they
can significantly modify the meaning of the rest of the program,
however, this is one extension that I definitly don't want to see.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Thu,  7 Dec 2000 19:27:34 GMT, "Fran=E7ois-Xavier Callewaert"
<celine.callewaert@club-internet.fr> wrote in comp.std.c++:

>=20
> Why does the standard C++ require that a preprocessor directive be the
> only "thing" on a line(16.1) ?
>=20
>  I can readily understand why  it should be the last "thing" on a line,
> but why should it also be the first ?
>=20
>  Appart from the fact that the following line of code is probably harde=
r to
> read then the legal alternative is it somehow bad ?
>=20
>  void func();  #define BAR
>=20
>  Thanks for any enlightenment

Consider that the C++ preprocessor, inherited from C, is actually a
language of its own and knows nothing at all about the actual syntax
of C or C++, only about tokens.

Now consider this:

char *x =3D "Hello this is #define BAR";

Then again, why not?  C programmers have managed to live with this for
more than 25 years without serious difficulty (although the period for
C++ programmers is about 10 years shorter).

Jack Klein
--=20
Home: http://jackklein.home.att.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Fran=E7ois-Xavier Callewaert" wrote:
>=20
> Why does the standard C++ require that a preprocessor directive be the
> only "thing" on a line(16.1) ?
>=20
>  I can readily understand why  it should be the last "thing" on a line,
> but why should it also be the first ?
>=20
>  Appart from the fact that the following line of code is probably harde=
r to
> read then the legal alternative is it somehow bad ?
>=20

cout<<"#define BAR"<<endl;

The preprocessor would have to first scan the line completely to
recognize whether and where a preprocessor directive starts. Here there
is none, but a string constant that would have to be recognized at
first.

With the current rule it can decide by the first non-whitespace of a
line, if there is a preprocessor directive or not. Preprocessing
directives are removed during preprocessing, this is very easy to do
with the current rules.

The lexical analysis would become remarkably more complex if the rules
allowed appending directives to other lines of code, since alle lines
would have to be fully scanned to find all directives. This slows the
preprocessor down.

So nobody really wants it. It's quite unreadable for programmers, it
adds complexity to the preprocessor, and it slows it down.

Bernd Strieder

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Fran   ois-Xavier Callewaert" <celine.callewaert@club-internet.fr> wrote in
message news:90onv1$dci$1@front7.grolier.fr...
>
> Why does the standard C++ require that a preprocessor directive be the
> only "thing" on a line(16.1) ?
>
>  I can readily understand why  it should be the last "thing" on a line,
> but why should it also be the first ?
>
>  Appart from the fact that the following line of code is probably harder
to
> read then the legal alternative is it somehow bad ?
>
>  void func();  #define BAR
>
>  Thanks for any enlightenment

Macro definition and expansion is done in a different preprocessing phase
(#4 in the standard) to the actual compilation.  This simplifies the
compiler a lot.

HTH,

--
Mike Dimmick


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Why does the standard C++ require that a preprocessor directive be the
only "thing" on a line(16.1) ?

 I can readily understand why  it should be the last "thing" on a line,
but why should it also be the first ?

 Appart from the fact that the following line of code is probably harder to
read then the legal alternative is it somehow bad ?

 void func();  #define BAR

 Thanks for any enlightenment



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Why do that to begin with???


"Fran   ois-Xavier Callewaert" <celine.callewaert@club-internet.fr> wrote in
message news:90onv1$dci$1@front7.grolier.fr...
>
> Why does the standard C++ require that a preprocessor directive be the
> only "thing" on a line(16.1) ?
>
>  I can readily understand why  it should be the last "thing" on a line,
> but why should it also be the first ?
>
>  Appart from the fact that the following line of code is probably harder
to
> read then the legal alternative is it somehow bad ?
>
>  void func();  #define BAR
>
>  Thanks for any enlightenment
>
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]