Re: #define and (brackets)
"Tommy" <bad@reallybad.com> wrote in message
news:%23dTDf4wUJHA.1148@TK2MSFTNGP05.phx.gbl
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?
You can put it this way, yes. And in fact they don't.
Its funny, you call them bugs, Microsoft says "NonStandard Behavior"
Thus admitting their compiler is non-compliant.
There are also a number of bugs listed on MS Connect site I referred you
to, that MS clearly accepts are bugs, but that they don't consider
important enough to fix right away. Some of them get fixed in the next
version, some in the version after that, and some are still open. This
is all part of a normal lifecycle of any software product.
This is exactly what I am taking about. If they were bugs, then one
would expect MS to fix them.
Quite. I hope they will, eventually. Meanwhile, I won't lose sleep over
it.
But if there are no plans to fix them,
then obviously, there are MS people who disagree with the C++
standard
No. They don't disagree with the standard - after all, they helped write
it. They just feel that their limited resources are better spent
elsewhere.
and that also translate to users of the product who don't
find that to be a problem, enough to escalate the issue.
Correct. This figures into the vendor's decision to spend its limited
resources elsewhere.
For example, there was a hard push by customers to improve handling of
templates, and so a lot of work has been done between VC6 (which just
barely understands them) and VC7.1 (which has a very decent support).
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 call these bugs (in lowercase; I rarely shout). What, in your opinion,
is my agenda?
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?"
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=385034
Any feedback yet?
Not yet. If you want to see an example of a typical bug report, here's
one of my previous reports (also about a minor problem with the
preprocessor, as luck would have it):
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=99561
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.
I don't understand the significance of this caveat. The standard
requires compliance with all its rules. An implementation that violates
any rule is non-conformant. Why should "parsing protocol" be singled out
for extra confirmation?
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 do you mean, "relaxing the guidelines"? I just quoted from the
standard, without changing a word. In what sense have I relaxed
anything? What did I make ambiguous that was unambiguous before? Please
be specific.
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.
So, the C++ standard is clear and unambiguous, while some IETF documents
are unclear and ambiguous, which is a problem. I haven't read all IETF
documents, so I have no reason not to believe you. But, how does this
relate to the discussion at hand? We don't discuss problems with any
IETF documents, do we?
In any case, I doubt you will find the same exact 100% same exact
parsing protocol follows by all the same way.
But I can point any divergences to implementation authors, thus helping
them fix bugs and improve conformance. Everyone benefits.
Note that the implementation doesn't have to implement its parsing
protocol (or any other feature) exactly as specified in the standard -
it just has to behave as if it does. I don't care what it does
internally - all I care is that it accept all valid C++ programs, and
reject all invalid ones.
That is not the say that an establish vendor will not update his
compiler to *better* comply to a standard
This is all I ask for.
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.
If they think some non-standard behavior is better, they should submit a
proposal to this effect to the standardization committee and work
towards making it standard. Note that all committee documents are open
to the public.
You call that a bug, broken. Others will see that differently, like
MS calls it "Nonstandard Behavior."
I don't see the fundamental difference. These are just two terms for the
same thing.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925