I recently reported a preprocessor bug in Oracle C++ 12.6 on their online forum when compiling a C program example. I even cited the C11 standard in showing that Oracle C++ 12.6's actions were non-conformant. The answer I was given, from an Oracle C++ developer who said he was a member of the C++ standard committee, is that since Oracle C++ 12.6 gives a warning message rather than a compiler error the compiler was compliant with the C standard, since the standard only requires a diagnostic message to be considered standard compliant when it does not implement the compiler according to the standard, and that a warning was a diagnostic message. Furthermore since there was a way to force the particular warning to be considered an error, Oracle was not going to change their compiler. At that point I "lost it" so to speak. I cannot conceive that any C/C++ standard would specify that giving a warning rather than an error, when not complying with the C/C++ standard, would then make the compiler compliant. Comments ?
On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
I recently reported a preprocessor bug in Oracle C++ 12.6 on their online forum when compiling a C program example. I even cited the C11 standard in showing that Oracle C++ 12.6's actions were non-conformant. The answer I was given, from an Oracle C++ developer who said he was a member of the C++ standard committee, is that since Oracle C++ 12.6 gives a warning message rather than a compiler error the compiler was compliant with the C standard, since the standard only requires a diagnostic message to be considered standard compliant when it does not implement the compiler according to the standard, and that a warning was a diagnostic message. Furthermore since there was a way to force the particular warning to be considered an error, Oracle was not going to change their compiler. At that point I "lost it" so to speak.
I cannot conceive that any C/C++ standard would specify that giving a warning rather than an error, when not complying with the C/C++ standard, would then make the compiler compliant. Comments ?
Uh, that's what all compilers do all the time when they implement extensions to the standard. With gcc, you even need to specify -Wpedantic to get those required diagnostics. I am really surprised that this is the first compiler for which you notice this... -- Marc Glisse
On 1/13/2018 1:55 PM, Marc Glisse via Boost wrote:
On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
I recently reported a preprocessor bug in Oracle C++ 12.6 on their online forum when compiling a C program example. I even cited the C11 standard in showing that Oracle C++ 12.6's actions were non-conformant. The answer I was given, from an Oracle C++ developer who said he was a member of the C++ standard committee, is that since Oracle C++ 12.6 gives a warning message rather than a compiler error the compiler was compliant with the C standard, since the standard only requires a diagnostic message to be considered standard compliant when it does not implement the compiler according to the standard, and that a warning was a diagnostic message. Furthermore since there was a way to force the particular warning to be considered an error, Oracle was not going to change their compiler. At that point I "lost it" so to speak.
I cannot conceive that any C/C++ standard would specify that giving a warning rather than an error, when not complying with the C/C++ standard, would then make the compiler compliant. Comments ?
Uh, that's what all compilers do all the time when they implement extensions to the standard. With gcc, you even need to specify -Wpedantic to get those required diagnostics. I am really surprised that this is the first compiler for which you notice this...
So a compiler is allowed to implement an extension to the standard which is non-compliant with the standard, and then claim compliance to the standard by outputting a warning message instead ? In that case what hope is there for the programmer to write C/C++ standard compliant code using such a compiler, since the compiler is "inventing" a standard which does not exist ? Note that the error I reported was not when using any -std=some_compilers_extension mode ( as in gcc's -std=gnu++nn mode as opposed to -std=c++nn mode) but with -std=c11 mode, which is explained as being an implementation of the c11 standard. In other words if I were using an Oracle c11 mode, as in a hypothetical -std=oracle++c11, I would not have complained about their extension to the standard or their cavalier treatment of a bug as not being a bug because they produced a warning. But that was not the case and the mode being used was the -std=c11 mode, which evidently means to Oracle C++ whatever they feel like defining as the c11 standard even if it does not follow the actual c11 standard.
On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
On 1/13/2018 1:55 PM, Marc Glisse via Boost wrote:
On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
I recently reported a preprocessor bug in Oracle C++ 12.6 on their online forum when compiling a C program example. I even cited the C11 standard in showing that Oracle C++ 12.6's actions were non-conformant. The answer I was given, from an Oracle C++ developer who said he was a member of the C++ standard committee, is that since Oracle C++ 12.6 gives a warning message rather than a compiler error the compiler was compliant with the C standard, since the standard only requires a diagnostic message to be considered standard compliant when it does not implement the compiler according to the standard, and that a warning was a diagnostic message. Furthermore since there was a way to force the particular warning to be considered an error, Oracle was not going to change their compiler. At that point I "lost it" so to speak.
I cannot conceive that any C/C++ standard would specify that giving a warning rather than an error, when not complying with the C/C++ standard, would then make the compiler compliant. Comments ?
Uh, that's what all compilers do all the time when they implement extensions to the standard. With gcc, you even need to specify -Wpedantic to get those required diagnostics. I am really surprised that this is the first compiler for which you notice this...
So a compiler is allowed to implement an extension to the standard which is non-compliant with the standard,
"non-compliant" is your judgement.
and then claim compliance to the standard by outputting a warning message instead ?
That's always been all the standards require. Picking a random sentence from the C++ standard: "if [...], a conforming implementation shall issue at least one diagnostic message". Seems pretty clear to me that warnings satisfy this requirement. And from discussions in the C++ committee, it is definitely interpreted that way.
In that case what hope is there for the programmer to write C/C++ standard compliant code using such a compiler,
Note that this is not a priority for compiler vendors. Accepting legacy programs comes before rejecting invalid ones. If the compiler is giving you a warning, read it? How is prefixing the message with "error:" clearer than with "warning:"?
since the compiler is "inventing" a standard which does not exist ?
Note that the error I reported was not when using any -std=some_compilers_extension mode ( as in gcc's -std=gnu++nn mode as opposed to -std=c++nn mode) but with -std=c11 mode, which is explained as being an implementation of the c11 standard. In other words if I were using an Oracle c11 mode, as in a hypothetical -std=oracle++c11, I would not have complained about their extension to the standard or their cavalier treatment of a bug as not being a bug because they produced a warning. But that was not the case and the mode being used was the -std=c11 mode, which evidently means to Oracle C++ whatever they feel like defining as the c11 standard even if it does not follow the actual c11 standard.
Again, this is in no way specific to Oracle's compiler. I am still trying to figure out why you are getting so angry about it. If the extension was breaking some subtle sfinae detection code, I could understand, but the preprocessor cannot be involved there. Does it break some feature detection in a configuration script? That's one case where indeed warnings can be much less helpful than errors, but I would still be surprised if that is the case you are in. (maybe I should read your bug report before posting anything else...) -- Marc Glisse
On 1/13/2018 4:08 PM, Marc Glisse via Boost wrote:
On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
On 1/13/2018 1:55 PM, Marc Glisse via Boost wrote:
On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
I recently reported a preprocessor bug in Oracle C++ 12.6 on their online forum when compiling a C program example. I even cited the C11 standard in showing that Oracle C++ 12.6's actions were non-conformant. The answer I was given, from an Oracle C++ developer who said he was a member of the C++ standard committee, is that since Oracle C++ 12.6 gives a warning message rather than a compiler error the compiler was compliant with the C standard, since the standard only requires a diagnostic message to be considered standard compliant when it does not implement the compiler according to the standard, and that a warning was a diagnostic message. Furthermore since there was a way to force the particular warning to be considered an error, Oracle was not going to change their compiler. At that point I "lost it" so to speak.
I cannot conceive that any C/C++ standard would specify that giving a warning rather than an error, when not complying with the C/C++ standard, would then make the compiler compliant. Comments ?
Uh, that's what all compilers do all the time when they implement extensions to the standard. With gcc, you even need to specify -Wpedantic to get those required diagnostics. I am really surprised that this is the first compiler for which you notice this...
So a compiler is allowed to implement an extension to the standard which is non-compliant with the standard,
"non-compliant" is your judgement.
"Non-compliant" simply means that the compiler does not follow the C++ standard. What is judgmental about that ? Or do you believe there is no such thing as following the C++ standard so whatever a compiler does it is perfectly OK to call itself compliant ?
and then claim compliance to the standard by outputting a warning message instead ?
That's always been all the standards require. Picking a random sentence from the C++ standard: "if [...], a conforming implementation shall issue at least one diagnostic message". Seems pretty clear to me that warnings satisfy this requirement. And from discussions in the C++ committee, it is definitely interpreted that way.
Please quote an actual place rather than a random sentence.
In that case what hope is there for the programmer to write C/C++ standard compliant code using such a compiler,
Note that this is not a priority for compiler vendors. Accepting legacy programs comes before rejecting invalid ones.
If the compiler is giving you a warning, read it? How is prefixing the message with "error:" clearer than with "warning:"?
An error stops the compilation, a warning does not unless you tell the compiler to treat warnings as errors. Good luck using the typical compiler if you do the latter.
since the compiler is "inventing" a standard which does not exist ?
Note that the error I reported was not when using any -std=some_compilers_extension mode ( as in gcc's -std=gnu++nn mode as opposed to -std=c++nn mode) but with -std=c11 mode, which is explained as being an implementation of the c11 standard. In other words if I were using an Oracle c11 mode, as in a hypothetical -std=oracle++c11, I would not have complained about their extension to the standard or their cavalier treatment of a bug as not being a bug because they produced a warning. But that was not the case and the mode being used was the -std=c11 mode, which evidently means to Oracle C++ whatever they feel like defining as the c11 standard even if it does not follow the actual c11 standard.
Again, this is in no way specific to Oracle's compiler.
I do not care if it is Podunk C++. The principal that a compiler says it is standard conforming because it issues a warning rather than an error when it does not conform to the standard is what bothers me. If such behavior is actually part of the C or C++ standard then there is never any point at reporting bugs to any C++ implementation because their answer to any valid bug can be "we issue a warning but we are not going to bother to fix the bug because the warning makes us compliant".
I am still trying to figure out why you are getting so angry about it. If the extension was breaking some subtle sfinae detection code, I could understand, but the preprocessor cannot be involved there. Does it break some feature detection in a configuration script? That's one case where indeed warnings can be much less helpful than errors, but I would still be surprised if that is the case you are in.
(maybe I should read your bug report before posting anything else...)
My anger is wrong. But my point of view is I believe valid. Why waste time trying to test a compiler when the result is that the compiler developers do not care if they have a bug in their implementation because all they have to do is tell you that their warning satisfies the standard and therefore there is no point of fixing their bug. I don't care what the bug actually is in this case, it's the attitude of the compiler implementor that irks me.
2018-01-13 13:43 GMT-08:00 Edward Diener via Boost <boost@lists.boost.org>:
On 1/13/2018 4:08 PM, Marc Glisse via Boost wrote:
On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
On 1/13/2018 1:55 PM, Marc Glisse via Boost wrote:
On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
I recently reported a preprocessor bug in Oracle C++ 12.6 on their
online forum when compiling a C program example. I even cited the C11 standard in showing that Oracle C++ 12.6's actions were non-conformant. The answer I was given, from an Oracle C++ developer who said he was a member of the C++ standard committee, is that since Oracle C++ 12.6 gives a warning message rather than a compiler error the compiler was compliant with the C standard, since the standard only requires a diagnostic message to be considered standard compliant when it does not implement the compiler according to the standard, and that a warning was a diagnostic message. Furthermore since there was a way to force the particular warning to be considered an error, Oracle was not going to change their compiler. At that point I "lost it" so to speak.
I cannot conceive that any C/C++ standard would specify that giving a warning rather than an error, when not complying with the C/C++ standard, would then make the compiler compliant. Comments ?
Uh, that's what all compilers do all the time when they implement extensions to the standard. With gcc, you even need to specify -Wpedantic to get those required diagnostics. I am really surprised that this is the first compiler for which you notice this...
So a compiler is allowed to implement an extension to the standard which is non-compliant with the standard,
"non-compliant" is your judgement.
"Non-compliant" simply means that the compiler does not follow the C++ standard. What is judgmental about that ? Or do you believe there is no such thing as following the C++ standard so whatever a compiler does it is perfectly OK to call itself compliant ?
and then claim compliance to the standard by outputting a warning message
instead ?
That's always been all the standards require. Picking a random sentence from the C++ standard: "if [...], a conforming implementation shall issue at least one diagnostic message". Seems pretty clear to me that warnings satisfy this requirement. And from discussions in the C++ committee, it is definitely interpreted that way.
Please quote an actual place rather than a random sentence.
In that case what hope is there for the programmer to write C/C++
standard compliant code using such a compiler,
Note that this is not a priority for compiler vendors. Accepting legacy programs comes before rejecting invalid ones.
If the compiler is giving you a warning, read it? How is prefixing the message with "error:" clearer than with "warning:"?
An error stops the compilation, a warning does not unless you tell the compiler to treat warnings as errors. Good luck using the typical compiler if you do the latter.
since the compiler is "inventing" a standard which does not exist ?
Note that the error I reported was not when using any -std=some_compilers_extension mode ( as in gcc's -std=gnu++nn mode as opposed to -std=c++nn mode) but with -std=c11 mode, which is explained as being an implementation of the c11 standard. In other words if I were using an Oracle c11 mode, as in a hypothetical -std=oracle++c11, I would not have complained about their extension to the standard or their cavalier treatment of a bug as not being a bug because they produced a warning. But that was not the case and the mode being used was the -std=c11 mode, which evidently means to Oracle C++ whatever they feel like defining as the c11 standard even if it does not follow the actual c11 standard.
Again, this is in no way specific to Oracle's compiler.
I do not care if it is Podunk C++. The principal that a compiler says it is standard conforming because it issues a warning rather than an error when it does not conform to the standard is what bothers me. If such behavior is actually part of the C or C++ standard then there is never any point at reporting bugs to any C++ implementation because their answer to any valid bug can be "we issue a warning but we are not going to bother to fix the bug because the warning makes us compliant".
I am still trying to figure out why you are getting so angry about it. If the extension was breaking some subtle sfinae detection code, I could understand, but the preprocessor cannot be involved there. Does it break some feature detection in a configuration script? That's one case where indeed warnings can be much less helpful than errors, but I would still be surprised if that is the case you are in.
(maybe I should read your bug report before posting anything else...)
My anger is wrong. But my point of view is I believe valid.
Actually I haven't read where you clearly develop your point with respect to the standard, even though you felt like asking from others to "quote an actual place rather than a random sentence".
Why waste time trying to test a compiler when the result is that the compiler developers do not care if they have a bug in their implementation because all they have to do is tell you that their warning satisfies the standard and therefore there is no point of fixing their bug. I don't care what the bug actually is in this case, it's the attitude of the compiler implementor that irks me.
The C++ standard says: "If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message." (C++14 1.4.2.2). It also define "diagnostic message" as "message belonging to an implementation-defined subset of the implementation’s output messages" (C++14 1.3.6). Finally the standard also allows the compiler vendor to compile and execute an ill-formed program, as long as they don't alter the behavior of a well conformant program: "A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any well-formed program. Implementations are required to diagnose programs that use such extensions that are ill-formed according to this International Standard. Having done so, however, they can compile and execute such programs." (C++14 1.4.8). I believe that compiler vendors in general are very much more listening to bug exhibited in standard-compliant programs than "bugs" exhibited by non-compliant programs. PS: what is the relationship with Boost and/or this mailing-list by the way? Best, -- Mehdi
On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
So a compiler is allowed to implement an extension to the standard which is non-compliant with the standard,
"non-compliant" is your judgement.
"Non-compliant" simply means that the compiler does not follow the C++ standard. What is judgmental about that ?
You are the one claiming it does not follow the standard, while it seems that it does follow at least the letter.
and then claim compliance to the standard by outputting a warning message instead ?
That's always been all the standards require. Picking a random sentence from the C++ standard: "if [...], a conforming implementation shall issue at least one diagnostic message". Seems pretty clear to me that warnings satisfy this requirement. And from discussions in the C++ committee, it is definitely interpreted that way.
Please quote an actual place rather than a random sentence.
[intro.compliance] "If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message." [defns.diagnostic] "diagnostic message message belonging to an implementation-defined subset of the implementation’s output messages" But I can't find any text forbidding the implementation to produce some binary object.
In that case what hope is there for the programmer to write C/C++ standard compliant code using such a compiler,
Note that this is not a priority for compiler vendors. Accepting legacy programs comes before rejecting invalid ones.
If the compiler is giving you a warning, read it? How is prefixing the message with "error:" clearer than with "warning:"?
An error stops the compilation, a warning does not unless you tell the compiler to treat warnings as errors. Good luck using the typical compiler if you do the latter.
Are you saying warnings are useless?
I do not care if it is Podunk C++. The principal that a compiler says it is standard conforming because it issues a warning rather than an error when it does not conform to the standard is what bothers me. If such behavior is actually part of the C or C++ standard then there is never any point at reporting bugs to any C++ implementation because their answer to any valid bug can be "we issue a warning but we are not going to bother to fix the bug because the warning makes us compliant".
You are over-generalizing. Most interesting bugs are about valid code that gets rejected, or accepted but for which wrong code is generated (or valid but slow code is generated). Then you can argue about helpful diagnostics that the compiler can provide to let developers know about potential issues, but aggressively claiming non-conformance may not be the most efficient way to present your argument. They already know about this since they have a warning, they probably already weighed the pros of accepting some customer's old code base vs more strongly telling users about an issue in their code, and consider the result a feature. Some chances of getting a change could be: - this was done a long time ago, maybe the old code is not relevant anymore - you demonstrate how the warning was ignored and this caused a bug for some important customer - ask for a better split between strict modes and compatibility modes (maybe a -pedantic-errors -like flag that turns all relevant warnings into errors)
I don't care what the bug actually is in this case, it's the attitude of the compiler implementor that irks me.
Try to see it from the other side. They would probably love to make it an error, but they have paying customers with legacy code (and I suspect this compiler in particular is used on legacy code more often than new code) and needed to find some compromise to make them happy, so they made it a warning (still conforming). Then come entitled non-paying users who tell them they absolutely must make it an error... What would you do in their place? Maxim's response was very polite and pedagogical, honestly explaining why this was unlikely to change. And along the years, I've read similar responses from all major compiler teams. -- Marc Glisse
On 1/13/2018 6:28 PM, Marc Glisse via Boost wrote:
On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
So a compiler is allowed to implement an extension to the standard which is non-compliant with the standard,
"non-compliant" is your judgement.
"Non-compliant" simply means that the compiler does not follow the C++ standard. What is judgmental about that ?
You are the one claiming it does not follow the standard, while it seems that it does follow at least the letter.
No such thing of "it does follow at least the letter" in this case. The standard is completely clear on the particular issue, and has always been. Invoking a non-variadic macro with a number of arguments not matching the number of parameters is incorrect C or C++.
and then claim compliance to the standard by outputting a warning message instead ?
That's always been all the standards require. Picking a random sentence from the C++ standard: "if [...], a conforming implementation shall issue at least one diagnostic message". Seems pretty clear to me that warnings satisfy this requirement. And from discussions in the C++ committee, it is definitely interpreted that way.
Please quote an actual place rather than a random sentence.
[intro.compliance] "If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message."
[defns.diagnostic] "diagnostic message message belonging to an implementation-defined subset of the implementation’s output messages"
But I can't find any text forbidding the implementation to produce some binary object.
In that case what hope is there for the programmer to write C/C++ standard compliant code using such a compiler,
Note that this is not a priority for compiler vendors. Accepting legacy programs comes before rejecting invalid ones.
If the compiler is giving you a warning, read it? How is prefixing the message with "error:" clearer than with "warning:"?
An error stops the compilation, a warning does not unless you tell the compiler to treat warnings as errors. Good luck using the typical compiler if you do the latter.
Are you saying warnings are useless?
I do not care if it is Podunk C++. The principal that a compiler says it is standard conforming because it issues a warning rather than an error when it does not conform to the standard is what bothers me. If such behavior is actually part of the C or C++ standard then there is never any point at reporting bugs to any C++ implementation because their answer to any valid bug can be "we issue a warning but we are not going to bother to fix the bug because the warning makes us compliant".
You are over-generalizing. Most interesting bugs are about valid code that gets rejected, or accepted but for which wrong code is generated (or valid but slow code is generated).
Then you can argue about helpful diagnostics that the compiler can provide to let developers know about potential issues, but aggressively claiming non-conformance may not be the most efficient way to present your argument. They already know about this since they have a warning, they probably already weighed the pros of accepting some customer's old code base vs more strongly telling users about an issue in their code, and consider the result a feature. Some chances of getting a change could be: - this was done a long time ago, maybe the old code is not relevant anymore - you demonstrate how the warning was ignored and this caused a bug for some important customer - ask for a better split between strict modes and compatibility modes (maybe a -pedantic-errors -like flag that turns all relevant warnings into errors)
I don't care what the bug actually is in this case, it's the attitude of the compiler implementor that irks me.
Try to see it from the other side. They would probably love to make it an error, but they have paying customers with legacy code (and I suspect this compiler in particular is used on legacy code more often than new code) and needed to find some compromise to make them happy, so they made it a warning (still conforming). Then come entitled non-paying users who tell them they absolutely must make it an error... What would you do in their place?
Maxim's response was very polite and pedagogical, honestly explaining why this was unlikely to change.
And along the years, I've read similar responses from all major compiler teams.
My issue is about claiming conformance. If the answer is that "we are non-conformant but we cannot change this because we are afraid of breaking legacy code" I would understand. But when the answer argues that they are conformant because in the particular case a warning is valid for establishing conformance, then I cannot understand it. We might as well say that any compiler which issues warnings whenever a compiler error should occur, simply because it can continue compiling, is a valid C or C++ conformant compiler. I am sorry I brought this up In the Boost mailing list. Nobody really cares and this is not a Boost problem. I do apologize for voicing my displeasure here, or even trying to find out if this is really the way the standard is designed. It is not a Boost issue per se and I should have kept it to myself.
Edward Diener wrote:
But when the answer argues that they are conformant because in the particular case a warning is valid for establishing conformance, then I cannot understand it. We might as well say that any compiler which issues warnings whenever a compiler error should occur, simply because it can continue compiling, is a valid C or C++ conformant compiler.
It is. That's what the standard says. Whether a diagnostic starts with the word "error" or the word "warning" is irrelevant for conformance.
On 1/13/2018 6:53 PM, Peter Dimov via Boost wrote:
Edward Diener wrote:
But when the answer argues that they are conformant because in the particular case a warning is valid for establishing conformance, then I cannot understand it. We might as well say that any compiler which issues warnings whenever a compiler error should occur, simply because it can continue compiling, is a valid C or C++ conformant compiler.
It is. That's what the standard says. Whether a diagnostic starts with the word "error" or the word "warning" is irrelevant for conformance.
So basically if the code continues compiling, even if it produces an incorrect result, the C++ standard says that the compiler is conformant because it issued a warning to the end-user instead of an error. Thanks for notifying me about this. I really did not know that this is how the standard is written. Needless to say if I were on the C++ standard committee I would have voted against this, but that is irrelevant to the way things are. At least I have learned something.
On 1/13/2018 3:40 PM, Olaf van der Spek via Boost wrote:
On Sat, Jan 13, 2018 at 7:45 PM, Edward Diener via Boost <boost@lists.boost.org> wrote:
I recently reported a preprocessor bug in Oracle C++ 12.6 on their online forum when compiling a C program example. I even cited the C11 standard in
What bug is it about?
Oracle C++ fails two preprocessor tests. I boiled it down to: #define SOME_MACRO(x,y) some_result int main() { SOME_MACRO(); return 0; } Of course calling SOME_MACRO without two arguments is a preprocessor error. Oracle C++ gives only a warning. My point is not about an actual bug but that a compiler decides a bug is not a bug because it gives a warning rather than an error. I find this ludicrous. I know that the VC++ preprocessor is much worse and is not even remotely C or C++ standard conformant. But no one from Microsoft would seriously argue that their preprocessor conformed to the C++ standard. The fact that the Oracle developer actual argues this case is what bothered me and caused my to give up trying to test that compiler or report anything to them.
participants (5)
-
Edward Diener -
Marc Glisse -
Mehdi AMINI -
Olaf van der Spek -
Peter Dimov