Re: #define and (brackets)

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Igor Tandetnik wrote:

FWIW, in this case, I happen to agree with you, the parser should
view the macro as a separate token and therefore safe, IN THIS CASE,
to embed a white space. But overall, I think it will cause more harm
than good, and it would be better if the programmer simply made his
macros more concise for the parser to handle.

I never suggested otherwise. This bug is a minor bug in an obscure corner of the language, and is quite easy to work around, with the workaround arguably improving the readability of the program, so a good thing all around. Nevertheless, it's a bug (and I distinctly recall you did argue against that last statement. Perhaps I managed to convince you.)

The only thing you convince me of here is that the C++ standard is strict enough to label existing applications as non-compliant by 100% believers of the document who may use it themselves in their product line. "Hey, we comply, therefore MS should too!"

But it it good to know that you took it upon yourself to better understand the process of the state machine, lexical analysis, strings, tokens, line translations, and single and multi-pass compilers, etc.

Are there any aspects of the C++ standard that are NOT implemented?

Yes. For MSVC compiler, they are documented here:

http://msdn.microsoft.com/en-us/library/x84h5b78.aspx

These are, arguably, known bugs that the vendor doesn't plan to fix in the near future.

So in essence, according to you, the MSVC is a non-compliant, broken C++ compiler and Microsoft can not claim otherwise?

Its funny, you call them bugs, Microsoft says "NonStandard Behavior"

Nonstandard Behavior

The following topics are some of the known places where
the Visual C++ implementation of C++ does not agree with
the C++ standard. The section numbers refer to section
numbers in the C++ standard.

I love the usage of "does not agree" hehehehehehe. :-)

This is exactly what I am taking about. If they were bugs, then one would expect MS to fix them. But if there are no plans to fix them, then obviously, there are MS people who disagree with the C++ standard, and that also translate to users of the product who don't find that to be a problem, enough to escalate the issue.

The only people who will call these BUGS are people who use the C++ standard as a bible who do have an agenda, personal or otherwise.

I don't know about protocol implementors (who seem to have a rather uneasy relationship with their users), but compiler vendors appear to be happy when users report bugs to them. For MSVC compiler, you can do it here:

http://connect.microsoft.com/feedback/default.aspx?SiteID=210

So did you report this "bug?" Any feedback yet?

The question is then does it specifically state in some
>> form or another:

"Implementators of this C++ standard MUST follow
the parsing protocol 100%"

1.4 Implementation compliance
> [...]

I will be surprise if it was there

Then, I guess, I've just managed to surprise you.

I did say "parsing protocol 100%" Igor.

What you provided was a generality and that was all it was. But note item #2. The idea of different views was well understood when it said:

Although this International Standard states only
requirements on C++ implementations, those requirements are
often easier to understand if they are phrased as requirements
on programs, parts of programs, or execution of programs.

In other words, don't create further ambiguity by relaxing the guidelines.

What C++ Standard did here was to address what is often considered a problem in the standardization process such as the IETF document process where too much relaxation of the document provisions can and does lead to greater ambiguity and in the case of security, sometimes a huge problem.

I wish you would understand that and not choose to argue it.

In any case, I doubt you will find the same exact 100% same exact parsing protocol follows by all the same way.

That is not the say that an establish vendor will not update his compiler to *better* comply to a standard, but you just never know how one part of the total is deliberately done differently maybe because that is how it was and it was deemed to be better. For whatever reason, they "do not agree" with the C++ standard.

You call that a bug, broken. Others will see that differently, like MS calls it "Nonstandard Behavior."

--
.

Relevant Pages

  • Re: #define and (brackets)
    ... These are, arguably, known bugs that the vendor doesn't plan to fix ... C++ compiler and Microsoft can not claim otherwise? ... There are also a number of bugs listed on MS Connect site I referred you ... They don't disagree with the standard - after all, ...
    (microsoft.public.vc.language)
  • Re: Pedants
    ... "Of course, that is a horrible compiler", etc. ... standard function to be declared in one standard header should not be ... time) sounds like there are still similar bugs in lcc. ... they make an implicit assertion ...
    (comp.lang.c)
  • Re: fortran 90 compiler for linux
    ... > I don't know of any outstanding bugs in the Lahey/Fujitsu Fortran 95 ... > concern some Technical Reports that followed the F95 standard. ... I have seen sufficient bugs in previous versions to be fairly sure ... If you use any compiler as your primary development ...
    (comp.lang.fortran)
  • Re: Great SWT Program
    ... mushrooms regarding bugs, downtime, etc. especially when they ... majority of users find undesirable that is not required by a standard, ... and any standard-violating behavior, relative to applicable standards ... without a credit card. ...
    (comp.lang.java.programmer)
  • Re: switch() Statement Question
    ... existence of any conforming implementations. ... with the peculiarities of the standard; rather it has to do with the ... reality that implementations are, after all, software produced by ... If you're talking about bugs in implementations, ...
    (comp.lang.c)