Automatically generate variables

[Kenny McCormack]

That when you force MSVC into ISO mode, it can't compile its own
header without errors.

Which is equal in value to the observation that if you remove the engine
from a car, it is no longer capable of travelling (via self-propulsion) at
the required minimum speed of most interstate highways.

 

[Yevgen Muntyan]

That when you force MSVC into ISO mode, it can't compile its own
header without errors.

MSVC is a good implementation, isn't it?

Then you are plainly an idiot.

Sure, if you say so. Syntax errors produced by unknown compiler
with unknown command line options with unknown file is an obvious
proof of everything you like. My idiocy shows, huh?

I believe we're done here. Nothing further need be said.

Yeah, it should have stopped long ago.

 

[Flash Gordon]

Yevgen Muntyan wrote, On 01/03/07 02:01:

MSVC is a good implementation, isn't it?

Many people would say that it is *not* a good implementation, and that
is just one of the valid reasons for this.

Sure, if you say so. Syntax errors produced by unknown compiler
with unknown command line options with unknown file is an obvious
proof of everything you like. My idiocy shows, huh?

Here Mark was talking about the compiler the header was *designed* for
rejecting it when told to follow the C standard. Therefore, the compiler
it is designed for does not believe that it is C, only some language
close to C.

Yeah, it should have stopped long ago.

Old flames never die, they just get hotter ;-)

 

[Yevgen Muntyan]

Yevgen Muntyan wrote, On 01/03/07 02:01:

Many people would say that it is *not* a good implementation, and that
is just one of the valid reasons for this.

Note that there are other versions of windows api headers. For instance,
mingw, which is *almost* standard C. "almost" because it uses gcc
__attribute__ thing unconditionally. But does it say anything about
program which uses it? Nope, the *implementation* may use C++ mixed with
perl in its own private parts. It's the user code that matters.
You can take mingw's string.h and compile it with some other compiler
and get bunch of syntax errors, it wouldn't mean anything, would it.
(And of course it was said like twenty times that windows.h isn't
standard C just because it isn't and need not to be)

So, one takes windows.h from his particular brain dead implementation,
an implementation which rejects its own header, makes it produce
errors, and it says anything about particular *program* which uses
windows api, the program which uses only function declarations and no
fancy syntax, no fancy nothing? Oh yeah.

Here Mark was talking about the compiler the header was *designed* for
rejecting it when told to follow the C standard. Therefore, the compiler
it is designed for does not believe that it is C, only some language
close to C.

I didn't not try to understand carefully what he's talking about when
calling me an idiot. And I can't get what you're really saying here, are
you saying I am an idiot, he's an idiot, both, or neither? If you're
seriously replying to what I said, then don't, it wasn't designed to be
treated like that. I just tried to keep myself from saying "**** you" to
MM. I didn't succeed unfortunately.

Yevgen

 

[Richard Heathfield]

Flash Gordon said:

Yevgen Muntyan wrote, On 01/03/07 02:01:

Many people would say that it is *not* a good implementation, and that
is just one of the valid reasons for this.

I would not be one of those people, however, because it's simply not the
case. MSVC is an *excellent* implementation of C90, and it is quite
untrue that it cannot compile its own headers in C90 mode. No C90
implementation is under any obligation to be able to compile arbitrary
code in some arbitrary header named <windows.h>, whether or not that
header was shipped with the implementation. What matters from a
conformance perspective is whether MSVC can compile its own C90
standard headers. And it can.

IIRC MSVC does (correctly) issue a diagnostic message for a wayward //
in math.h - which, in an ideal world, would have been a /* */ - but it
compiles just fine (which is still legal, although not required). To
turn that into an error, you need to enable the "turn all warnings into
errors" option - in other words, if you want it to fail to compile its
own headers, you have to *try*. By default, it works just fine.

I cannot agree that MSVC is not a good implementation of C90 (and I am
by no means a Microsoft advocate, as I'm sure many people here are
already aware).

 

[Flash Gordon]

Richard Heathfield wrote, On 01/03/07 09:08:

Flash Gordon said:


I would not be one of those people, however, because it's simply not the
case. MSVC is an *excellent* implementation of C90, and it is quite
untrue that it cannot compile its own headers in C90 mode. No C90
implementation is under any obligation to be able to compile arbitrary
code in some arbitrary header named <windows.h>, whether or not that
header was shipped with the implementation. What matters from a
conformance perspective is whether MSVC can compile its own C90
standard headers. And it can.

I would say that if the header is shipped with the compiler then it is
its header. However, there might be good reasons for it not to compile
(or generate warnings) on using non-standard headers. Although I
personally would find anything more than something like "WARNING: Use of
non-standard header, your program will not be portable to other
implementations" to be an annoyance.

IIRC MSVC does (correctly) issue a diagnostic message for a wayward //
in math.h - which, in an ideal world, would have been a /* */ - but it
compiles just fine (which is still legal, although not required). To

Well, as it is in one of its standard headers it is required to jump
though whatever hoops it needs to in order to be able to use it in
standard conforming mode. It is, of course, legal for it to warn about
this although it would be better if it did not generate any warnings on
math.h whatever options you provided.

turn that into an error, you need to enable the "turn all warnings into
errors" option - in other words, if you want it to fail to compile its
own headers, you have to *try*. By default, it works just fine.

I cannot agree that MSVC is not a good implementation of C90 (and I am
by no means a Microsoft advocate, as I'm sure many people here are
already aware).

Well, I was not expressing my opinion just pointing out what many others
say. I have not used it enough myself to have that strong an opinion.

 

[jacob navia]

MSVC is a good implementation, isn't it?



Sure, if you say so. Syntax errors produced by unknown compiler
with unknown command line options with unknown file is an obvious
proof of everything you like. My idiocy shows, huh?



Yeah, it should have stopped long ago.

Do not take that guy seriously. He just goes around
insulting everyone...

 

[Richard Heathfield]

Flash Gordon said:

Richard Heathfield wrote, On 01/03/07 09:08:


Well, I was not expressing my opinion just pointing out what many
others say. I have not used it enough myself to have that strong an
opinion.

But I *have* used MSVC very heavily indeed, ever since 1.0 days. In all
that time, I have never, ever encountered a bug in its C90
implementation in real-world code (except, perhaps, if you count that
math.h // thing). Lots of times I *thought* I'd found a bug, but it
always turned out that the compiler was just reacting in a conforming
way that I didn't happen to expect. People have posted MSVC C90 bugs
here in clc, and I don't deny that those bugs exist, but I've never hit
them myself - and I've been using Visual C a *lot*, for a great many
years, in conforming mode.

Microsoft are far from being my favourite software company, but I don't
see any justification for claiming that their C90 compiler is poorly
implemented.

 

[Scott J. McCaughrin]

: Flash Gordon said:
: > Richard Heathfield wrote, On 01/03/07 09:08:

: <snip>

: >> I cannot agree that MSVC is not a good implementation of C90 (and I
: >> am by no means a Microsoft advocate, as I'm sure many people here are
: >> already aware).

I find that a rather arrogant presumption: how do you know the number of
people "already aware" of your position - do you keep track? Can you provide
stats? But then, how are we to believe your stats?

: >
: > Well, I was not expressing my opinion just pointing out what many
: > others say. I have not used it enough myself to have that strong an
: > opinion.

: But I *have* used MSVC very heavily indeed, ever since 1.0 days. In all
: that time, I have never, ever encountered a bug in its C90
: implementation in real-world code (except, perhaps, if you count that
: math.h // thing). Lots of times I *thought* I'd found a bug, but it
: always turned out that the compiler was just reacting in a conforming
: way that I didn't happen to expect. People have posted MSVC C90 bugs
: here in clc, and I don't deny that those bugs exist, but I've never hit
: them myself - and I've been using Visual C a *lot*, for a great many
: years, in conforming mode.


So you *have* encounered an MVSC bug in "that math.h // thing" as you
call it. And you admit "people have posted MVSC C90 bugs ... and I don't
deny that those bugs exist", so why this ostensible disclaimer about bugs,
when you admit to them being reported?

 

[Richard Heathfield]

Scott J. McCaughrin said, in a reply to an article about six months old:

: Flash Gordon said:
: > Richard Heathfield wrote, On 01/03/07 09:08:

: <snip>

: >> I cannot agree that MSVC is not a good implementation of C90 (and
: >> I am by no means a Microsoft advocate, as I'm sure many people
: >> here are already aware).

I find that a rather arrogant presumption:

Do you.

how do you know the number
of people "already aware" of your position - do you keep track?

No, but I presume that many people who subscribe to comp.lang.c can
read, and I have made my attitude towards Microsoft clear on several
occasions in the past. Note, also, that I said "many", not "most". How
many is "many"? Well, it's in the eye of the beholder.

Can you provide stats? But then, how are we to believe your stats?

No, I can't, provide stats; no, I don't feel the need to provide stats;
and no, there are no stats to believe or disbelieve.

: > Well, I was not expressing my opinion just pointing out what many
: > others say. I have not used it enough myself to have that strong
: > an opinion.

: But I *have* used MSVC very heavily indeed, ever since 1.0 days. In
: all that time, I have never, ever encountered a bug in its C90
: implementation in real-world code (except, perhaps, if you count
: that math.h // thing). Lots of times I *thought* I'd found a bug,
: but it always turned out that the compiler was just reacting in a
: conforming way that I didn't happen to expect. People have posted
: MSVC C90 bugs here in clc, and I don't deny that those bugs exist,
: but I've never hit them myself - and I've been using Visual C a
: *lot*, for a great many years, in conforming mode.


So you *have* encounered an MVSC bug in "that math.h // thing" as you
call it.

Yes, I think it's in VS6 and prior (and maybe even in later versions)
that Microsoft's math.h uses a BCPL-style comment in code parsed by the
C preprocessor. It's a minor thing, but it does produce a diagnostic
message at level 4, which is a little irritating, no more.

And you admit "people have posted MVSC C90 bugs ... and I
don't deny that those bugs exist", so why this ostensible disclaimer
about bugs, when you admit to them being reported?

Because they're in dark corners of the language that, to me at least,
have no particular significance or relevance. If you would care to dig
out some counter-examples that are particularly significant or relevant
to you, I'll be happy to discuss them.

 

[Tor Rustad]

Scott J. McCaughrin said, in a reply to an article about six months old:
[...]

And you admit "people have posted MVSC C90 bugs ... and I
don't deny that those bugs exist", so why this ostensible disclaimer
about bugs, when you admit to them being reported?

Because they're in dark corners of the language that, to me at least,
have no particular significance or relevance. If you would care to dig
out some counter-examples that are particularly significant or relevant
to you, I'll be happy to discuss them.

I second that, I have only used VC++ since 1.5 days though. The most
annoying thing, is perhaps MS implementation of the signal(...)
function, which is pretty useless.

 

[Kelsey Bjarnason]

[snips]

Richard Heathfield <[email protected]> wrote:

I find that a rather arrogant presumption: how do you know the number of
people "already aware" of your position

Because he's been here for years, as have many others, so unless they are
*completely* oblivious to his posting history - i.e. they've managed, for
all that time, to avoid reading a significant number of his posts -
they'll know this. Further, many have discussed the matter with him,
directly, meaning that many are in fact quite well aware of it, directly
and personally.

 

[Malcolm McLean]

[snips]

Richard Heathfield <[email protected]> wrote:

I find that a rather arrogant presumption: how do you know the number of
people "already aware" of your position

Because he's been here for years, as have many others, so unless they are
*completely* oblivious to his posting history - i.e. they've managed, for
all that time, to avoid reading a significant number of his posts -
they'll know this. Further, many have discussed the matter with him,
directly, meaning that many are in fact quite well aware of it, directly
and personally.

I used to be rather pro- Microsoft. Not any more, not since they broke the
compiler I use to compile BASICdraw. So people's positions can change.