Gennaro Prota <gennaro_prota@yahoo.com> writes:

|>  On Wed,  1 May 2002 21:07:36 GMT, Gennaro Prota
|>  <gennaro_prota@yahoo.com> wrote:

|>  >For new code? Do you mean that you always write, let's say:

|>  >bool func (...) {
|>  >    return (bool) a>b;   // cast here?
|>  >}

|>  Sorry, I meant (of course)

|>  bool func () {
|>     return (bool) (a>b);   // or bool(a>b)
|>  }

In fact, I don't, and never did.  Which means that in fact, my code
won't be portable to a place where bool is a typedef for an enum.
(I've never actually encountered anything but a typedef to an integral
type.)

For totally new code, I suppose compiler support for bool.  Today.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gennaro Prota wrote:
....
> It's a good thing :) My doubt was due to the evident difference with
> the immediately preceding sentence (in which the form "define names"
> is used). Were we dealing with a colloquial text I would have ascribed
> this choice to the wish of avoiding a repetition, but since the
> standard doesn't claim to be a pleasant reading ;) I thought that
> there should have been another reason and the only one that came to my
> mind was that "names for" could someway stand for "names that are
> substitutes for".
>
> Of course I'm reassured that both a German (James, are you German?)
> and a native english speaker don't read it this way. Thanks for the
> clarification.

There are two different Jameses here, you'll need to use last names. I'm
American (but I'm 1/4 German by ancestry). I'm fairly certain James
Kanze is German. He's got a german e-mail address, and his .sig has a
Frankfurt address and phone number. Of course, he could just be
visiting. :-)

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." <kuyper@wizard.net> writes:

|>  I'm fairly certain James Kanze is German. He's got a german e-mail
|>  address, and his .sig has a Frankfurt address and phone number. Of
|>  course, he could just be visiting. :-)

But James isn't a particularly German name, and James Kanze is very
active in the French speaking news groups:-).

In fact, my father was German, my mother American, and my wife is
Italian.  Which is why I feal most at home in France.  But I live
where ever the current job sends me.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 29 Apr 2002 17:21:54 GMT, "James Kuyper Jr."
<kuyper@wizard.net> wrote:

[...]

>The preprocessor statement
>
>#define A B
>
>provides a definition FOR 'A', not for 'B'. 'B' is the definition that
>has been provided for 'A'. Therefore, prohibiting the definition of
>"macros for names lexically identical to keywords" can only restrict the
>lexical form of 'A', not of 'B'. As a native speaker of English, I'd say
>that "defining macros that are lexically identical" would carry the same
>meaning.

It's a good thing :) My doubt was due to the evident difference with
the immediately preceding sentence (in which the form "define names"
is used). Were we dealing with a colloquial text I would have ascribed
this choice to the wish of avoiding a repetition, but since the
standard doesn't claim to be a pleasant reading ;) I thought that
there should have been another reason and the only one that came to my
mind was that "names for" could someway stand for "names that are
substitutes for".

Of course I'm reassured that both a German (James, are you German?)
and a native english speaker don't read it this way. Thanks for the
clarification.

Genny.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 28 Apr 2002 00:16:03 GMT, James Kanze
<kanze@alex.gabi-soft.de> wrote:

>I know that there is no good answer for bool.  And that I have to
>program so that my code will work, regardless of whether bool is a
>built-in type or a typedef for int or an enum.

For new code? Do you mean that you always write, let's say:

bool func (...) {
    return (bool) a>b;   // cast here?
}


It's a real pain! Why do you do that?


Genny.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed,  1 May 2002 21:07:36 GMT, Gennaro Prota
<gennaro_prota@yahoo.com> wrote:

>For new code? Do you mean that you always write, let's say:
>
>bool func (...) {
>    return (bool) a>b;   // cast here?
>}

Sorry, I meant (of course)

bool func () {
   return (bool) (a>b);   // or bool(a>b)
}


Genny.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
>
> Gennaro Prota <gennaro_prota@yahoo.com> writes:
....
> |>  Oh, that is not my point :) What I was asking is:
>
> |>  does
>
> |>   #define true_or_false     bool
>
> |>  mean to define a macro *for* a name lexically identical to a
> |>  keyword (bool)? The point is that saying you can't define macros
> |>  *for* names lexically identical to keywords seems more general to
> |>  me that saying you can't define names lexically identical to
> |>  keywords.
>
> It never occured to me that the text could be read this way.  I'll
> leave it to others (who use English on a day to day basis) to decide
> if this is a reasonable interpretation, and if the text needs
> correction.  (I am very sure that this was not the intent.)

The preprocessor statement

#define A B

provides a definition FOR 'A', not for 'B'. 'B' is the definition that
has been provided for 'A'. Therefore, prohibiting the definition of
"macros for names lexically identical to keywords" can only restrict the
lexical form of 'A', not of 'B'. As a native speaker of English, I'd say
that "defining macros that are lexically identical" would carry the same
meaning. English is a flexible language; a little too flexible for
well-defined technical documents. :-(

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Ron Natalie <ron@sensor.com> writes:

|>  James Kanze wrote:

|>  > I'm not quite sure why anyone would want to do this.  I've never
|>  > encountered a compiler which didn't implement for-loop variable
|>  > scope correctly.  The problem is that there are two incompatible
|>  > "correct" implementations, an old one and a new one.  But since
|>  > it is trivial to write code which works correctly with either
|>  > implementation, that is no excuse for such preprocessor tricks.

|>  No, it's not trivial to write code that works corection with
|>  either.  Lets say you are developing on the Sun (which users the
|>  currently correct scoping).  Even if you remember that you need to
|>  either use unique names, or wrap your for's each in it's own
|>  additional block scope, you can screw up and miss this and it will
|>  still compile and work correctly on the behaving implememtation.

There are also a couple of hundred different ways of invoking
undefined behavior which will still compile and work correctly on some
implementations.  That's life.  (Or rather, that's C++.)  Or more to
the point, that's why you have code reviews, and such.

|>  One of two things happen when you go to a (currentnly) incorrect
|>  scoped compiler:

|>   1.  It doesn't compile (duplicate identifier)

|>    for(int i =3D 0; i < n; ++i) { /* ... */ }
|>    for(int i =3D 0; i < k; ++i) { /* ... */ }

|>   2.  It silently does the wrong thing:

|>    int i;

|>    void foo() {
|>     for(int i =3D 0; i < n; ++i) { /* ... */ }
|>     i =3D 5;

|>    (Changes the global i on a conforming implementation, changes
|>    the local i on a non-conforming one).

As I said, that's why you have code review.  I'm sure you could find a
couple of hundred other cases (generally involving undefined behavior)
where similar problems occur.

In practice, in 30 years of experience, I've only once encountered a
case where global variables had names that might possibly conflict
with local names.  Realistically, the probability of the second case
is extremely small.  (I'd actually hope that a compiler would warn
about it, but since it occurs so rarely, I suspect that most don't
bother to test the case.)

|>  It's much easier to have a "portability include file" with things lik=
e:

|>  #if __ACME_COMPUTER__
|>   #define WRONG_FOR_SCOPING 1
|>   #define NO_BOOLS     1
|>  #endif

|>  #if WRONG_FOR_SCOPING
|>   # define for if(0); else
|>  #endif
|>  #if NO_BOOLS
|>   typedef int bool;
|>   const bool true =3D 1;
|>   const bool false =3D 0;
|>  #endif

I do (or rather did) use something similar for the bools.  The results
are a perfectly legal program in both cases, and there are no subtle
tricks to confuse a reader.

Using the preprocessor to play tricks with scope and syntax is just
asking for trouble.  Using the preprocessor to redefine a keyword is
illegal, and results in undefined behavior.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

>
> I do (or rather did) use something similar for the bools.  The results
> are a perfectly legal program in both cases, and there are no subtle
> tricks to confuse a reader.
>
> Using the preprocessor to play tricks with scope and syntax is just
> asking for trouble.  Using the preprocessor to redefine a keyword is
> illegal, and results in undefined behavior.
>
Actually fixing the for loop scoping to behave according to the standard
in these compilers has less impact than whatever you are doing for bools.
There is no good answer for bool.  There is nothing you can typedef it
to that will work the same way as it does in the standard and there is no
way to properly simulate it with a class.

All the #define for... trick does is wrap the for in an additional scope
which is entirely transparent to the "reader."  A reader who understands
the correct (and I'm taling about the post-1999 correctness, not your
excuse making for antique compilers) behavior is not going to get confused.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
>
> "Ludwig Pumberger" <pumberger@direkt.at> writes:
....
> |>  > I'm not quite sure why anyone would want to do this.  I've never
> |>  > encountered a compiler which didn't implement for-loop variable
> |>  > scope correctly.  The problem is that there are two incompatible
> |>  > "correct" implementations, an old one and a new one.
>
> |>  There is a standard implementation and the old one. And only the
> |>  standard implementation is correct.
>
> Both are "correct".  Which one you prefer is a different matter.  (If
> you have a lot of legacy code, you may even prefer the old
> implementation.)

You're right - the relevant term is not "correct", but "conforming".

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gennaro Prota <gennaro_prota@yahoo.com> writes:

|>  On Wed, 24 Apr 2002 00:45:23 GMT, James Kanze
|>  <kanze@alex.gabi-soft.de> wrote:

|>  >whatiscpp@yahoo.com (John the newbie) writes:

|>  >|>  I have just learned a rough trick to deal with compilers that
|>  >|>  do not implement for-loop variable scope correctly:

|>  >|>  #define for if(0) {} else for

|>  >|>  Of course I have immediately wondered if "redefining" a
|>  >|>  keyword is something legal.

|>  >Not if you include a standard header.  See 17.4.3.1.1/2.

|>  Right. Just one doubt about the second sentence in that paragraph:
|>  why does it say "define macros for names lexically identical"
|>  instead of "define names that are lexically identical"?

Probably because you cannot define names other than macros that are
lexically identical to a keyword.  Anywhere.  Any attempt to do so
requires a diagnostic.  (Whereas defining an identical macro is
undefined behavior.)

|>  Is the intent to prohibit for instance:

|>  #define LOOP for

|>  too? Actually I don't think so, but... one can never say.... :)

No.  The name LOOP is not lexically identical to a keyword.

|>  >I'm not quite sure why anyone would want to do this.  I've never
|>  >encountered a compiler which didn't implement for-loop variable
|>  >scope correctly.

|>  Hmm... I don't dare to imagine how many people are green with envy
|>  at this statement, but you can atone for your guilt by putting
|>  yourself in their place: go reading
|>  http://msdn.microsoft.com/library/en-us/vccore/html/vcrefZcforScope.a=
sp
|>  and I think you will be, like me, hallucinated ;)

I've used various Microsoft compilers in the past, and all have
implemented the for-loop scoping correctly.

We have to define what we mean by correct.  A program is correct if it
does what it is supposed to do.  For various reasons, Microsoft
decided that their compile should, by default, implement the old scope
rules.  One may disagree with their decision, but the code does what
it is supposed to do.  So it is correct.

The real life situation is that C++ has two different rules.  Some
compilers implement one.  Other compilers implement the other.  Most
compilers (including Microsoft) have switches to choose which one you
want; at least one compile will, in its default mode, emit a warning
if the semantics of your program depend on a particular rule.

Good C++ programmers are aware of this, and write code so that it will
be legal and have the same semantics under both rules.  Personally, I
can't think of a single reason to do otherwise -- it's not as if doing
so is awkward, or had any other costs.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 26 Apr 2002 18:32:10 GMT, James Kanze
<kanze@alex.gabi-soft.de> wrote:

[...]

>|>  Right. Just one doubt about the second sentence in that paragraph:
>|>  why does it say "define macros for names lexically identical"
>|>  instead of "define names that are lexically identical"?
>
>Probably because you cannot define names other than macros that are
>lexically identical to a keyword.  Anywhere.

Oh, that is not my point :) What I was asking is:

does

 #define true_or_false     bool

mean to define a macro *for* a name lexically identical to a keyword
(bool)? The point is that saying you can't define macros *for* names
lexically identical to keywords seems more general to me that saying
you can't define names lexically identical to keywords.



>|>  >I'm not quite sure why anyone would want to do this.  I've never
>|>  >encountered a compiler which didn't implement for-loop variable
>|>  >scope correctly.
>
>|>  Hmm... I don't dare to imagine how many people are green with envy
>|>  at this statement, but you can atone for your guilt by putting
>|>  yourself in their place: go reading
>|>  http://msdn.microsoft.com/library/en-us/vccore/html/vcrefZcforScope.asp
>|>  and I think you will be, like me, hallucinated ;)
>
>I've used various Microsoft compilers in the past, and all have
>implemented the for-loop scoping correctly.

Ooops... did I give you the impression of being in favour of the for
hack? I'm not, and the link I provided was, in my intent, just a
curiosity to have a look at (did you notice the smiley?).

As to the Microsoft compiler (but far be from me a dispute on this
issue), the switch specifically dealing with for-loop scope is a
brand-new addition; AFAIK, the only way you could convince pre-.net
versions to be standard compliant about that,  was to disable (all)
Microsoft extensions (without which you can't compile windows
headers).



Genny.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." <kuyper@wizard.net> writes:

|>  James Kanze wrote:

|>  > "Ludwig Pumberger" <pumberger@direkt.at> writes:
|>  ....
|>  > |>  > I'm not quite sure why anyone would want to do this.  I've
|>  > |>  > never encountered a compiler which didn't implement
|>  > |>  > for-loop variable scope correctly.  The problem is that
|>  > |>  > there are two incompatible "correct" implementations, an
|>  > |>  > old one and a new one.

|>  > |>  There is a standard implementation and the old one. And only
|>  > |>  the standard implementation is correct.

|>  > Both are "correct".  Which one you prefer is a different matter.
|>  > (If you have a lot of legacy code, you may even prefer the old
|>  > implementation.)

|>  You're right - the relevant term is not "correct", but
|>  "conforming".

And conformance is only one aspect that the authors' of a quality
compiler have to consider.  Because I'm concerned with portable code,
I consider it an important aspect.  Because I've been programming for
a while, and have a considerable amount of existing code, I consider
backwards compatibility another important aspect.  When the standard
requires something incompatible with existing practice, it puts
compiler writers on the spot, since all of them (at least the ones I
know -- from Microsoft to g++) really want to be conforming AND
backwards compatible.

Normally, I am very critical of cases where the standard is
incompatible with existing practice.  In this case, I pretty much go
along with it, because:
  - the new rules *are* better (more intuitive, etc.),
  - the number of programs in which the semantics will silently change
    should be very, very small, and
  - there exist a number of reasonable solutions for migration.
(The last two points are at least as important as the first.)

In the meantime, of course, programmers concerned with portability
have to be aware of the problem, and should program in such a manner
that their code is both legal and has the same semantics regardless of
which rule is used.  In practice, in well written code, most code
written with the new, standards conformant rule in mind will also
compile and work with the old rule.  So IMHO the problem is minimal,
and certainly not worth inventing confusing macros which change the
syntax.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Ron Natalie <ron@sensor.com> writes:

|>  > I do (or rather did) use something similar for the bools.  The
|>  > results are a perfectly legal program in both cases, and there
|>  > are no subtle tricks to confuse a reader.

|>  > Using the preprocessor to play tricks with scope and syntax is
|>  > just asking for trouble.  Using the preprocessor to redefine a
|>  > keyword is illegal, and results in undefined behavior.

|>  Actually fixing the for loop scoping to behave according to the
|>  standard in these compilers has less impact than whatever you are
|>  doing for bools.  There is no good answer for bool.  There is
|>  nothing you can typedef it to that will work the same way as it
|>  does in the standard and there is no way to properly simulate it
|>  with a class.

I know that there is no good answer for bool.  And that I have to
program so that my code will work, regardless of whether bool is a
built-in type or a typedef for int or an enum.

Which is, sort of, my point.  That's a lot more difficult than
programming so that my code will work with either for-scope rule.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gennaro Prota <gennaro_prota@yahoo.com> writes:

|>  On Fri, 26 Apr 2002 18:32:10 GMT, James Kanze
|>  <kanze@alex.gabi-soft.de> wrote:

|>  [...]

|>  >|>  Right. Just one doubt about the second sentence in that
|>  >|>  paragraph: why does it say "define macros for names lexically
|>  >|>  identical" instead of "define names that are lexically
|>  >|>  identical"?

|>  >Probably because you cannot define names other than macros that
|>  >are lexically identical to a keyword.  Anywhere.

|>  Oh, that is not my point :) What I was asking is:

|>  does

|>   #define true_or_false     bool

|>  mean to define a macro *for* a name lexically identical to a
|>  keyword (bool)? The point is that saying you can't define macros
|>  *for* names lexically identical to keywords seems more general to
|>  me that saying you can't define names lexically identical to
|>  keywords.

It never occured to me that the text could be read this way.  I'll
leave it to others (who use English on a day to day basis) to decide
if this is a reasonable interpretation, and if the text needs
correction.  (I am very sure that this was not the intent.)

|>  >|>  >I'm not quite sure why anyone would want to do this.  I've
|>  >|>  >never encountered a compiler which didn't implement for-loop
|>  >|>  >variable scope correctly.

|>  >|>  Hmm... I don't dare to imagine how many people are green with en=
vy
|>  >|>  at this statement, but you can atone for your guilt by putting
|>  >|>  yourself in their place: go reading
|>  >|>  http://msdn.microsoft.com/library/en-us/vccore/html/vcrefZcforSc=
ope.asp
|>  >|>  and I think you will be, like me, hallucinated ;)

|>  >I've used various Microsoft compilers in the past, and all have
|>  >implemented the for-loop scoping correctly.

|>  Ooops... did I give you the impression of being in favour of the
|>  for hack? I'm not, and the link I provided was, in my intent, just
|>  a curiosity to have a look at (did you notice the smiley?).

Nope.  I missed it.

|>  As to the Microsoft compiler (but far be from me a dispute on this
|>  issue), the switch specifically dealing with for-loop scope is a
|>  brand-new addition;

The switch was present in VC++ 6.0, which isn't exactly recent.  I
think it was present in 5.0 as well.

|>  AFAIK, the only way you could convince pre-.net versions to be
|>  standard compliant about that, was to disable (all) Microsoft
|>  extensions (without which you can't compile windows headers).

I didn't say that the compiler was usable with the switch:-); I just
said that the switch existed.  (The problem isn't the windows headers
-- there is nothing in the standard that says they need to be compiled
in conformant mode.  The problem is that you can't use the standard
headers either.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hi everybody,
my apologies for the trivial question but...

I have just learned a rough trick to deal with compilers that do not
implement for-loop variable scope correctly:

#define for if(0) {} else for

Of course I have immediately wondered if "redefining" a keyword is
something legal. All I have found in the standard is 2.11p1: "The
identifiers shown in Table 3 are reserved for use as keywords (that
is, they are unconditionally treated as keywords in phase 7)".

This doesn't seem to invalidate the trick above, and anyway what does
the "otherwise" mean?

Thanks.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John the newbie wrote:
>
> Hi everybody,
> my apologies for the trivial question but...
>
> I have just learned a rough trick to deal with compilers that do not
> implement for-loop variable scope correctly:
>
> #define for if(0) {} else for
>
> Of course I have immediately wondered if "redefining" a keyword is
> something legal. All I have found in the standard is 2.11p1: "The
> identifiers shown in Table 3 are reserved for use as keywords (that
> is, they are unconditionally treated as keywords in phase 7)".

'if', 'else', and 'for' are not recognised as keywords until phase 7.
Therefore, they can be created by just such a #define, which is
processed during translation phase 4.

> This doesn't seem to invalidate the trick above, and anyway what does
> the "otherwise" mean?

You mean, the "otherwise" in the following sentence?:

"Furthermore, the alternative representations shown in Table 4 for
certain operators and punctuators (2.5) are reserved and shall not be
used otherwise:"

That simply means that those tokens shall not be used for any purpose,
except as alternative representations for those operators and
punctuators. For instance, they shouldn't be used as variable names.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> Hi everybody,
> my apologies for the trivial question but...
>
> I have just learned a rough trick to deal with compilers that do not
> implement for-loop variable scope correctly:
>
> #define for if(0) {} else for
>
> Of course I have immediately wondered if "redefining" a keyword is
> something legal. All I have found in the standard is 2.11p1: "The
> identifiers shown in Table 3 are reserved for use as keywords (that
> is, they are unconditionally treated as keywords in phase 7)".
>
> This doesn't seem to invalidate the trick above, and anyway what does
> the "otherwise" mean?
>

#define simply performs a replacement. It doesn't care about C++ language
rules (that's why you should try to avoid it). You can't, for example, write
int for = 0;
because for is a keyword. But the preprocessor has it's own language.


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Ludwig Pumberger wrote:

>
> #define simply performs a replacement. It doesn't care about C++ language
> rules (that's why you should try to avoid it). You can't, for example, write
> int for = 0;
> because for is a keyword. But the preprocessor has it's own language.

The Preprocessor is a defined, and distinct state of the C++ language.

To answer the original question, yes it is wrong to redefine the keyword,
but the compiler is already broken, so as far as I am concerned, what ever
you have to do to work around it is fine as long as you make some provision
(conditional compilation, etc...) to go back to standard behavior.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3CC352B8.8CDA4A03@wizard.net>...

[snip...]

>
> 'if', 'else', and 'for' are not recognised as keywords until phase 7.
> Therefore, they can be created by just such a #define, which is
> processed during translation phase 4.
>
> > This doesn't seem to invalidate the trick above, and anyway what does
> > the "otherwise" mean?
>
> You mean, the "otherwise" in the following sentence?:

Yes, I meant that "otherwise" but my mind erroneusly mapped it to the
sentence in paragraph 1, sorry :(

>
> "Furthermore, the alternative representations shown in Table 4 for
> certain operators and punctuators (2.5) are reserved and shall not be
> used otherwise:"
>
> That simply means that those tokens shall not be used for any purpose,
> except as alternative representations for those operators and
> punctuators. For instance, they shouldn't be used as variable names.

So, if I correctly understood your explanation

#define for anything

is legal, while

#define and my_and

is not, right?

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John the newbie wrote:
>
> "James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3CC352B8.8CDA4A03@wizard.net>...
....
> > "Furthermore, the alternative representations shown in Table 4 for
> > certain operators and punctuators (2.5) are reserved and shall not be
> > used otherwise:"
> >
> > That simply means that those tokens shall not be used for any purpose,
> > except as alternative representations for those operators and
> > punctuators. For instance, they shouldn't be used as variable names.
>
> So, if I correctly understood your explanation
>
> #define for anything
>
> is legal, while
>
> #define and my_and
>
> is not, right?

I believe so.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

whatiscpp@yahoo.com (John the newbie) writes:

|>  I have just learned a rough trick to deal with compilers that do
|>  not implement for-loop variable scope correctly:

|>  #define for if(0) {} else for

|>  Of course I have immediately wondered if "redefining" a keyword is
|>  something legal.

Not if you include a standard header.  See 17.4.3.1.1/2.

I'm not quite sure why anyone would want to do this.  I've never
encountered a compiler which didn't implement for-loop variable scope
correctly.  The problem is that there are two incompatible "correct"
implementations, an old one and a new one.  But since it is trivial to
write code which works correctly with either implementation, that is
no excuse for such preprocessor tricks.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> Not if you include a standard header.  See 17.4.3.1.1/2.

> I'm not quite sure why anyone would want to do this.  I've never
> encountered a compiler which didn't implement for-loop variable scope
> correctly.  The problem is that there are two incompatible "correct"
> implementations, an old one and a new one.

There is a standard implementation and the old one. And only the standard
implementation is correct.

> But since it is trivial to
> write code which works correctly with either implementation, that is
> no excuse for such preprocessor tricks.

But what if you want to compile code written by someone else? And if your
compiler doesn't display an error message you can easily forget that you
wanted write code that is compatible to both implementations.





---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:

> whatiscpp@yahoo.com (John the newbie) writes:
>
> |>  I have just learned a rough trick to deal with compilers that do
> |>  not implement for-loop variable scope correctly:
>
> |>  #define for if(0) {} else for
>
> |>  Of course I have immediately wondered if "redefining" a keyword is
> |>  something legal.
>
> Not if you include a standard header.  See 17.4.3.1.1/2.
>
> I'm not quite sure why anyone would want to do this.  I've never
> encountered a compiler which didn't implement for-loop variable scope
> correctly.


   Sun SparcWorks 4.2 (and later Sun C++ Workshop/Forte compilers in SparcWorks
4 compatibility mode) and other compilers which implement _ARM_-defined C++
still have the old _ARM_-defined scoping.  Some source-code bases written in
_ARM_-defined C++ have difficulty finding the monetary- & schedule-budget to
make a sweep through their (multi-hundred-thousand-line or multi-million-line)
source-code base to switch from _ARM_-defined syntax & semantics to C++98 syntax
& semantics.  Thus these source-code bases remain with compilers which can
deliver _ARM_-defined syntax & semantics.  Plenty of source code with
_ARM_-defined syntax & semantics is still out there and thus compilers
deliverying _ARM_-defined syntax & semantics are still in use.

   _ARM_ = Ellis's & Stroustrup's _Annotated C++ reference manual_ 1991

>  The problem is that there are two incompatible "correct"
> implementations, an old one and a new one. But since it is trivial to
> write code which works correctly with either implementation, that is
> no excuse for such preprocessor tricks.


   James Kanze's aforementioned way of writing one copy of code which works the
same with either implementation is to write it using the *old* _ARM_-defined
scoping.  The original posting seeks to write one copy of the code which works
the same in both C++98 and _ARM_-defined C++ using only the *new* C++98 scoping.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
>
> I'm not quite sure why anyone would want to do this.  I've never
> encountered a compiler which didn't implement for-loop variable scope
> correctly.  The problem is that there are two incompatible "correct"
> implementations, an old one and a new one.  But since it is trivial to
> write code which works correctly with either implementation, that is
> no excuse for such preprocessor tricks.
>
No, it's not trivial to write code that works corection with either.
Lets say you are developing on the Sun (which users the currently
correct scoping).  Even if you remember that you need to either
use unique names, or wrap your for's each in it's own additional
block scope, you can screw up and miss this and it will still compile
and work correctly on the behaving implememtation.  One of
two things happen when you go to a (currentnly) incorrect scoped compiler:

 1.  It doesn't compile (duplicate identifier)

  for(int i = 0; i < n; ++i) { /* ... */ }
  for(int i = 0; i < k; ++i) { /* ... */ }

 2.  It silently does the wrong thing:

  int i;

  void foo() {
   for(int i = 0; i < n; ++i) { /* ... */ }
   i = 5;
  (Changes  the global i on a conforming implementation, changes the local i
   on a non-conforming one).

It's much easier to have a "portability include file" with things like:

#if __ACME_COMPUTER__
 #define WRONG_FOR_SCOPING 1
 #define NO_BOOLS     1
#endif

#if WRONG_FOR_SCOPING
 # define for if(0); else
#endif
#if NO_BOOLS
 typedef int bool;
 const bool true = 1;
 const bool false = 0;
#endif

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 24 Apr 2002 00:45:23 GMT, James Kanze
<kanze@alex.gabi-soft.de> wrote:

>whatiscpp@yahoo.com (John the newbie) writes:
>
>|>  I have just learned a rough trick to deal with compilers that do
>|>  not implement for-loop variable scope correctly:
>
>|>  #define for if(0) {} else for
>
>|>  Of course I have immediately wondered if "redefining" a keyword is
>|>  something legal.
>
>Not if you include a standard header.  See 17.4.3.1.1/2.

Right. Just one doubt about the second sentence in that paragraph: why
does it say "define macros for names lexically identical" instead of
"define names that are lexically identical"? Is the intent to prohibit
for instance:

#define LOOP for

too? Actually I don't think so, but... one can never say.... :)


>I'm not quite sure why anyone would want to do this.  I've never
>encountered a compiler which didn't implement for-loop variable scope
>correctly.

Hmm... I don't dare to imagine how many people are green with envy at
this statement, but you can atone for your guilt by putting yourself
in their place: go reading
http://msdn.microsoft.com/library/en-us/vccore/html/vcrefZcforScope.asp
and I think you will be, like me, hallucinated ;)


Genny.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Ludwig Pumberger" <pumberger@direkt.at> writes:

|>  > Not if you include a standard header.  See 17.4.3.1.1/2.

|>  > I'm not quite sure why anyone would want to do this.  I've never
|>  > encountered a compiler which didn't implement for-loop variable
|>  > scope correctly.  The problem is that there are two incompatible
|>  > "correct" implementations, an old one and a new one.

|>  There is a standard implementation and the old one. And only the
|>  standard implementation is correct.

Both are "correct".  Which one you prefer is a different matter.  (If
you have a lot of legacy code, you may even prefer the old
implementation.)

|>  > But since it is trivial to write code which works correctly with
|>  > either implementation, that is no excuse for such preprocessor
|>  > tricks.

|>  But what if you want to compile code written by someone else?

There are two possibilities:
  - The code was written with portability in mind.  In this case, you
    should have no problem; the problem is well known and easily
    avoided.
  - The code was written with no regards to portability.  If it wasn't
    written for the compiler you are using, then the scope of
    variables in the for loop is likely the least of your problems.

|>  And if your compiler doesn't display an error message you can
|>  easily forget that you wanted write code that is compatible to
|>  both implementations.

That's what code reviews are for.  The same thing could be said for
undefined behavior.  It sometimes slips in.  That doesn't make it
right.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Miller <daniel.miller@tellabs.com> writes:

|>  James Kanze wrote:
|>  > whatiscpp@yahoo.com (John the newbie) writes:
|>  > |>  I have just learned a rough trick to deal with compilers
|>  > |>  that do not implement for-loop variable scope correctly:
|>  > |>  #define for if(0) {} else for Of course I have immediately
|>  > |>  wondered if "redefining" a keyword is something legal.

|>  > Not if you include a standard header.  See 17.4.3.1.1/2.  I'm
|>  > not quite sure why anyone would want to do this.  I've never
|>  > encountered a compiler which didn't implement for-loop variable
|>  > scope correctly.

|>     Sun SparcWorks 4.2 (and later Sun C++ Workshop/Forte compilers
|>  in SparcWorks 4 compatibility mode) and other compilers which
|>  implement _ARM_-defined C++ still have the old _ARM_-defined
|>  scoping.

Which is correct.

There are two "correct" for-loop variable scoping.  Saying that a
compile implements the old scoping doesn't mean that the compiler has
an error; it just means that it implements the old scoping.  For
whatever reasons: in the case of 4.2, it is doubtlessly because the
compiler predates the current standard.  But with the correct options,
the latest g++ also implements the old rules.

|>  Some source-code bases written in _ARM_-defined C++ have
|>  difficulty finding the monetary- & schedule-budget to make a sweep
|>  through their (multi-hundred-thousand-line or multi-million-line)
|>  source-code base to switch from _ARM_-defined syntax & semantics
|>  to C++98 syntax & semantics.  Thus these source-code bases remain
|>  with compilers which can deliver _ARM_-defined syntax & semantics.
|>  Plenty of source code with _ARM_-defined syntax & semantics is
|>  still out there and thus compilers deliverying _ARM_-defined
|>  syntax & semantics are still in use.

Quite.  The existance of this code is doubtlessly the reason why g++
and others continue to provide options to implement the old rules,
even in the latest versions of the compiler.

|>     _ARM_ =3D Ellis's & Stroustrup's _Annotated C++ reference manual_ =
1991

|>  >  The problem is that there are two incompatible "correct"
|>  > implementations, an old one and a new one. But since it is
|>  > trivial to write code which works correctly with either
|>  > implementation, that is no excuse for such preprocessor tricks.

|>     James Kanze's aforementioned way of writing one copy of code
|>  which works the same with either implementation is to write it
|>  using the *old* _ARM_-defined scoping.  The original posting seeks
|>  to write one copy of the code which works the same in both C++98
|>  and _ARM_-defined C++ using only the *new* C++98 scoping.

My way of writing one copy of the code which works both ways is to
write code which is legal and has the same semantics under both rules.
You don't need funny (and illegal) preprocessor tricks to do this.
You just need common sense.  Don't use the same variable name twice in
a function.  (The number of functions with two for loops in them
should be extremely small anyway.  About the only time it occurs in my
own code is in some debugging routines.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]