Re: #define and (brackets)
"Tommy" <bad@reallybad.com> wrote in message
news:%23Jl4O04UJHA.5920@TK2MSFTNGP06.phx.gbl
Igor Tandetnik wrote:
"Tommy" <bad@reallybad.com> wrote in message
news:eGRj6e1UJHA.1148@TK2MSFTNGP05.phx.gbl
Igor Tandetnik wrote:
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.
I didn't mean the entire standard silly. :-) "parts of the C++
standard"
Do you have any evidence that MS disagrees with any part of the
standard?
I'm going to give you a B+ on the Art of Rhetorical Judo. :-)
Don't you think the NonStandard Behavior Web Link you provided
implies it?
No. It only suggests that MS chose not to implement some parts of the
standard at this time, but doesn't imply any specific reason for such a
decision. Disagreement with the standard would be one such reason - do
you have any evidence this is what's driving the decision here?
Like I said, "failure to implement" doesn't imply "disagreement".
Note that "decide not to implement" doesn't necessarily imply
"disagree": e.g., I don't disagree with any part of RFC 5321, and
yet I choose not to implement SMTP protocol.
Sure. What I think you are saying is like:
"My implementation was done as such that doesn't fully agree
with the standard.
Yes. I have just written a trivial implementation of SMTP protocol. It
looks like this:
int main() { return 0; }
I chose not to fully implement RFC 5321. Does it imply I disagree with
it, and believe my implementation is better? Or does it simply mean I
didn't invest sufficient resources into a more complete implementation?
After all, I had to produce it on a very tight schedule.
By the way, the same program doubles as a C++ compiler, though not a
particularly standard-conforming one. But that shouldn't be a problem,
right? Mine is much faster than anything on the market today. It's not
buggy, it just exhibits NonStandard Behavior.
But it does says "Does not agree" and its your guess and my guess why
they decided not to AGREE in implementing specific parts of the
standard.
It's entirely possible to fail to implement a standard (or parts
thereof) without disagreeing with it.
They just feel that their limited resources are better spent
elsewhere.
I doubt that.
Which part: that their resources are limited, or that they are
spending them elsewhere?
Now Igor, do you really think MS resources are limited? :-)
Yes. Do you really think they are infinite?
If MS has unlimited resources, why wouldn't they fix what they've
already accepted are in fact bugs? Like this one I mentioned before:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=99561
Is this because they disagree with themselves as to whether or not it's
a bug? Or is it because of this:
"We will keep the bug in our database and *if time permits* we will take
another look at it. -- Jonathan Caves, Visual C++ Compiler Team"
(Emphasis mine.)
I will venture on the idea that its a product of
evolutions where methods were well established and they deem it was
better to keep with compatibility.
Can you explain how implementing, say, export for templates breaks
compatibility?
I can't off hand.
So your idea is incorrect, then?
In other words, establish vendors in any product market, generally
do not have the luxury as new comers have in producing a product
that follows a standard 100%.
Comeau and GCC try pretty darn hard.
And they are good examples of "new comers" (don't take that literally)
I'm confused. Are they newcomers, or are they not? If they are, why
shouldn't I take this statement literally? If they are not, how are they
good examples?
In my market, we have a integrated "all in one" system. Competitor
systems excel on one part but they only can do that because they were
able to start that way.
The same is true in all markets. All vendors face this at some people
or another, maybe GCC and Comeau will too one day, in fact, I'm sure
of it. There will be a point where GCC/Comeau no longer are as
flexible they once were, where decisions on directions have to be
made. That wasn't the case when they first started out.
Understand?
I understand that you claim this. I don't see why this must necessarily
be the case. Obviously, MSVC still evolves, with new versions being
released, bugs being fixed, new features of the upcoming standard being
implemented:
http://blogs.msdn.com/vcblog/archive/2008/10/28/visual-studio-2010-ctp-released.aspx
What are we arguing about, then?
Good question. :-)
When you stated there was a BUG
So you don't agree there is a bug? Does it imply that you don't have an
agenda, and thus are wasting time?
all I was trying to do was open your
EYES|MIND about macro substitution
I believe I understand macro substitution pretty well, thank you very
much.
I saw the ORIGINAL OP set of macros as a coder problem. You saw it as
a bug because it didn't follow C++ standard protocol for parsing.
You then went on to show a different example which you believe proved
your point, which to me, is still a coder problem when it comes to
MACROS.
The example wasn't used to prove the point. The plain reading of the
unambiguous language of the standard proves the point. As I said before,
one cannot hold up the behavior of a known-buggy compiler as a proof of
any facts about the C++ language (whether or not the compiler happens to
agree with one's point of view). The example was used to challenge the
preconceived notions of the OP, and to expose internal contradictions in
them.
In other words
#define X -1
#define Y -X
This is bad.
Stylistically, yes. I've never claimed otherwise.
You're asking for confusion and I don't expect any compiler to pick
one's brains on your intent.
It shouldn't. It should just follow the rules in the standard to
interpret the code as written, not as meant.
Question:
Should the compiler, like Alan believes it should, detect such macros
constructions like above and report there is a potential for conflict
and issue an warning or error?
line 12: Warning macros substitution results in negation
or decrement operation - "#define Y -X"
It shouldn't be an error - the construct is valid C++. I wouldn't be
against a warning (though I wouldn't sign petitions to demand it,
either). At this point, it's a quality of implementation issue, not a
conformance issue.
--
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