Bill Klein wrote:
>
> Francis Glassborow <francis@robinton.demon.co.uk> wrote:
>> It seems to me that you can either have MFC or Standard C++ but not
>> both.
>
> Hehe, actually it's much worse than that. If you turn on
> the /Za switch to disable MS 'extensions', which is what
> you need to do to get the correct for() loop scope, you
> can't use many standard library (STL) headers! They
> simply won't compile.

Yep.  To be fair (!) to MS, they are not the only compiler that fails
to compile conforming programs when "strict conformance" is enabled.
Many Unix compilers refuse to compile programs that call POSIX system
functions in this mode, apparently on the theory that only the
functions defined by ISO are allowed to be declared in "conforming"
headers, so all of the other system functions (e.g., read() and
fork()) get thrown out the window.  This would be fine if they also
provided other headers (e.g., "unistd.h") that declared those
functions, but they don't.

Of course, I've argued for a long time that system-specific O/S
functions should have names like sys_fork() or os_read(); but far
too much water (and code) has passed under the bridge for that kind
of change to ever happen.

BTW, it's a minor nit, but "STL" means "Standard Template Library"
(which is only part of the standard library), not "STandard Library".
You would be more correct to write "std library" instead (since the
names of the standard library reside in the 'std' namespace).

-- David R. Tribble, david@tribble.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I wrote:
>> Hehe, actually it's much worse than that. If you turn on
>> the /Za switch to disable MS 'extensions', which is what
>> you need to do to get the correct for() loop scope, you
>> can't use many standard library (STL) headers! They
>> simply won't compile.

David R. Tribble
>Yep.  To be fair (!) to MS, they are not the only compiler that fails
>to compile conforming programs when "strict conformance" is enabled.

What annoys me is that, to be perfectly honest, i don't
*care* if the MS extensions are on or not and would gladly
leave them on (and just not use them) if all the did was
*extend*. The problem comes from the fact that they also
change the way certain things work to completely non-
conforming behavior (for example, the for loops we've
been talking about). It would be nice if there were, perhaps,
two options: standard-compliant behavior on/off and MS
extensions on/off. The former would make for loops and
other things work as they are supposed to when it's on (and
would be turned off for backward compatibility).

>BTW, it's a minor nit, but "STL" means "Standard Template Library"
>(which is only part of the standard library), not "STandard Library".
>You would be more correct to write "std library" instead (since the
>names of the standard library reside in the 'std' namespace).

Actually I knew all this. The reason why I said Standard
Library is because I was referring to the entire standard
library and not just the STL. For example, I *believe* (could
be wrong) there is also a problem if you simply do an
#include <iostream> ! The reason I put STL in brackets is
because I've noticed that a lot of people don't realize
that the STL is considered to be part of the standard
library and I wanted to emphasize that that's where the
main problems were.



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

  Thanks for the info everyone,

  David LaRue

David R Tribble <david@tribble.com> writes:

>Yep.  To be fair (!) to MS, they are not the only compiler that fails
>to compile conforming programs when "strict conformance" is enabled.
>Many Unix compilers refuse to compile programs that call POSIX system
>functions in this mode, apparently on the theory

It's not just a theory, it's a fact.

>that only the
>functions defined by ISO are allowed to be declared in "conforming"
>headers, so all of the other system functions (e.g., read() and
>fork()) get thrown out the window.  This would be fine if they also
>provided other headers (e.g., "unistd.h") that declared those
>functions, but they don't.

There's a problem of conflicting standards here. The C and C++
standards say, for example, that the spelling "fileno" in the
global namespace is reserved to user programs, so <stdio.h> can't
declare a function with that name.  But the POSIX and X/Open
standards require fileno to be in <stdio.h>. (Different versions
of POSIX and X/Open standards have conflicting requirements,
adding to the fun.)

The usual solution is to provide guard macros in the standard
headers, some or all of which are set by compiler flags. You
tell the compiler whether you want to see a strictly-conforming
C++ implementation, or one that (for example) conforms to X/Open
Issue 5. One cannot conform strictly to both at the same time.

If you are writing a program that depends on Unix features, you
don't want strict C++ conformance -- you want Unix conformance.
For example, you want to include <stdio.h> to get fileno.
(Presumably large parts of any application don't depend on
the platform. Those parts could be compiled in strict language
conformance mode.)

If a C or C++ implementation provided, say, <stdio-unix.h> as a way
to get Unix features while maintaining strict language conformance,
it would not help portability. Another implementation might not
provide that header, or provide it with a different spelling, or
provide an unrelated header with that spelling.

If a Unix standard provided additional headers with the Unix
features that are not in the C standard, that would solve
the problem for language implementors. It is probably a bit
late in the day for such a change to have much value for
users, however.

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.12082c665fd2f721989c7f@news.mindspring.com>,
jcoffin@taeus.com (Jerry Coffin) wrote:

> In article <WgKQkdAzIjn3Ewss@robinton.demon.co.uk>,
> francis@robinton.demon.co.uk says...
>
> [ ... ]
>
> > NO and this change to the language was made a long time ago (five or
> > more years I think).  What is, to my mind, disgraceful is that, while
> > VC++ does support the correct version if you use the appropriate switch
> > you will then find that MFC source is broken.
> >
> > It seems to me that you can either have MFC or Standard C++ but not
> > both.
>
> It's actually FAR worse than that -- if only MFC broke when you used
> the /Za switch, it wouldn't be so terrible.  Unfortunately, you can't
> use (at least most of) the headers required by the standard unless you
> enable MS's extensions.  IMO, that's a _dramatically_ worse situation.

Essentially their compiler is even more academic than academic itself,
when its "conforming" mode is on. It's so academic as to be almost
completely unusable :-)  (I'm making playful jabs at academia here)

> OTOH, as has been pointed out many times in the past, it's pretty
> trivial to fix this without help from the compiler:
>
> #define for if (0) else for
>
> does the trick IIRC.

I got flamed for posting that. Someone once mentioned that this makes the
program non-conforming, since defining preprocessor macros with names that
match keywords makes it non-conforming... *but*, if the compiler were
conforming, this hack wouldn't be necessary in the first place. So, I have
no problem with it if I happen to be using an old/bloated compiler. An
advantage over a compile-time switch is that this is "local" to the
translation unit (and can be even be restricted to just part of the
translation unit). This allows code which requires the old behavior to
continue to work.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow <francis@robinton.demon.co.uk> wrote:
>NO and this change to the language was made a long time ago (five or
>more years I think).  What is, to my mind, disgraceful is that, while
>VC++ does support the correct version if you use the appropriate switch
>you will then find that MFC source is broken.
>
>It seems to me that you can either have MFC or Standard C++ but not
>both.

Hehe, actually it's much worse than that. If you turn on
the /Za switch to disable MS 'extensions', which is what
you need to do to get the correct for() loop scope, you
can't use many standard library (STL) headers! They
simply won't compile. This is a known problem and MS has
not said when they will fix it. So to correct your
statement, if you want to use Standard C++, you're not
allowed to use MFC and neither are you allowed to use
Standard C++ libraries. Hmm...
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

  A coworker asked about the latest standard and the scope of variables.
There is a difference between the Borland and Microsoft implementations
and we would like clarification on which is the standard implementation.

  The following function is an example:

int main (int argc, char *argv[])
{
  for (int i = 0; i < argc; i++)
   {
     if (strcmp (argv[i], "/d")
       break;
   }

  if (i < argc) return   i;
  else          return -1;
}

  Should the scope of i extend to the end of the main function under the
latest C++ standard?

  Thanks,

  David LaRue


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David LaRue wrote:

>   A coworker asked about the latest standard and the scope of variables.
> There is a difference between the Borland and Microsoft implementations
> and we would like clarification on which is the standard implementation.
>
>   The following function is an example:
>
> int main (int argc, char *argv[])
> {
>   for (int i = 0; i < argc; i++)
>    {
>      if (strcmp (argv[i], "/d")
>        break;
>    }
>
>   if (i < argc) return   i;
>   else          return -1;
> }
>
>   Should the scope of i extend to the end of the main function under the
> latest C++ standard?

No. The scope of i extends to the end of the for loop. The line "  if (i <
argc) return   i;" is in error. Borland does this correctly. Microsoft still
does not.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

DLaRue@NetSRQ.Com (David LaRue) asks:
>   A coworker asked about the latest standard and the scope of variables.
> There is a difference between the Borland and Microsoft implementations
> and we would like clarification on which is the standard implementation.
>
>   The following function is an example:
>
> int main (int argc, char *argv[])
> {
>   for (int i = 0; i < argc; i++)
>    {
>      if (strcmp (argv[i], "/d")
>        break;
>    }
>
>   if (i < argc) return   i;
>   else          return -1;
> }
>
>   Should the scope of i extend to the end of the main function under the
> latest C++ standard?

No.  Under the standard i goes out of scope when the flow of control exits
from the for loop.  This is different from the rule in the ARM (under which
the scope of i would extend to the end of the main function).

You should be able to get the same behaviour under both your compilers
by moving the declaration outside the for loop thusly:

#include <string.h>

int main (int argc, char *argv[])
{
  int i;
  for (i = 0; i < argc; i++)
   {
     if (strcmp (argv[i], "/d"))
       break;
   }

  if (i < argc) return   i;
  else          return -1;
}

Mike
--
C. M. Heard/VVNET, Inc.
heard@vvnet.com


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <MPG.12082c665fd2f721989c7f@news.mindspring.com>, Jerry
> Coffin <jcoffin@taeus.com> writes
> >OTOH, as has been pointed out many times in the past, it's pretty
> >trivial to fix this without help from the compiler:
> >
> >#define for if (0) else for
> >
> >does the trick IIRC.
>
[...]
> Actually I believe that, even
> though it works, having a keyword as a pre-processor identifier is
> unacceptable.
>

Does 'unacceptable' mean 'illegal' here? If so, where does the standard
say so? I thought the pre-processor doesn't know and doesn't want to
know about the keywords of C++ language.

--
Biju Thomas
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:

>> Actually I believe that, even
>> though it works, having a keyword as a pre-processor identifier is
>> unacceptable.

Biju Thomas <b_thomas@ibm.net> wrote:

> Does 'unacceptable' mean 'illegal' here? If so, where does the standard
> say so? I thought the pre-processor doesn't know and doesn't want to
> know about the keywords of C++ language.

I assume that Francis meant to say that it's a bad idea, not that the
standard prohibits it. However, the standard does prohibit this kind of
definition before including headers from the standard library.

Section 17.4.3.3.1 [lib.macro.names], paragraph 2, says:

"A translation unit that includes a header shall not contain any macros that
define names declared or defined in that header. Nor shall such a
translation unit define macros for names lexically identical to keywords."

This is legal:

    #define DarinAdlerIsAGoon
    #include <iostream>

But not this:

    #define iterator hesheoriterator
    #include <vector>

And not this:

    #define auto NoOneEverUsesAutoAnyway
    #include <cstring>

    -- Darin


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

One other thing. The standard says nothing about the order, so these are
illegal too:

    #include <vector>
    #define iterator hesheoriterator

And this:

    #include <cstring>
    #define auto NoOneEverUsesAutoAnyway

So, it's legal to #define for, but not if you want to include any of the
standard headers!

Anyway, who cares if it's legal when you're using it to work around a
bizarre behavior of Visual C++? The question is not whether it's legal, but
whether it will work!

    -- Darin
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Darin Adler wrote:
>
> I assume that Francis meant to say that it's a bad idea, not that the
> standard prohibits it. However, the standard does prohibit this kind of
> definition before including headers from the standard library.
>
> Section 17.4.3.3.1 [lib.macro.names], paragraph 2, says:
>
> "A translation unit that includes a header shall not contain any macros that
> define names declared or defined in that header. Nor shall such a
> translation unit define macros for names lexically identical to keywords."

I don't see how you can restrict this restriction to macros
defined *before* including a standard header. That is, as I read
it, it prohibits all macro definitions of names that are either
defined or declared in any included standard header or that are
keywords, before or after the inclusion of the headers.

Curiously, as I read this,

    #define for if (0) ; else for

is legal as long as your program doesn't include any standard
headers. (This admittedly doesn't provide any practical relief
from the restriction.)

John L
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37A0FCEB.EB118208@ibm.net>, Biju Thomas <b_thomas@ibm.net>
writes
>Does 'unacceptable' mean 'illegal' here? If so, where does the standard
>say so? I thought the pre-processor doesn't know and doesn't want to
>know about the keywords of C++ language.

No unacceptable means something that is generally not done in polite
circles (even though sometimes you have no reasonable alternative.)

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <abln3.115$Kd.1922@mercury.intnet.net>, David LaRue
<DLaRue@NetSRQ.Com> writes
> The following function is an example:
>
>int main (int argc, char *argv[])
>{
>  for (int i = 0; i < argc; i++)
>   {
>     if (strcmp (argv[i], "/d")
>       break;
>   }
>
>  if (i < argc) return   i;
>  else          return -1;
>}
>
>  Should the scope of i extend to the end of the main function under the
>latest C++ standard?

NO and this change to the language was made a long time ago (five or
more years I think).  What is, to my mind, disgraceful is that, while
VC++ does support the correct version if you use the appropriate switch
you will then find that MFC source is broken.

It seems to me that you can either have MFC or Standard C++ but not
both.

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <abln3.115$Kd.1922@mercury.intnet.net>, DLaRue@NetSRQ.Com
says...
>
>   A coworker asked about the latest standard and the scope of variables.
> There is a difference between the Borland and Microsoft implementations
> and we would like clarification on which is the standard implementation.

[ code elided ]

>   Should the scope of i extend to the end of the main function under the
> latest C++ standard?

Under the C++ standard (there has only ever been one), the scope of a
variable declared in a for statement extends only to the end of the
for statement itself -- I.e. to the end of the statement (or block of
statements) controlled by the for loop.  For example:

int main() {
 int I=10;

 for (int I=0; I<20;I++)
  ;

 std::cout << I; // should print '10' because the 'i' in the
     // for loop is now out of scope.
 return 0;
}

MS implements this in their compiler if (and only if) you use the /Za
flag to disable their extensions.  Unfortunately, this is worthless,
because with that flag, it can no longer compile its own standard
headers.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> [W]hile VC++ does support the correct version if you use the appropriate
> switch you will then find that MFC source is broken.
>
> It seems to me that you can either have MFC or Standard C++ but not
> both.

It is worse than that. With /Za some of the standard library
headers won't compile, either. It is easier to just acknowledge
that Visual C++ doesn't support the standard wrt for-statement
declaration scope, or trick it into doing so with macros, with
all of the attendant problems with that.

John L

cc: Francis Glassborow
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <WgKQkdAzIjn3Ewss@robinton.demon.co.uk>,
francis@robinton.demon.co.uk says...

[ ... ]

> NO and this change to the language was made a long time ago (five or
> more years I think).  What is, to my mind, disgraceful is that, while
> VC++ does support the correct version if you use the appropriate switch
> you will then find that MFC source is broken.
>
> It seems to me that you can either have MFC or Standard C++ but not
> both.

It's actually FAR worse than that -- if only MFC broke when you used
the /Za switch, it wouldn't be so terrible.  Unfortunately, you can't
use (at least most of) the headers required by the standard unless you
enable MS's extensions.  IMO, that's a _dramatically_ worse situation.

OTOH, as has been pointed out many times in the past, it's pretty
trivial to fix this without help from the compiler:

#define for if (0) else for

does the trick IIRC.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.12082c665fd2f721989c7f@news.mindspring.com>, Jerry
Coffin <jcoffin@taeus.com> writes
>OTOH, as has been pointed out many times in the past, it's pretty
>trivial to fix this without help from the compiler:
>
>#define for if (0) else for
>
>does the trick IIRC.

Perhaps such a ghastly piece of code about fits the quality of the code
MS hands out as examples (i.e. MFC).  Actually I believe that, even
though it works, having a keyword as a pre-processor identifier is
unacceptable.


>

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]