Hello,
I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this, but I had something
like this in mind...
int i;
for(i = 1; i < 4; i++){
int variable....
}
For example, this loop would declare the following variables all of
type int:
variable1
variable2
variable3
Is something like this possible? Is there another way?
Thanks in advance,
-Nate
Feb 13 '07
111  4531 
In article <72********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>On Tue, 27 Feb 2007 23:36:36 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>>Your counterexample shows what?
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.
Mark McIntyre wrote:
On Tue, 27 Feb 2007 23:36:36 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>Your counterexample shows what?
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?
>I'd say it's not an obvious proof of "the header isn't C".
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.
Yevgen Muntyan wrote, On 01/03/07 02:01:
Mark McIntyre wrote:
>On Tue, 27 Feb 2007 23:36:36 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>>Your counterexample shows what?
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?
Many people would say that it is *not* a good implementation, and that
is just one of the valid reasons for this.
>>I'd say it's not an obvious proof of "the header isn't C".
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?
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 believe we're done here. Nothing further need be said.
Yeah, it should have stopped long ago.
Old flames never die, they just get hotter ;-)
--
Flash Gordon
Flash Gordon wrote:
Yevgen Muntyan wrote, On 01/03/07 02:01:
>Mark McIntyre wrote:
>>On Tue, 27 Feb 2007 23:36:36 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
Your counterexample shows what?
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?
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.
>>>I'd say it's not an obvious proof of "the header isn't C".
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?
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 "fuck you" to
MM. I didn't succeed unfortunately.
Yevgen
Flash Gordon said:
Yevgen Muntyan wrote, On 01/03/07 02:01:
>Mark McIntyre wrote:
>>On Tue, 27 Feb 2007 23:36:36 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
Your counterexample shows what?
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?
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).
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield wrote, On 01/03/07 09:08:
Flash Gordon said:
>Yevgen Muntyan wrote, On 01/03/07 02:01:
>>Mark McIntyre wrote:
On Tue, 27 Feb 2007 23:36:36 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
Your counterexample shows what?
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?
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.
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.
--
Flash Gordon
Yevgen Muntyan wrote:
Mark McIntyre wrote:
>On Tue, 27 Feb 2007 23:36:36 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>>Your counterexample shows what?
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?
>>I'd say it's not an obvious proof of "the header isn't C".
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.
Do not take that guy seriously. He just goes around
insulting everyone...
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).
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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield <rj*@see.sig.invalidwrote:
: 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 wrote:
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.
--
Tor <torust [at] online [dot] no>
[snips]
On Fri, 07 Sep 2007 22:08:13 +0000, Scott J. McCaughrin wrote:
Richard Heathfield <rj*@see.sig.invalidwrote:
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.
"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:pa************@spanky.localhost.net...
[snips]
On Fri, 07 Sep 2007 22:08:13 +0000, Scott J. McCaughrin wrote:
>Richard Heathfield <rj*@see.sig.invalidwrote:
>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.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm This thread has been closed and replies have been disabled. Please start a new discussion. |
