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  4562 
Yevgen Muntyan wrote:
Mark McIntyre wrote:
jacob navia wrote:
Mark McIntyre wrote:
<snip>
>There isn't - you can't define object names at runtime in C.
Wrong
#include <stdio.h>
#include <windows.h>
Beep beep. This isn't C.
void *h = LoadLibrary("va riables.dll");
fn = (void (*fn)(int))GetP rocAddress("Get DynamicObject") ;
This isn't either.
Nonsense. It is C. It's not strictly conforming, it won't work
almost anywhere, it's rather useless, it's off-topic here, all this
was in details explained in another reply to JN post. But it is C,
where "C" means "C language as defined by the ISO standard".
But the ISO standard doesn't define the windows.h header or the
functions LoadLibrary or GetProcAddress. It uses the syntax and
semantics as defined in the standard, but uses various extensions not
defined in the standard. If one or more of these extensions change the
standard syntax and semantics of C, then it's debatable if the
resulting code can even be called as C. That's why GNU C is called as
GNU C and not C.
santosh a écrit :
Yevgen Muntyan wrote:
>>Mark McIntyre wrote:
>>>jacob navia wrote:
Mark McIntyre wrote:
<snip>
>>>>>There isn't - you can't define object names at runtime in C.
Wrong
#include <stdio.h>
#include <windows.h>
Beep beep. This isn't C.
void *h = LoadLibrary("va riables.dll");
fn = (void (*fn)(int))GetP rocAddress("Get DynamicObject") ;
This isn't either.
Nonsense. It is C. It's not strictly conforming, it won't work
almost anywhere, it's rather useless, it's off-topic here, all this
was in details explained in another reply to JN post. But it is C,
where "C" means "C language as defined by the ISO standard".
But the ISO standard doesn't define the windows.h header or the
functions LoadLibrary or GetProcAddress. It uses the syntax and
semantics as defined in the standard, but uses various extensions not
defined in the standard. If one or more of these extensions change the
standard syntax and semantics of C, then it's debatable if the
resulting code can even be called as C. That's why GNU C is called as
GNU C and not C.
This means that there is no single serious program besides hello world
ones that is written in C.
OK?
Neither the linux kernel, nor all the network programs, nor any GUI
program, nor any library that uses graphics, networking, threads,
exception handling, nor the dynamic loader, nor any program that uses
a directory structure (file directories aren't defined in standard
C) nor all the embedded systems that use myriads of extensions
adapted to each circuit board, etc.
There are then NO PROGRAMS WRITTEN IN C.
Satisfied?
santosh wrote:
Yevgen Muntyan wrote:
>Mark McIntyre wrote:
>>jacob navia wrote:
Mark McIntyre wrote:
<snip>
>>>>There isn't - you can't define object names at runtime in C.
Wrong
#include <stdio.h>
#include <windows.h>
Beep beep. This isn't C.
void *h = LoadLibrary("va riables.dll");
fn = (void (*fn)(int))GetP rocAddress("Get DynamicObject") ;
This isn't either.
Nonsense. It is C. It's not strictly conforming, it won't work
almost anywhere, it's rather useless, it's off-topic here, all this
was in details explained in another reply to JN post. But it is C,
where "C" means "C language as defined by the ISO standard".
But the ISO standard doesn't define the windows.h header or the
functions LoadLibrary or GetProcAddress. It uses the syntax and
semantics as defined in the standard, but uses various extensions not
defined in the standard.
This is true, but we have a choice here: call a "C program" only
strictly conforming programs or use a wider definition. The former
is what I call nonsense, simply because it's too restrictive - if
one accepts such definition of a "C program", then all those C
programmers out there are writing programs in some fancy language
which is not C, and all those C programs out there are not C
programs. Then, I think the standard exists to make people able
to write C programs using extensions. And it uses term "strictly
conforming" exactly to distinguish programs which are completely
described and programs which use extensions but are still C programs,
but to not restrict itself only to those strictly conforming
programs. The syntax and semantics of "a C program" have very big
value, what would be the point of having the standard which simply
stops working as soon as non-standard header is used?
I personally don't have that wider definition, and I don't think
anyone could come up with something sensible here. And it's the
reason why *on-topic* here are only strictly conforming programs.
But there is more to C than programs using only standard features.
For instance, a C program which uses POSIX regex to work with
some strings, or a program which uses windows API to print list of
processes, are C programs as long as they don't use some fancy
non-C syntax or mechanics (insert "semantics" here).
If one or more of these extensions change the
standard syntax and semantics of C, then it's debatable if the
resulting code can even be called as C. That's why GNU C is called as
GNU C and not C.
I'd say "GNU C" is the same nonsense as "C/C++". There is one C
language, and there are extensions to it; "C with GNU extensions" sounds
better here. If you need gcc to compile a program, then it's not
a "C program as defined by the C standard", it's a program written
in GCC dialect of C or whatever you call it. But if any working
(QoI thing here) compiler on given platform (one more non-standard
thing, you got to accept that <windows.his only for windows) can
compile it without any fancy compatibility switches, then it's C. It's
just an empiric test of course, without 100% success guarantee. But
then, one can't prove that given program of reasonable complexity is
strictly-conforming either (I guess one could say he can get all
conforming implementations in the world and simply check, according
to the definition, I'd love to see that).
Anyway, answer to "C or not C" certainly should not involve sympathy or
antipathy to Jacob Navia. Saying "beep beep not C hahaha because I don't
like you" is total nonsense. Off-topic, sure. But C. If one says
that silly JN's program isn't C, he says that the great deal of C
programs (like all the C programs which work on your computer, except
maybe one) suddenly stop being C programs. And that's nonsense.
And it's not only about JN's program of course, elsewhere people already
told that C means in comp.lang.c something different than in the
rest of the world.
Yevgen
jacob navia wrote, On 17/02/07 19:08:
santosh a écrit :
<snip>
>resulting code can even be called as C. That's why GNU C is called as
GNU C and not C.
This means that there is no single serious program besides hello world
ones that is written in C.
OK?
Neither the linux kernel, nor all the network programs, nor any GUI
program, nor any library that uses graphics, networking, threads,
exception handling, nor the dynamic loader, nor any program that uses
a directory structure (file directories aren't defined in standard
C) nor all the embedded systems that use myriads of extensions
adapted to each circuit board, etc.
There are then NO PROGRAMS WRITTEN IN C.
Satisfied?
You've posted this before when people have pointed out that some things
are not C but extensions. The answer is still the same that some
programs can be written completely in standard C and vast amount more
can have 95% written in standard C with the remaining 5% nicely isolated
and written in whatever system specific method is appropriate.
--
Flash Gordon
Flash Gordon wrote:
jacob navia wrote, On 17/02/07 19:08:
>santosh a écrit :
<snip>
>>resulting code can even be called as C. That's why GNU C is called as
GNU C and not C.
This means that there is no single serious program besides hello world
ones that is written in C.
OK?
Neither the linux kernel, nor all the network programs, nor any GUI
program, nor any library that uses graphics, networking, threads,
exception handling, nor the dynamic loader, nor any program that uses
a directory structure (file directories aren't defined in standard
C) nor all the embedded systems that use myriads of extensions
adapted to each circuit board, etc.
There are then NO PROGRAMS WRITTEN IN C.
Satisfied?
You've posted this before when people have pointed out that some things
are not C but extensions. The answer is still the same that some
programs can be written completely in standard C and vast amount more
can have 95% written in standard C with the remaining 5% nicely isolated
and written in whatever system specific method is appropriate.
Looks like there are two ways to apply C standard in real life. One is
to call C programs (not necessarily strictly conforming) C programs;
another one is to claim that something *can* be done in some way. Note
that the standard doesn't know what it means 95% is C and 5% isn't.
You pollute your program with "1%" of non-C and it stops being C,
the whole thing is no longer a C program (namely what you call a C
program). And it's certainly true that vast majority of real C programs
installed on computers are not written that way, 95% here and 5%
isolated there. Jacob isn't right here of course, there are strictly
conforming C programs, sure. But his statement (the conditional one,
the "if that's not C then there are no C programs") is far closer
to reality and truth than your "answer", that "vast amount more *can*
have .." (emphasis mine).
I do agree that Jacob is one of persons who make it harder to talk
about real life C applications here, but if one wants to shut him up,
he can choose lot of other things, without the need to make this
newsgroup like bunch of jerks who pretend real programs are not what
they actually are.
Yevgen
Yevgen Muntyan wrote:
santosh wrote:
Yevgen Muntyan wrote:
Mark McIntyre wrote:
jacob navia wrote:
Mark McIntyre wrote:
<snip>
>>#include <stdio.h>
#include <windows.h>
Beep beep. This isn't C.
<snip>
Nonsense. It is C. It's not strictly conforming, it won't work
almost anywhere, it's rather useless, it's off-topic here, all this
was in details explained in another reply to JN post. But it is C,
where "C" means "C language as defined by the ISO standard".
But the ISO standard doesn't define the windows.h header or the
functions LoadLibrary or GetProcAddress. It uses the syntax and
semantics as defined in the standard, but uses various extensions not
defined in the standard.
This is true, but we have a choice here: call a "C program" only
strictly conforming programs or use a wider definition. The former
is what I call nonsense, simply because it's too restrictive - if
one accepts such definition of a "C program", then all those C
programmers out there are writing programs in some fancy language
which is not C, and all those C programs out there are not C
programs. Then, I think the standard exists to make people able
to write C programs using extensions. And it uses term "strictly
conforming" exactly to distinguish programs which are completely
described and programs which use extensions but are still C programs,
but to not restrict itself only to those strictly conforming
programs. The syntax and semantics of "a C program" have very big
value, what would be the point of having the standard which simply
stops working as soon as non-standard header is used?
<rest snipped>
I can see your reasoning.
The imaginary boundary which divides a peice of code from being
reasonably called as C from being in a C-like language is undefined
and blurred. The standard fully defines conforming C programs. In
addition it allows implementation specific decisions for various
aspects and extensions as well. Certainly the code posted by jacob
navia qualifies as C code. The issue is what we exactly mean by term C
code. If we mean "the language as defined by the C standard", (which
is what you wrote earlier), then does his code snippet qualify as C
code? I think so.
But what about more fundamental extensions like the && gcc extension
discussed in another thread or the various operator overloading
features implemented by the lcc-win32 compiler? Can code that use such
"radical" extensions still be called as C? I don't think so. What
makes one extension reasonable and another not, from the POV of being
compatible with C?
Unless we take the strict approach of adhering to what the standard
specifies and allows, we seem to get into a lot of "gray areas" about
what is, and is not, C. It seems to ultimately come down to personal
opinion, something I'm not happy about.
santosh said:
<snip>
The imaginary boundary
....is not imaginary, and is not a boundary.
which divides a peice of code from being
reasonably called as C from being in a C-like language is undefined
and blurred.
Yes, it's more like a beard than a boundary. Does a man with one hair on
his chin have a beard? Clearly not. Does a man with ten thousand hairs
on his chin have a beard? Yes, and to spare! So where is the dividing
line? If we say a man with N hairs on his chin has no beard, but a man
with N + 1 hairs /does/ have a beard, people would rightly laugh. And
yet some men have beards, and others don't.
The standard fully defines conforming C programs.
Perhaps, but not their behaviour. It only says that a conforming C
program is one that is acceptable to a conforming implementation.
<snip>
Unless we take the strict approach of adhering to what the standard
specifies and allows, we seem to get into a lot of "gray areas" about
what is, and is not, C. It seems to ultimately come down to personal
opinion, something I'm not happy about.
Yes, the concept of "strictly conforming" is too strong to be useful,
and the concept of "conforming " too weak. In this newsgroup, the
concept of "comp.lang. c-conforming" has proved itself to be far more
effective.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Yevgen Muntyan a écrit :
I do agree that Jacob is one of persons who make it harder to talk
about real life C applications here, but if one wants to shut him up,
he can choose lot of other things, without the need to make this
newsgroup like bunch of jerks who pretend real programs are not what
they actually are.
Yevgen
Look Yevgen, I can't parse that sentence. Maybe shorter sentences would do.
What I wanted to demonstrate with my snippet is basically:
1) You can use a C program to generate a C source file.
2) You can use the C compiler to compile it
3) You can use the dynamic loader to load it into memory
4) You can get a function pointer from the loaded file
and execute it.
This is possible in a wide variety of systems, from Unix, to
Windows, to many embedded systems. It is called a JIT, a
Just In Time compiler. Obviously how do you implement those
steps is system specific, and will change slightly from
system to system.
Instead of going into the question at hand (generating C
programs dynamically) we delve into boring stuff about
this being C or not. This is ridiculous and hinders any
discussion about real programs.
jacob
P.S. I do see the danger of discussiong very system specific
stuff, but the OTHER danger, not discussing anything at all but
the restricted subset of C proposed by some people here is even
worst!
santosh wrote:
>
But what about more fundamental extensions like the && gcc extension
discussed in another thread or the various operator overloading
features implemented by the lcc-win32 compiler? Can code that use such
"radical" extensions still be called as C? I don't think so. What
makes one extension reasonable and another not, from the POV of being
compatible with C?
One has to draw the distinction between extensions to the language (the
&& gcc extension and operator overloading) and platform specific
libraries. It is a fairly straightforward exercise for a developer to
implement a set of functions defined in a library (say Posix file
handling or BSD style sockets), but not to implement extensions to the
language. Which makes the former portable and the latter not.
Anything which conforms to the language defined in the current C
standard is a C program, which includes programs that include
non-standard headers.
--
Ian Collins.
santosh wrote:
Yevgen Muntyan wrote:
>santosh wrote:
>>Yevgen Muntyan wrote:
Mark McIntyre wrote:
jacob navia wrote:
>Mark McIntyre wrote:
<snip>
>>>>>#include <stdio.h>
>#include <windows.h>
Beep beep. This isn't C.
<snip>
>>>Nonsense. It is C. It's not strictly conforming, it won't work
almost anywhere, it's rather useless, it's off-topic here, all this
was in details explained in another reply to JN post. But it is C,
where "C" means "C language as defined by the ISO standard".
But the ISO standard doesn't define the windows.h header or the
functions LoadLibrary or GetProcAddress. It uses the syntax and
semantics as defined in the standard, but uses various extensions not
defined in the standard.
This is true, but we have a choice here: call a "C program" only
strictly conforming programs or use a wider definition. The former
is what I call nonsense, simply because it's too restrictive - if
one accepts such definition of a "C program", then all those C
programmers out there are writing programs in some fancy language
which is not C, and all those C programs out there are not C
programs. Then, I think the standard exists to make people able
to write C programs using extensions. And it uses term "strictly
conforming" exactly to distinguish programs which are completely
described and programs which use extensions but are still C programs,
but to not restrict itself only to those strictly conforming
programs. The syntax and semantics of "a C program" have very big
value, what would be the point of having the standard which simply
stops working as soon as non-standard header is used?
<rest snipped>
I can see your reasoning.
The imaginary boundary which divides a peice of code from being
reasonably called as C from being in a C-like language is undefined
and blurred. The standard fully defines conforming C programs.
No it doesn't, it fully defines strictly conforming programs,
the ones which in particular do not contain code like
#include "foo.h"
"Just" conforming is no good, C++ programs seem to be conforming
because gcc accepts them, and gcc is a conforming implementation
(GNU compiler collection, that is, not the binary called 'gcc').
In
addition it allows implementation specific decisions for various
aspects and extensions as well. Certainly the code posted by jacob
navia qualifies as C code. The issue is what we exactly mean by term C
code. If we mean "the language as defined by the C standard", (which
is what you wrote earlier), then does his code snippet qualify as C
code? I think so.
Yes, I do think so too.
But what about more fundamental extensions like the && gcc extension
discussed in another thread or the various operator overloading
features implemented by the lcc-win32 compiler? Can code that use such
"radical" extensions still be called as C? I don't think so.
I agree here too.
What
makes one extension reasonable and another not, from the POV of being
compatible with C?
And I don't know the answer for this. And as I said, I don't think
one can provide sensible answer which would not involve what one
feels as opposed to what exactly is said in some definition.
Unless we take the strict approach of adhering to what the standard
specifies and allows, we seem to get into a lot of "gray areas" about
what is, and is not, C. It seems to ultimately come down to personal
opinion,
True. But it's not bad. It seems to me people generally agree on
what's C and what's not C (unless it's an argument in comp.lang.c).
And that's what really matters.
something I'm not happy about.
Sure, it would be easier if the standard said "this is C, and the
rest isn't C and I don't care about that", but then the standard
would be useless. So we have what we have. I believe it's called
"trade off" in English.
Yevgen This thread has been closed and replies have been disabled. Please start a new discussion. |
