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  4690 
On Sun, 25 Feb 2007 03:05:52 GMT, in comp.lang.c , Yevgen Muntyan
<mu************ ****@tamu.eduwr ote:
>Mark McIntyre wrote:
>On Fri, 23 Feb 2007 21:22:14 GMT, in comp.lang.c , Yevgen Muntyan
<mu*********** *****@tamu.eduw rote:
>>In case of original program using windows.h
you *do* know what windows.h is, and you do know that's a C program.
This is where I disagree fairly strongly, and I've given evidence to
back my position elsethread, and a bit more below.
Evidence of what, that you didn't know what windows.h was?
No, that its not a C programme.
>I am still claiming you knew very well that windows.h in JN's code was the windows api
I see, you can read my thoughts...
>
>For example, the Windows.h that came with MSVC 6.0 contains a 79
illegal or erroneous constructs eg:
winnt.h(357) : error C2467: illegal declaration of anonymous 'struct'
winnt.h(1519 ) : error C2054: expected '(' to follow '_inline'
winnt.h(1519 ) : error C2085: 'GetFiberData' : not in formal param list
winnt.h(1519 ) : error C2143: syntax error : missing ';' before '{'
winnt.h(4357 ) : error C2467: illegal declaration of anonymous 'union'
You snipped some stuff, didn't you?
Yes, I snipped the other 74 errors.
>C and C++ compilers are famous
by very sane error messages which follow the first, real one.
I see - you think I disengenuously forged the error messages by hiding
the real one. Think again, and perhaps even try this yourself.
Remember to disable language extensions.
>take any standard headers
of any implementation, and try to use them with another implementation
which wasn't intentionally made compatible with the first one (like
icc which pretends it's gcc, or like mingw which is both gcc and
accepting-windows-headers).
Fascinating. However I was compiling the MSVC6.0 version of windows.h
with... wait for it.... MSVC6.0.
>We are not discussing quality of microsoft implementation,
we are discussing a C program which uses that silly windows
api. It's the *same program*, and it is a *C program*.
Actually, you're now proving my point - it *becomes* a C programme,
provided the contents of windows.h are valid C. This is the crux of
the matter. Unless you know whats in that, you can only say that it
*may* be a C programme.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
On Sun, 25 Feb 2007 10:18:31 GMT, in comp.lang.c , Yevgen Muntyan
<mu************ ****@tamu.eduwr ote:
>It doesn't cover the following thing (not "program", it's what we
are arguing about):
For the record, the below is *NOT* what we're arguing about.
>two files, file.h and file.c:
file.h: empty;
file.c:
------------------
#include "file.h"
int main (void)
{
return 0;
}
Still, most people here agree it's a C program, or C code, "C"
in short.
The above /is/ C, since the contents of file.h are known and are valid
C. This differs from the example with windows.h since we don't know
the content (and in fact I've proved elsethread that the one file we
thought it might have been isn't valid C).
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mark McIntyre wrote:
On Sun, 25 Feb 2007 10:18:31 GMT, in comp.lang.c , Yevgen Muntyan
<mu************ ****@tamu.eduwr ote:
>It doesn't cover the following thing (not "program", it's what we
are arguing about):
For the record, the below is *NOT* what we're arguing about.
>two files, file.h and file.c:
file.h: empty;
file.c:
------------------
#include "file.h"
int main (void)
{
return 0;
}
Still, most people here agree it's a C program, or C code, "C"
in short.
The above /is/ C, since the contents of file.h are known and are valid
C. This differs from the example with windows.h since we don't know
the content (and in fact I've proved elsethread that the one file we
thought it might have been isn't valid C).
Um, and I proved elsethread that it's been valid C by compiling
it with gcc and icc? Funny.
Anyway, you're saying the above is valid C. Why? The standard
doesn't say it is. This program relies on implementation-defined
ways to process #include directives. It's not strictly conforming.
It is conforming. How *much* is it different from a program which
uses windows.h, a header file which is part of certain implementation?
I.e. how do you define that something not standard is C, and something
isn't? I apply common sense, you?
As far as standard is concerned, they are the same. Both conforming,
and both not strictly conforming. Now we can talk about what "is C"
and what is "pseudo C crap" or something, and it's what we are arguing
about. But you can't *prove* anything here by compiling/miscompiling
something (something which is part of implementation, like string.h,
which isn't required to be standard C code).
For the record, this file.c and file.h program is of course C.
Yevgen
Keith Thompson <ks***@mib.orgw rote:
Beej Jorgensen <be**@beej.uswr ites:
7.1.2 paragraph 3:
If a file with the same name as one of the above < and delimited
sequences, not provided as part of the implementation, is placed in
any of the standard places that are searched for included source
files, the behavior is undefined.
Interesting. That says that if I place a "stdlib.h" file in one of
the places searched for a
#include "stdlib.h"
directive but *not* for a
#include <stdlib.h>
directive, then the behavior is undefined. I suspect that wasn't the
intent.
I suspect that the intent was that if you place a new stdlib.h in one of
the <places, you're effectively creating a new C _implementation _, not
a new C source program. If you place a stdlib.h in one of the "" places,
you're doing the latter, trying to create a different program in C, but
one that has undefined behaviour.
Richard rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.orgw rote:
>Beej Jorgensen <be**@beej.uswr ites:
7.1.2 paragraph 3:
If a file with the same name as one of the above < and delimited
sequences, not provided as part of the implementation, is placed in
any of the standard places that are searched for included source
files, the behavior is undefined.
Interesting. That says that if I place a "stdlib.h" file in one of
the places searched for a
#include "stdlib.h"
directive but *not* for a
#include <stdlib.h>
directive, then the behavior is undefined. I suspect that wasn't the
intent.
I suspect that the intent was that if you place a new stdlib.h in one of
the <places, you're effectively creating a new C _implementation _, not
a new C source program. If you place a stdlib.h in one of the "" places,
you're doing the latter, trying to create a different program in C, but
one that has undefined behaviour.
I don't see any reason for the latter to have UB other than the fact
that 7.1.2p3 explicitly says so (or seems to). If I create a file
stdlib.h in one of the "" places, and my program has
#include <stdlib.h>
then the compiler should never even look at the stdlib.h I created.
--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
In article <45************ ****@news.xs4al l.nl rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.orgw rote:
Beej Jorgensen <be**@beej.uswr ites:
7.1.2 paragraph 3:
>
If a file with the same name as one of the above < and delimited
sequences, not provided as part of the implementation, is placed in
any of the standard places that are searched for included source
files, the behavior is undefined.
Interesting. That says that if I place a "stdlib.h" file in one of
the places searched for a
#include "stdlib.h"
directive but *not* for a
#include <stdlib.h>
directive, then the behavior is undefined. I suspect that wasn't the
intent.
I suspect that the intent was that if you place a new stdlib.h in one of
the <places, you're effectively creating a new C _implementation _, not
a new C source program. If you place a stdlib.h in one of the "" places,
you're doing the latter, trying to create a different program in C, but
one that has undefined behaviour.
I think the intent was that when the compiler recognises the name of a
standard include file it is allowed to act accordingly.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter wrote:
In article <45************ ****@news.xs4al l.nlrl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.orgw rote:
Beej Jorgensen <be**@beej.uswr ites:
7.1.2 paragraph 3:
>
If a file with the same name as one of the above < and delimited
sequences, not provided as part of the implementation, is placed in
any of the standard places that are searched for included source
files, the behavior is undefined.
Interesting. That says that if I place a "stdlib.h" file in one of
the places searched for a
#include "stdlib.h"
directive but *not* for a
#include <stdlib.h>
directive, then the behavior is undefined. I suspect that wasn't the
intent.
>
I suspect that the intent was that if you place a new stdlib.h in one of
the <places, you're effectively creating a new C _implementation _, not
a new C source program. If you place a stdlib.h in one of the "" places,
you're doing the latter, trying to create a different program in C, but
one that has undefined behaviour.
I think the intent was that when the compiler recognises the name of a
standard include file it is allowed to act accordingly.
Below is the quote from comp.std.c thread about #include:
Douglas A. Gwyn wrote:
"Yevgen Muntyan" <mu************ ****@tamu.eduwr ote...
[snip]
>? Or "string.h", what if implementation treats
#include "string.h"
as
#include <string.h>
It is supposed to apply its defined search rules first, and only if not
found in that search should it use the standard header. Note that it
is a useful programming practice for portability to use "" instead of
<for standard headers, since it makes it possible to substitute
application-provided replacements when necessary to compensate
for problems in the implementation-provided headers, without
affecting the system files.
It'd be not so nice if this "useful programming practice" actually
relied on undefined behavior. But then, another quote:
Jun Woong wrote:
genn...@invalid .address.com wrote:
[...]
>* #include "stdio.h"
would search for a source file first, if the search is supported;
if it is not, or if the search fails, it is processed as if it were
#include <stdio.h>
Unless #include "stdio.h" triggers the undefined behavior.
Apparently it's one more nice topic for comp.std.c, without
answers thanks to nice wording in the standard ;)
Yevgen
On Sun, 25 Feb 2007 23:32:05 GMT, in comp.lang.c , Yevgen Muntyan
<mu************ ****@tamu.eduwr ote:
>the content (and in fact I've proved elsethread that the one file we
thought it might have been isn't valid C).
Um, and I proved elsethread that it's been valid C by compiling
it with gcc and icc? Funny.
As I'm sure you're aware, if you can find one counterexample it
disproves a theory. Any number of examples which match the theoretical
outcome are useless.
>Anyway, you're saying the above is valid C. Why? The standard
doesn't say it is.
I disagree, but now you're picking at nonexistent nits and engaging in
disingenuous and absurd arguments, and have become a troll.
>For the record, this file.c and file.h program is of course C.
Agreed.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mark McIntyre wrote:
On Sun, 25 Feb 2007 23:32:05 GMT, in comp.lang.c , Yevgen Muntyan
<mu************ ****@tamu.eduwr ote:
>>the content (and in fact I've proved elsethread that the one file we
thought it might have been isn't valid C).
Um, and I proved elsethread that it's been valid C by compiling
it with gcc and icc? Funny.
As I'm sure you're aware, if you can find one counterexample it
disproves a theory. Any number of examples which match the theoretical
outcome are useless.
Your counterexample shows what? That you can make your compiler
miscompile its own header? I'd say it's not an obvious proof
of "the header isn't C". In any case, *the program which uses
the header* is C (that program, not any, not always).
We could talk about version of your compiler, about version
of my compiler which I use with <windows.hheade r, about
non-conforming Microsoft implementation, about possibility to make
up that header without using non-standard stuff so that the program
still has the same meaning, about standard headers of whatever-you-like
compiler and "proving" they are not C, but you don't want to, right?
You simply mistreated some piece of soft you have there and tell
it's a "proof".
>Anyway, you're saying the above is valid C. Why? The standard
doesn't say it is.
I disagree, but now you're picking at nonexistent nits and engaging in
disingenuous and absurd arguments,
Um, in what part exactly? Could you check the thread in comp.std.c
about the #include? I wouldn't say that's a 100% proof of something,
but I do believe it's not just nonexistent nits. *I* claim that
a C program need not to be strictly conforming. *You* do not agree
with this, and at the same time you do not agree to use strictest
definition, the strictly conforming program notion, you simply
can't afford that since you'd end up with writing in "beep beep"
language instead of C. So what's C? What you're saying and thinking it
is? I wouldn't object, if you admitted that. But you don't, you think
your opinion is from gods or from standard or something, and mine is
junk.
and have become a troll.
I thought trolling is "beep beep not C".
Yevgen
On Tue, 27 Feb 2007 23:36:36 GMT, in comp.lang.c , Yevgen Muntyan
<mu************ ****@tamu.eduwr ote:
>Your counterexample shows what?
That when you force MSVC into ISO mode, it can't compile its own
header without errors.
>I'd say it's not an obvious proof of "the header isn't C".
Then you are plainly an idiot.
I believe we're done here. Nothing further need be said.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan This thread has been closed and replies have been disabled. Please start a new discussion. |
