Hi,

Consider this simply code snippet:

struct S {};
void f(int S) {
}

If you compile this with MSVC 9 (2008) under /Za (disable language
extensions) you'll get a warning to the effect of "redeclaring type-
name S as a function parameter is a language extension".

This puzzles me. I can't find anything saying that I can't redeclare a
type-name in a function scope (where parameter definitions are; see
3.3.2).

Is MSVC right to warn here, or have they misunderstood something?

Sebastian

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

wasti.redl@gmx.net wrote:

> Hi,
>
> Consider this simply code snippet:
>
> struct S {};
> void f(int S) {
> }
>
> If you compile this with MSVC 9 (2008) under /Za (disable language
> extensions) you'll get a warning to the effect of "redeclaring type-
> name S as a function parameter is a language extension".
>
> This puzzles me. I can't find anything saying that I can't redeclare a
> type-name in a function scope (where parameter definitions are; see
> 3.3.2).
>
> Is MSVC right to warn here, or have they misunderstood something?

They are right to warn you, on two accounts.
First, a compiler may warn about anything and everything, as long as it
still compiles valid code.
Secondly, the code you posted is legal but bad style. Re-using a name
that is already in scope for a completely different purpose (like S in
your example) is a very good recipe for puzzled engineers who have to
do maintenance on the code.

>
> Sebastian
>

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

* Bart van Ingen Schenau:
> wasti.redl@gmx.net wrote:
>
>> Hi,
>>
>> Consider this simply code snippet:
>>
>> struct S {};
>> void f(int S) {
>> }
>>
>> If you compile this with MSVC 9 (2008) under /Za (disable language
>> extensions) you'll get a warning to the effect of "redeclaring type-
>> name S as a function parameter is a language extension".
>>
>> This puzzles me. I can't find anything saying that I can't redeclare a
>> type-name in a function scope (where parameter definitions are; see
>> 3.3.2).
>>
>> Is MSVC right to warn here, or have they misunderstood something?

To OP: one easy way to get a high confidence answer is to simply submit
the code
to Comeau Online (and perhaps also donate some money there <g>). And Comeau
Onlien compiles your snippet without any diagnostic. It's valid standard
C++.


> They are right to warn you, on two accounts.
> First, a compiler may warn about anything and everything, as long as it
> still compiles valid code.

To Bart: Not quite.

In the case above the compiler warning includes a statement about the C++
standard that is completely untrue, and as I understand it is what the
OP was
asking about  --  not whether the standard allows diagnostics about moon
phases.

Any program labeled "compiler" by the vendor may "warn" about anything,
and may
indeed do anything whatsoever, or nothing at all. But in the context of
standard
compliance for alleged C++ compilers we expect that they follow the
intention of
the standard (if they just follow the letter of the standard they can
still do
anything or nothing, so, intention it is), and on top of that we expect
that
they do not lie to us or deceive us or do other completely unreasonable
things.
So with respect to what I think the OP was asking about, the answer is
/no/, the
MSVC warning is not right, and it indeed seems as if "they" have
misunderstood.


> Secondly, the code you posted is legal but bad style. Re-using a name
> that is already in scope for a completely different purpose (like S in
> your example) is a very good recipe for puzzled engineers who have to
> do maintenance on the code.

Agreed. :-) But note that this can easily happen in other situations.
E.g. you
have an existing routine with formal argument named S, and you #include
a header
that defines a struct S. It would be very impractical if you got a
warning every
time some name shadowed some other name. C++ allows name shadowing in
order to
provide some measure of independence of (changes to) outer context.


Cheers & hth.,

- Alf

--
Due to hosting requirements I need visits to [http://alfps.izfree.com/].
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 8, 12:10 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * Bart van Ingen Schenau:
>
> > They are right to warn you, on two accounts.
> > First, a compiler may warn about anything and everything, as long as it
> > still compiles valid code.
>
> To Bart: Not quite.
>
> In the case above the compiler warning includes a statement about the C++
> standard that is completely untrue, and as I understand it is what the
> OP was
> asking about  --  not whether the standard allows diagnostics about moon
> phases.
>
> Any program labeled "compiler" by the vendor may "warn" about anything,
> and may
> indeed do anything whatsoever, or nothing at all. But in the context of
> standard
> compliance for alleged C++ compilers we expect that they follow the
> intention of
> the standard (if they just follow the letter of the standard they can
> still do
> anything or nothing, so, intention it is), and on top of that we expect
> that
> they do not lie to us or deceive us or do other completely unreasonable
> things.
> So with respect to what I think the OP was asking about, the answer is
> /no/, the
> MSVC warning is not right, and it indeed seems as if "they" have
> misunderstood.

I was indeed asking about the "language extension" part of the
diagnostic. Yes, they can of course warn if I compile code when Mars
is bright, but I expect them not to claim that doing so is not allowed
by the standard.

>
> > Secondly, the code you posted is legal but bad style. Re-using a name
> > that is already in scope for a completely different purpose (like S in
> > your example) is a very good recipe for puzzled engineers who have to
> > do maintenance on the code.
>
> Agreed. :-) But note that this can easily happen in other situations.
> E.g. you
> have an existing routine with formal argument named S, and you #include
> a header
> that defines a struct S. It would be very impractical if you got a
> warning every
> time some name shadowed some other name. C++ allows name shadowing in
> order to
> provide some measure of independence of (changes to) outer context.
>

Or in the majority of cases in my particular use case, I have two
(kind of) independent libraries, one of which defines a type S and the
other an abstract class where the virtual functions use parameters
called S.
Namespaces would help, but the two libraries are part of the same
larger project and thus use the same namespace. Also, different naming
conventions for types and variables would help, but it's a bit late
for that change :-)

Thanks for the answers.
Sebastian


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Alf P. Steinbach wrote:

> * Bart van Ingen Schenau:
>> They are right to warn you, on two accounts.
>> First, a compiler may warn about anything and everything, as long as
>> it still compiles valid code.
>
> To Bart: Not quite.
>
> In the case above the compiler warning includes a statement about the
> C++ standard that is completely untrue, and as I understand it is what
> the OP was
> asking about  --  not whether the standard allows diagnostics about
> moon phases.
>
> Any program labeled "compiler" by the vendor may "warn" about
> anything, and may
> indeed do anything whatsoever, or nothing at all. But in the context
> of standard
> compliance for alleged C++ compilers we expect that they follow the
> intention of
> the standard (if they just follow the letter of the standard they can
> still do
> anything or nothing, so, intention it is), and on top of that we
> expect that
> they do not lie to us or deceive us or do other completely
> unreasonable things.
> So with respect to what I think the OP was asking about, the answer is
> /no/, the
> MSVC warning is not right, and it indeed seems as if "they" have
> misunderstood.

I agree that the text of the warning is misleading, and I should have
commented on that in my original reply.

With regard to compilers doing unreasonable things, if the question
comes up if a compiler may do X, I try to look only at the text of the
standard and not at the behaviour I would expect from a high-quality
implementation.
QoI should not affect if X is possible, although it will affect if X is
desirable.

>
> Cheers & hth.,
>
> - Alf
>
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 8, 4:10 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * Bart van Ingen Schenau:
> > wasti.r...@gmx.net wrote:
>
> >> Consider this simply code snippet:
>
> >> struct S {};
> >> void f(int S) {
> >> }
>
> >> If you compile this with MSVC 9 (2008) under /Za (disable language
> >> extensions) you'll get a warning to the effect of "redeclaring type-
> >> name S as a function parameter is a language extension".
>
> > They are right to warn you, on two accounts.
> > First, a compiler may warn about anything and everything, as long as it
> > still compiles valid code.
>
> In the case above the compiler warning includes a statement about the C++
> standard that is completely untrue, and as I understand it is what the
> OP was asking about  --  not whether the standard allows diagnostics about moon
> phases.

The warning makes no mention of C++. And the fact that the warning
appears only when setting a special switch (instead appearing all of
the time) - strongly suggests that the compiler is not warning about C+
+ compliance at all.

> Any program labeled "compiler" by the vendor may "warn" about anything,
> and may indeed do anything whatsoever, or nothing at all. But in the context of
> standard compliance for alleged C++ compilers we expect that they follow the
> intention of the standard (if they just follow the letter of the standard they can
> still do anything or nothing, so, intention it is), and on top of that we expect
> that they do not lie to us or deceive us or do other completely unreasonable things.
> So with respect to what I think the OP was asking about, the answer is
> /no/, the MSVC warning is not right, and it indeed seems as if "they" have
> misunderstood.

Have they? Clearly, the "non-standard extension" mentioned in the
warning is not an extension to the C++ Standard; otherwise the C++
compiler would issue an error - not a warning - when compiling the
file with language extensions disabled. Therefore, simply by virtue of
the fact that the source file does compile, we can conclude that the
name redeclaration -is- standard C++, but would be considered an
extension under some other Standard. And a cursory look at the
documentation for the /Za compiler switch confirms that the "standard"
in this case is the ANSI C Standard.

Greg


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

* Greg Herlihy:
>
> On Mar 8, 4:10 am, "Alf P. Steinbach" <al...@start.no> wrote:
>>
>> * Bart van Ingen Schenau:
>>>
>>> wasti.r...@gmx.net wrote:
>>>>
>>>> Consider this simply code snippet:
>>>> struct S {};
>>>> void f(int S) {
>>>> }
>>>> If you compile this with MSVC 9 (2008) under /Za (disable language
>>>> extensions) you'll get a warning to the effect of "redeclaring type-
>>>> name S as a function parameter is a language extension".
>>>
>>> They are right to warn you, on two accounts.
>>> First, a compiler may warn about anything and everything, as long as it
>>> still compiles valid code.
>>
>> In the case above the compiler warning includes a statement about the C++
>> standard that is completely untrue, and as I understand it is what the
>> OP was asking about  --  not whether the standard allows diagnostics about moon
>> phases.
>
> The warning makes no mention of C++. And the fact that the warning
> appears only when setting a special switch (instead appearing all of
> the time) - strongly suggests that the compiler is not warning about C+
> + compliance at all.

Sorry, it's the other way.

The switch in question forces standard compliance, to the degree that
this compiler provides such compliance.

The text in the warning says that the code is not standard compliant,
but is instead a "language extension", which is incorrect.


>
>> Any program labeled "compiler" by the vendor may "warn" about anything,
>> and may indeed do anything whatsoever, or nothing at all. But in the context of
>> standard compliance for alleged C++ compilers we expect that they follow the
>> intention of the standard (if they just follow the letter of the standard they can
>> still do anything or nothing, so, intention it is), and on top of that we expect
>> that they do not lie to us or deceive us or do other completely unreasonable things.
>> So with respect to what I think the OP was asking about, the answer is
>> /no/, the MSVC warning is not right, and it indeed seems as if "they" have
>> misunderstood.
>
> Have they? Clearly, the "non-standard extension" mentioned in the
> warning is not an extension to the C++ Standard; otherwise the C++
> compiler would issue an error - not a warning - when compiling the
> file with language extensions disabled. Therefore, simply by virtue of
> the fact that the source file does compile, we can conclude that the
> name redeclaration -is- standard C++, but would be considered an
> extension under some other Standard. And a cursory look at the
> documentation for the /Za compiler switch confirms that the "standard"
> in this case is the ANSI C Standard.

Again sorry, the documentation does not say that the C++ compiler with
that switch behaves as an ANSI C compiler.

The documentation's term "ANSI C++ standard"[1] refers to the
international ISO/IEC C++ standard.

And, again sorry, a contradiction between the warning's text and the
documented compiler behavior does not mean that All Is Right: it means
the opposite. :-)

But then, the issue raised was, AIUI, not the quality of
implementation of that compiler (it also has many other problems with
the /Za switch).

The issue was whether the warning text is correct wrt. the C++
standard, and it isn't.


Cheeers & hth.,

- Alf


Notes:
[1] The particular switch is documented at
<url: http://msdn.microsoft.com/en-us/library/0k0w269d.aspx>.

--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 9, 8:15 am, Greg Herlihy <gre...@mac.com> wrote:

[...]

> Have they? Clearly, the "non-standard extension" mentioned in the
> warning is not an extension to the C++ Standard; otherwise the C++
> compiler would issue an error - not a warning - when compiling the
> file with language extensions disabled.

I do not see why an *error* must be issued here.

The point is, the C++ standard only requires diagnostic message
for violation of any diagnosable rule, and it really does not matter
whether the message is error or warning. After all, diagnostic
message generation is defined to be implementation-defined
behavior.

To state it stronger, if an implementation can *diagnose* the
ill-formed program, then it can compile and execute the
program without worrying about the standard conforming issues.

> Therefore, simply by virtue of
> the fact that the source file does compile, we can conclude that the
> name redeclaration -is- standard C++, but would be considered an
> extension under some other Standard.

Sorry I failed to parse the above statement here. Source file got
compiled does not necessarily mean it is standard c++. Though
this point has little to nothing to do with the OP's problem.

For implementation extensions, we know

1. The extensions shall not alter the behavior of any well-formed
     program, and

2. If a program uses extension and the problem is ill-formed
     according to the C++ standard, the implementation must find
     a way to diagnose it.
     (/Za for vc, --a/--A for como, -ansi -pedantic for gcc)


For OP's warning message (a diagnostic), though it is really
a meaningless diagnostic, but as Bart said in another post,
implementations have the freedom to issue a diagnostic
message if they really want. The program is compiled and
the final binary is generated so I believe this is an issue of
QoI.

> And a cursory look at the
> documentation for the /Za compiler switch confirms that the "standard"
> in this case is the ANSI C Standard.
>

My MSDN shows me that

   " /Za flags language constructs not compatible with either ANSI C++
     or ANSI C as errors."


> Greg
>

Regards,

Jiang


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 9, 10:12 am, Jiang <goo.mai...@yahoo.com> wrote:
> On Mar 9, 8:15 am, Greg Herlihy <gre...@mac.com> wrote:
>
> > Have they? Clearly, the "non-standard extension" mentioned in the
> > warning is not an extension to the C++ Standard; otherwise the C++
> > compiler would issue an error - not a warning - when compiling the
> > file with language extensions disabled.
>
> I do not see why an *error* must be issued here.

If setting a compiler switch to "disable" language extensions - does
not in fact stop a compiler from successfully compiling a source file
containing language extensions - then what exactly would this switch
be "disabling"?  And as a practical matter, what would use would this
switch even have in the first place?

So I don't think it is at all a stretch to conclude that a swtich that
disables language extensions - means that source files that contain
language extensions will no longer compile successfully. And in fact,
the MSDN documentation quoted (see below) affirms this expected
behavior.

> The point is, the C++ standard only requires diagnostic message
> for violation of any diagnosable rule, and it really does not matter
> whether the message is error or warning. After all, diagnostic
> message generation is defined to be implementation-defined
> behavior.

The point here has nothing to do with what the C++ Standard has to say
about diagnostics. The issue is solely behavior of a specific compiler
switch for a specific C++ compiler, and the correct interpretation of
a related warning message.

So the difference between a compiler error and a warning is the crux
of the issue here. On one side, there is a switch (/Za) that tells the
compiler not to accept language extensions - yet at the same time,
there is the text of a warning message that seems to say the the
compiler just compiled a language extension. And the way to resolve
this apparent contradiction, is to realize that there is more than one
Standard involved here.

> > Therefore, simply by virtue of
> > the fact that the source file does compile, we can conclude that the
> > name redeclaration -is- standard C++, but would be considered an
> > extension under some other Standard.
>
> Sorry I failed to parse the above statement here. Source file got
> compiled does not necessarily mean it is standard c++. Though
> this point has little to nothing to do with the OP's problem.

In this case, the fact that the source file does compile sucessfully
means that the source file is Standard C++ (at least in the opinion of
the C++ compiler). The logic to arrive at this conclusion is
straightfoward.  Tell the C++ compiler (by setting a special switxh)
to compile the source file only if contains Standard C++ (that is, the
source files must contain no language extensions). Then use the
compiler configured in this manner to compile the source file without
any error. Q.E.D.

> > And a cursory look at the
> > documentation for the /Za compiler switch confirms that the "standard"
> > in this case is the ANSI C Standard.
>
> My MSDN shows me that
>
>    " /Za flags language constructs not compatible with either ANSI C++
>      or ANSI C as errors."

Absolutely correct. The effect of compiling a source file with the /Za
compiler switch enabled, is to have a language extension not
compatible with either the ANSI C or the ISO C++ Standard to generate
an error, and to have an extension that is compatible with one
Standard or the other (as in this case) - generate a warning.

Greg


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy wrote:

>
> Absolutely correct. The effect of compiling a source file with the /Za
> compiler switch enabled, is to have a language extension not
> compatible with either the ANSI C or the ISO C++ Standard to generate
> an error, and to have an extension that is compatible with one
> Standard or the other (as in this case) - generate a warning.
>
> Greg
>
>

However as long as a single diagnostic has been issued the
implementation is free to do whatever it likes from then on. The only
exception that I am aware of is if the TU includes a #error directive.

A diagnostic can take almost any form including such things as:

'Congratulations on making use of our brilliant extensions'
The Standard does not distinguish between various compile time messages.
Now some implementations have switches that suppress the generation of
an object file (note that the Standard does not even require that such a
thing be created) or otherwise suppress the 'execution' of the code but
the Standards (both C and C++) do not require such behaviour.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 10, 10:10 pm, Greg Herlihy <gre...@mac.com> wrote:
> On Mar 9, 10:12 am, Jiang <goo.mai...@yahoo.com> wrote:
> > On Mar 9, 8:15 am, Greg Herlihy <gre...@mac.com> wrote:
> > > Have they? Clearly, the "non-standard extension" mentioned
> > > in the warning is not an extension to the C++ Standard;
> > > otherwise the C++ compiler would issue an error - not a
> > > warning - when compiling the file with language extensions
> > > disabled.

> > I do not see why an *error* must be issued here.

> If setting a compiler switch to "disable" language extensions
> - does not in fact stop a compiler from successfully compiling
> a source file containing language extensions - then what
> exactly would this switch be "disabling"?  And as a practical
> matter, what would use would this switch even have in the
> first place?

It disables "extensions".  It means that if the code using the
extension is such that it requires a diagnostic, the compiler
will issue a diagnostic.  For example, if the compiler normally
silently supports VLA's, if extensions are disabled, it will
issue a diagnostic (perhaps just a warning) that VLA's are not
supported in standard C++.

> So I don't think it is at all a stretch to conclude that a
> swtich that disables language extensions - means that source
> files that contain language extensions will no longer compile
> successfully. And in fact, the MSDN documentation quoted (see
> below) affirms this expected behavior.

A compiler can certainly document this as its behavior, and
there are good arguments that this should be the behavior.  But
only from a QoI point of view; once the compiler has issued the
diagnostic, it's off the hook, as far as the standard is
concerned.

> > The point is, the C++ standard only requires diagnostic
> > message for violation of any diagnosable rule, and it really
> > does not matter whether the message is error or warning.
> > After all, diagnostic message generation is defined to be
> > implementation-defined behavior.

The standard does, however, require the compiler to document
what it considers diagnostics.

> The point here has nothing to do with what the C++ Standard
> has to say about diagnostics. The issue is solely behavior of
> a specific compiler switch for a specific C++ compiler, and
> the correct interpretation of a related warning message.

> So the difference between a compiler error and a warning is
> the crux of the issue here.

Or a warning, or no warning.

> On one side, there is a switch (/Za) that tells the compiler
> not to accept language extensions - yet at the same time,
> there is the text of a warning message that seems to say the
> the compiler just compiled a language extension. And the way
> to resolve this apparent contradiction, is to realize that
> there is more than one Standard involved here.

And the other is?

> > > Therefore, simply by virtue of the fact that the source
> > > file does compile, we can conclude that the name
> > > redeclaration -is- standard C++, but would be considered
> > > an extension under some other Standard.

> > Sorry I failed to parse the above statement here. Source
> > file got compiled does not necessarily mean it is standard
> > c++. Though this point has little to nothing to do with the
> > OP's problem.

> In this case, the fact that the source file does compile
> sucessfully means that the source file is Standard C++ (at
> least in the opinion of the C++ compiler).

That depends on the documentation.  The fact that the source
file triggers a diagnostic means that the source file *may* not
be standard C++; if there's no diagnostic (and the compiler is
in conforming mode), then the source *is* standard C++.

Strictly speaking, a compiler which outputs "?" for all files it
compiles, and documents this as a diagnositic in the sense of
the standard, is conforming.  Not very useful, of course, and
very criticizable from a QoI point of view, but still conform.

      [...]
> > My MSDN shows me that

> >    " /Za flags language constructs not compatible with either ANSI C++
> >      or ANSI C as errors."

> Absolutely correct. The effect of compiling a source file with
> the /Za compiler switch enabled, is to have a language
> extension not compatible with either the ANSI C or the ISO C++
> Standard to generate an error, and to have an extension that
> is compatible with one Standard or the other (as in this case)
> - generate a warning.

You need more than that.  All the quoted statement says is that
it "flags as errors", whatever that means.  I see nothing there
that says that no output will be generated, or that the compiler
will return a failure status to the system.  (Part of these
issues, at least, should be covered by more generic
documentation concerning the compiler.)  And I don't really
understand the last sentence---if something is compiler with the
standard, it's not an extension.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 11, 5:40 am, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
> Greg Herlihy wrote:

> > Absolutely correct. The effect of compiling a source file
> > with the /Za compiler switch enabled, is to have a language
> > extension not compatible with either the ANSI C or the ISO
> > C++ Standard to generate an error, and to have an extension
> > that is compatible with one Standard or the other (as in
> > this case) - generate a warning.

> However as long as a single diagnostic has been issued the
> implementation is free to do whatever it likes from then on.
> The only exception that I am aware of is if the TU includes a
> #error directive.

I don't see any special rules for an #error directive.  All an
error directive does is require a diagnostic, and render the
program ill formed.

> A diagnostic can take almost any form including such things as:

> 'Congratulations on making use of our brilliant extensions'
> The Standard does not distinguish between various compile time messages.

Except in the case of an #error directive, where the diagnostic
must contain the specified sequence of preprocessing tokens
(which is somewhat strange, in a way, since tokens aren't text).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]