Re: #define and (brackets)
"Tommy" <bad@reallybad.com> wrote in message
news:ObMPyvjUJHA.5860@TK2MSFTNGP02.phx.gbl
Maybe this is common with mail systems, but not with C++ compilers.
All major compiler vendors are thoroughly represented when the new
standard is drafted.
Thus leaving out all minors ones?
Minor compiler vendors are free to join if they are so inclined, and so
is anyone else willing to commit time and effort - you don't need to be
a compiler vendor to participate in the committee. I know that major
vendors _are_ represented. I couldn't say "all vendors are represented",
as that would have required me to interview every person not
represented, to make sure they are not writing a new C++ compiler in
their copious spare time.
All decisions are made by consensus.
Minor or Major?
By consensus of everyone who chose to join the committee.
Here's food for thought:
Isn't the lexical analysis PERFECT, Is not the state machine perfect?
Define "PERFECT".
Therefore, there should be 100% consensus?
Are you suggesting this is not the case? The description of the lexical
analysis hasn't changed between the two versions of the standard.
Presumably, everyone agrees it's fine as is.
The fact that the
standard is released at all means that all interested parties have
signed off on it. It's not like some external force tries to foist
the new text on unsuspecting population.
Of course it is, Osmosis By Concensus as I always called it. The fact
that there could disagreements that may not suit the agenda of the
powers to be, does show the consensus is not gospel or speaks for all.
Who do you perceive to hold these mystical "powers to be", whatever that
means? And what do you believe their secret agenda is?You begin to sound
like a conspiracy theorist. I'm pretty sure they are not out to get you.
The reality is that the those involved in the process DO NOT always
appeal to all, nor all END USERS, including the fact, they may be too
involved to have created a "mental block" on what may end up being a
bad mistake for the majority.
Those involved will have to sell their products to said end users. Their
bottom line is firmly in their minds during the discussions.
Besides, many of those end users are themselves on the committee. I know
the company I work for is represented, though we don't produce C++
compilers. We have a very large and growing C++ codebase, and we are
there to make sure that C++ language meets our needs.
And I've been long involved in such groups to know it is usually just
1 or 2 champions and others that have blind trust and sign off on
thing they generally don't or may not fully comprehend.
I assure you that our company has very smart and capable people
representing it on the committee. I personally have read many of the
proposals, and I believe I comprehend them (I'm not personally involved
in the official business of the committee). You seem to be accusing
people you don't even know of being stupid, or naive, or lazy. Do you
have any evidence for such accusations?
You seem to be talking about RFC 2821.
The update, RFC 5381, was just released.
In year 2008. You were talking about an RFC that is 8 years old.
So now anyone not following this is broken? <g>
Anyone who claims to follow it but doesn't is, by definition, broken.
There were one or two
things that WILL break a system that read the original as it was
UNDERSTOOD.
I'm sure the participants involved have deemed the (presumably
considerable) benefits of these changes to outweigh the drawbacks, and
have carefully considered the migration process and compatibility
issues. At least that's what would have happened in the C++
standardization committee. I have no evidence suggesting that some
mysterios "powers that be" have subverted the process to serve their
evil agenda, and unless and until such evidence surfaces, I assume that
all parties are acting in good faith. I'm not sufficiently familiar with
SMTP or its development procedures to comment further.
Second, if you guys reference a DRAFT C/C++ standard document that
is analogous to an RFC.
Everything I said in this thread is true against ISO/IEC 14882:1998
aka C++98, as well as the C++0x draft (which didn't change the
description of the phases of translation in any significant way, if
at all; I haven't compared the two texts character by character).
Well, as long as one notices the redlining and understand the
background that C++ is an augmentation of the C language, then I
personally have no issue with that.
ISO/IEC 9899:1999 aka C99 prescribes the same phases of translation, in
substantially the same normative language. I wouldn't be surprised if
the text hasn't changed since C89, but I don't have a copy handy to
check.
The issue I have is an insistence of the specific "parsing protocol"
and I am not entirely convinced it has been all read correctly in its
total context.
Then please feel free to point out specifically where you believe my
reading is incorrect.
But either way, thats ok too, because I know from experience that
implementations do tend to differ and not always because they are
buggy.
Differ from each other, or differ from specification? C++
implementations are allowed to differ from each other - that's why the
standard has the concept of undefined (1.3.12) and unspecified (1.3.13)
behaviors. It is possible to write portable programs that don't exhibit
either of those.
As to differing from specification - how do you define "buggy" if not as
"doesn't follow specification"? Do you subscribe to Alan Carre's notion
that "the compiler is the ultimate arbiter", in which case there
apparently ain't no such thing as a compiler bug?
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.)
So for one to continue to suggest that a long existing compilers are
magically BUGGY because it may not follow verbatim an ever evolving
standard or draft today is just plain silly, unrealistic.
A compiler is buggy when it doesn't follow the standard it claims to
conform to.
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.
Anyway, this is typical behavior of USERS of a system. Users are known
to be anal with specifics, they appeal to docs as it is the "bible" to
an one way or the high way approach towards protocol implementation.
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
They are the ones that general throw in your face,
"look, its buggy because of this standard section XYZ"
You mean, they provide free QA service to you by filing a bug report?
Why again is this something to despise, rather than cherish?
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
2 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. Such requirements have the following meaning:
- If a program contains no violations of the rules in this International
Standard, a conforming implementation shall, within its resource limits,
accept and correctly execute that program.
- If a program contains a violation of any diagnosable rule, a
conforming implementation shall issue at least one diagnostic message,
except that
- If a program contains a violation of a rule for which no diagnostic is
required, this International Standard places no requirement on
implementations with respect to that program.
In our case, we have a program that contains no violations of the rules
in the standard, and yet the implementation fails to accept it. Ergo,
it's non-conforming (unless you want to argue that the program in
question strains the compiler's resource limits).
I will be surprise if it was there
Then, I guess, I've just managed to surprise you.
because as I said, there is far
too many implementators that MAY or MAY NOT follow it for whatever
reason it is.
In other words, there exist buggy implementations. Tell me something I
don't know.
At best, the C++ standard can only serve as a
guideline for implementators to use, to provide an INTENT in order to
make the meaning correct.
You may put it this way, yes. Then, whenever the implementation doesn't
follow the guidelines, its users file a bug report and its authors fix
it.
C++ users, you see, are interested in writing portable code. For that,
they demand compilers that agree with each other on the meaning and
interpretation of their programs. One way to achieve that, the way that
C++ community chose to follow, is to draft a written specification of
the language, and then demand compliance with this specification from
the vendors. It also helps vendors, by introducing clarity as to what
the compiler should do.
At the end of the day, it was about how a parser took a string "-X"
and created tokens.
I know as a fact based on compiler and interpretator creation and
seeing how others, and how other languages work, not just C/C++ but
many others, that it could see that as TWO tokens
"-" "X"
or it can do MACRO substitution FIRST and see a string:
"--10"
and see two different tokens now:
"--" "10"
A compiler that does the former is conforming. A compiler that does the
latter is non-conforming, aka buggy, as it fails to compile a valid C++
program.
There are just far too many factors to all this. Appealing to a
STANDARD does not always make it broken.
How else do you determine that a compiler is broken? What other
measuring stick can you compare it against?
What you (speaking in
general) think is correct may or may not be viewed the same way by
others.
A program is either valid with respect to the standard, or it isn't. The
compiler either accepts it, or it doesn't. These are objective facts not
subject to personal opinion. 2+2==4 regardless of what someone might
think about it.
--
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