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 
Yevgen Muntyan wrote, On 24/02/07 11:21:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 23/02/07 21:22:
>>Flash Gordon wrote:
Yevgen Muntyan wrote, On 23/02/07 13:33:
Richard Bos wrote:
>Yevgen Muntyan <mu************ ****@tamu.eduwr ote:
>>
>>Richard Bos wrote:
>>>You're the one using non-Standard extensions and claiming they're
>>>perfectl y good C. I suggest that _you_ come up with your
>>>definiti on of
>>>what is and is not a C program. Be careful, now: some
>>>definiti ons are
>>>tricki er than they first seem. For example, simply replying "any
>>>conformi ng program" would have some unforeseen consequences...
>>Try reading the thread, you'll find some discussion of this, what
>>you're saying and more.
>>
>What I find is a whole lot of "yes it is", "no it isn't", "yes it
>is";
>but nothing that makes it clear what _you_ consider to be C. Since
>you're the one who is telling the rest of us that we're wrong,
>perhaps
>you'd like to enlighten us, rather than just contradicting.
>
Well, since it's indeed hard to read, and much easier just to pick
some words and argue about them, I'll quote myself:
>
-----------------------------------------------------
... we have a choice here: call a "C program" only
strictly conforming programs or use a wider definition. The former
<snip>
I personally don't have that wider definition, and I don't think
anyone could come up with something sensible here.
In other words you think everyone who places any kind of limit on
what a C program is is wrong.
#include <crapit>
BEGIN
print "This is C"
END
Must be C by your definition since crapit might possibly be a header
that makes it C. Or it might be a header that makes it C++ but not
C. Or maybe some other language.
Yes, it *could* be a C program, and it's indeed not hard to write that
crapit. It all depends on what in <crapit>, and whether compiler
will accept that crapit.
It was indeed carefully constructed so that given an appropriate
include then you would have C code that compiles in to a C program.
> In case of original program using windows.h
you *do* know what windows.h is, and you do know that's a C program.
If you don't know what windows.h was, you can ask.
Others have pointed out that there is more than one header file called
windows.h which are there for different purposes.
Yeah, "others". Of course there are many windows.h files, I can write
about zillion more using my favorite shell. But the windows.h header was
a windows C api header. If you don't know that, just ask ;)
For instance, I knew it was *the* windows windows.h header because the
code was posted by one famous portable-code-writer comp.lang.c regular.
He does tend to get a more extreme reaction that a newbie would because
he knows the scope of the group but flouts it anyway.
>The ones provided by MS has IIRC things which are not legal C syntax
in them (the way calling conventions etc are specified).
If you mean things like __declspec, they are fine,
implementation-specific extensions.
I agree that it is a valid way to do an extension, MS are actually quite
good in that respect. However, it violates the syntax of C because C
syntax does not allow adding anything at that point of a declaration.
Just to be clear, using __whatever to add it was doing the right thing.
Program wasn't portable and nobody
said it was, so it's fine (and windows.h is indeed a part of
implementation) . But the program itself used a nice #include
directive, which has well-defined (or rather well-understood and
well-agreed-on) semantics and the rest of code was real C code. A C
program.
Given certain assumptions the C code was valid C code, however from what
I remember it certainly was not a C program solving the problem since it
not only relied on non-C APIs (the Windows API with comments showing a
suggested Unix alternative) but also relied on external programs that in
general are *not* installed on machine.
<anip>
>I made some attempt to provide some kind of scope to what is and is
not C, although it is not perfect. You, on the other hand, just said
that it might be C even if it goes beyond what the standard defined
and gave no outer limit on what could be considered C.
Well, the standard does *not* define what is "C code". I understand
what you mean, you understand what you mean, but it's not what
standard says. Standard doesn't know what it means "N% of C code"
or "two lines of C code".
Well, the C standard does not know about anything that is *not* C code
so it does not have to make the distinction between C code and code that
is not C.
How about "C program is a program consisting of C code" anyway?
A C program consists *only* of C code.
>With no such limits then this entire post is C because for all you
know it could be an extract from a file that has /* before what is
shown here and closes the comment after. So you have to put some limit
on what you consider to be C code, you don't have to make an attempt
to tell us what it is, but if you don't then don't complain when
others express there opinion that something is not C code.
Yeah yeah, "opinion". Now do go back and read that very post, where
"others" "expressed their opinion". It wasn't "given that I have no
clue what windows.h I can't make a conclusion if it's C or not".
If I remember the post correctly it relied on there being a C compiler
on the target, where generally there is not, and on the ability to
dynamically load executable (which is only common on hosted systems, but
probably not available on *all* hosted systems). So in this particular
case the bulk of what the program was assuming was actually system
specific (and available as much through any other language in the same
way) rather than being C. It was probably close to "replace { with
begin, } with END; and int main() with PROGRAM FRED;" and you would have
a Pascal program in the same sense that you are calling it a C program.
If hanging 10% changes it to another language, but getting it to run on
a different system means changing 90% then is it really a C solution?
No, it
was "fsking no, it's non-standard therefore not C", an emotional
response caused by feelings of one person to another one.
*If* someone was interested in that program he could ask what windows.h
was. If someone wasn't interested in it, he could ignore it. But "not
C because I pretend I have no clue what it is" is nonsense.
Oh well.
Topicality is enforced to keep the experts here and so keep the group
valuable. Jacob gets extreme reactions because of how often he has
flouted topicality pushing either Windows specific code or his own
extensions to C.
<snip>
>>>>How do you distinguish "C code" from "pseudo-C crap". As far as the
standard is concerned, once you have any non-standard #include
in your file, you get "pseudo-C crap".
Only if the non-standard header is not provided or is not itself C
code. If the non-standard header has no impact on the rest of the
file then only that one line is "pseudo-C crap", if you don't know
the contents of the header then the entire presented code can
validly be considered as "pseudo-C crap".
You see, here I tightened up the definition up so that my earlier
example given on its own because "not C code".
You miss the important fact here. If you have a non-standard #include
in your C code, it may fail to be processed by a conforming C compiler.
Even if that header is empty, for instance.
In that extreme case, just provide the empty header as well and it can
safely be called C code.
You are saying that it's
C code because reasonable compiler will indeed process it; or because
you can expand #include manually; or for whatever else reason. But the
standard doesn't agree. I, from the other hand, claim that it's totally
fine to say it's a C program (or C code if you prefer), even though
it's not standard.
As far as I can see the standard only considers it to be C if it can be
compiled, so if it includes a header that does not exist then it is just
plain broken.
If you say "this header defines the prototypes for these non-standard
functions" then we can consider everything apart from those non-standard
functions as C.
I do not see a need to say that even an entire file is C or not C, this
is why I emphasise that it is the code that is C or not C since then you
can graduate it as finely as you need.
>>> Once you have one file in
your program which uses a non-standard feature (even if the other
thousand files are perfect standard C), then the program is "pseudo-C
crap". So the question stands. You like to write pseudo-C crap,
it's fine; I still believe there are lot of C programmers writing
C programs, which are C programs even if they use POSIX api, windows
api, foobar api, etc.
Personally since I started writing C hardly any programs I have
written have been C programs (or do yo consider " LAC *+,AR0" to
be C?)
It can't be made C even using preprocessor tricks, so it's not C at all.
I guess.
The point was there is a program where 90% or more is completely
standard C. Then there are a few linker tricks to get some variables
which are only ever declared as "extern" in the C mapped on to some
hardware (so the C code is not having to do tricks like converting
integers to pointers to access memory mapped devices). Then there are
one or two assembler files making up under 10% of the code. So 90% is
C but a small fraction is not, and the status of the 90% as being C
code is far more important than the status of the program as a whole.
I can't disagree here. Anyway, do you count #include <cheader.has
C code? As well as #include "cheader.h" (sure, provided the complete
listing of cheader.h is available, the standard doesn't say it will
help).
Given a reason to suppose that the C compiler will succeed (headers need
not actually be files) then yes, I would consider it to be a line of C code.
>>>but I have written a lot of C code that has been incorporated with
other stuff to produce programs.
Somehow almost all programs on my computer are written in C. You
may say they are written in "Pseudo-Unix pseudo-C crap", it's your
choice. But it's not a sensible choice.
A lot of programs are written mostly in C, but if the program as a
whole is not written in C then calling it a C program is misleading,
although saying it is mostly written in C is not.
If I write a program with 25% assembler, 25% C, 25% Java and 25%
Fortran, what language is the program written in? My answer is "a
mixture".
Yes, it's a mixture. But I wasn't talking about such cases. I was
talking about programs which have 100% C code. Using non-standard
features like "libraries" though.
Those libraries are written in something. If they are written in C
then expand your scope to include them and you have a C program (I use
XML libraries which are at least mostly written in C for example).
"Expand scope", huh? If you include their source files, it's standard.
Yes, because then it is just a number of additional C translation units.
If you use linker, it becomes non-standard,
The linker has nothing to do with it. After all, when combining multiple
translation unites (which is allowed by C) you are linking!
i.e. just as standard-C
as embedded assembly.
<sighNo, because everything is standard C! It matters not to me
whether I have written the XML library in C or whether someone else has.
If the library is in C and my code using it is in C then everything is
in C. However, if the library is in assembler (or I do not know it is C)
then what I have is C+XML-library rather than just C. If the XML library
is written in assembler then you can call it either C+XML-library or
C+assembler, your choice, if you do not know what the XML-library is
written in then all you can do is call it C+XML-library.
But the result is the same, the point is the same:
you have a C program (program consisting of C code if you prefer), you
use C headers.
No, if the libraries I am reliant on are C (i.e. part of what is defined
by the standard as C or written in C, with this applied recursively)
then the program as a whole is C. If somewhere along the line you reach
something that is not C (i.e. not written in C or not part of the
standard C library) then the program as a whole is C+whatever-is-not-C
even though the headers describing the interface to the not-C may
themselves be C.
>However, if either those extras are not C *or* you are not including
them in what you are presenting, then what you are presenting is no
longer C but C+whatever or Windows-C or POSIX-C.
Note that a header that is not part of standard C and is not provided
as part of what is presented could easily contain things which convert
your program from being valid C to being valid some-other-language. C
is not the only language to use #include! I would assume it was
C+something but I could not be completely convinced, because I do know
that there are files called windows.h which are nothing to do with MS
Windows.
Well, I just made an (completely reasonable) assumption that the
windows.h thing was indeed *that* windows.h thing. You can have
reasonable doubt in it, since it may or may not have been that
windows.h. But can you just claim "not C" because I/he didn't tell
what windows.h was? Can you tell that "beep beep not C" is just
as reasonable as my "I believe it's C program which uses windows
api"?
So you call it "C+Windows API" and I call it "Windows-C" (yes, I know
I've paraphrased you). That does not actually look like quite so far
apart. It is more that I and some others (particularly when dealing with
certain people who show repeated disregard for topicality) put more
emphasis on the "+Windows API", and even more so when almost every line
is either using the Windows API or setting things up to use the Windows API.
--
Flash Gordon
Flash Gordon wrote:
Yevgen Muntyan wrote, On 24/02/07 11:21:
>Flash Gordon wrote:
>>Yevgen Muntyan wrote, On 23/02/07 21:22:
Flash Gordon wrote:
Yevgen Muntyan wrote, On 23/02/07 13:33:
>Richard Bos wrote:
>>Yevgen Muntyan <mu************ ****@tamu.eduwr ote:
>>>
>>>Richar d Bos wrote:
>>>>You'r e the one using non-Standard extensions and claiming they're
>>>>perfect ly good C. I suggest that _you_ come up with your
>>>>definit ion of
>>>>what is and is not a C program. Be careful, now: some
>>>>definit ions are
>>>>trickie r than they first seem. For example, simply replying "any
>>>>conform ing program" would have some unforeseen consequences...
>>>Try reading the thread, you'll find some discussion of this, what
>>>you're saying and more.
>>>
>>What I find is a whole lot of "yes it is", "no it isn't", "yes it
>>is";
>>but nothing that makes it clear what _you_ consider to be C. Since
>>you're the one who is telling the rest of us that we're wrong,
>>perhaps
>>you'd like to enlighten us, rather than just contradicting.
>>
>Well, since it's indeed hard to read, and much easier just to pick
>some words and argue about them, I'll quote myself:
>>
>-----------------------------------------------------
>... we have a choice here: call a "C program" only
>strictly conforming programs or use a wider definition. The former
>
<snip>
>
>I personally don't have that wider definition, and I don't think
>anyone could come up with something sensible here.
>
In other words you think everyone who places any kind of limit on
what a C program is is wrong.
>
#include <crapit>
BEGIN
print "This is C"
END
>
Must be C by your definition since crapit might possibly be a
header that makes it C. Or it might be a header that makes it C++
but not C. Or maybe some other language.
Yes, it *could* be a C program, and it's indeed not hard to write that
crapit. It all depends on what in <crapit>, and whether compiler
will accept that crapit.
It was indeed carefully constructed so that given an appropriate
include then you would have C code that compiles in to a C program.
In case of original program using windows.h
you *do* know what windows.h is, and you do know that's a C program.
If you don't know what windows.h was, you can ask.
Others have pointed out that there is more than one header file
called windows.h which are there for different purposes.
Yeah, "others". Of course there are many windows.h files, I can write
about zillion more using my favorite shell. But the windows.h header was
a windows C api header. If you don't know that, just ask ;)
For instance, I knew it was *the* windows windows.h header because the
code was posted by one famous portable-code-writer comp.lang.c regular.
He does tend to get a more extreme reaction that a newbie would because
he knows the scope of the group but flouts it anyway.
True.
>>The ones provided by MS has IIRC things which are not legal C syntax
in them (the way calling conventions etc are specified).
If you mean things like __declspec, they are fine,
implementati on-specific extensions.
I agree that it is a valid way to do an extension, MS are actually quite
good in that respect. However, it violates the syntax of C because C
syntax does not allow adding anything at that point of a declaration.
Just to be clear, using __whatever to add it was doing the right thing.
I am not sure what you mean by this. Standard permits implementation
to use whatever fancy stuff it wants to, __whatever is totally legal
in the system headers. User code didn't contain anything like that,
and it's trivial to write windows.h header which would make the program
work everywhere, like declare the two non-standard functions used.
Program wasn't portable and nobody
said it was, so it's fine (and windows.h is indeed a part of
implementation ). But the program itself used a nice #include
directive, which has well-defined (or rather well-understood and
well-agreed-on) semantics and the rest of code was real C code. A C
program.
Given certain assumptions the C code was valid C code, however from what
I remember it certainly was not a C program solving the problem since it
not only relied on non-C APIs (the Windows API with comments showing a
suggested Unix alternative) but also relied on external programs that in
general are *not* installed on machine.
Oh yeah, the program didn't solve the problem, and didn't solve even
the problem it aimed to solve. We are talking about C/not C here,
not about what the program did. We can discuss the minimal program
including windows.h for that purpose, the program which simply
does nothing but returning 0 from main.
<anip>
>>I made some attempt to provide some kind of scope to what is and is
not C, although it is not perfect. You, on the other hand, just said
that it might be C even if it goes beyond what the standard defined
and gave no outer limit on what could be considered C.
Well, the standard does *not* define what is "C code". I understand
what you mean, you understand what you mean, but it's not what
standard says. Standard doesn't know what it means "N% of C code"
or "two lines of C code".
Well, the C standard does not know about anything that is *not* C code
so it does not have to make the distinction between C code and code that
is not C.
I am not saying it has to do anything. I am saying your notion of
"C code" is as non-standard as what I imagine "C program" is.
In other words: your "C code" has the same value as my "C program"
as far as the standard is concerned, the zero value.
But if you talk humanish, then we can talk about "C code" or
"not C code" and will understand each other well.
>How about "C program is a program consisting of C code" anyway?
A C program consists *only* of C code.
I asked what you think about such a "definition ". Of course
a C program consists only of C code. But C program doesn't
include headers it uses. Take a look at any set of standard
headers, you'll find lots of implementation-specific stuff.
They are secured by the standard, which says "you don't care
what's inside", but it applies as well to other headers provided
by the implementation, such as windows.h. It's *not* really
important what's inside, the important thing is that the header
is provided by implementation to be used in C programs.
And by the way, the syntax errors shown elsewhere prove exactly nothing.
windows.h is not portable, and not meant to be. It's part of
implementation. I can provide you with mingw headers which
actually will work with GCC (what was that compiler, by the way?).
They won't work with other compilers because they are made
for GCC. Then what, program using those headers (string.h for
instance) is not C?
>>With no such limits then this entire post is C because for all you
know it could be an extract from a file that has /* before what is
shown here and closes the comment after. So you have to put some
limit on what you consider to be C code, you don't have to make an
attempt to tell us what it is, but if you don't then don't complain
when others express there opinion that something is not C code.
Yeah yeah, "opinion". Now do go back and read that very post, where
"others" "expressed their opinion". It wasn't "given that I have no
clue what windows.h I can't make a conclusion if it's C or not".
If I remember the post correctly it relied on there being a C compileionr
on the target, where generally there is not, and on the ability to
dynamically load executable (which is only common on hosted systems, but
probably not available on *all* hosted systems). So in this particular
case the bulk of what the program was assuming was actually system
specific (and available as much through any other language in the same
way) rather than being C. It was probably close to "replace { with
begin, } with END; and int main() with PROGRAM FRED;" and you would have
a Pascal program in the same sense that you are calling it a C program.
If hanging 10% changes it to another language, but getting it to run on
a different system means changing 90% then is it really a C solut?
Yes, it is. It's called "not portable". It's called "conforming but
not strictly conforming". You all the time talk about those BEGIN
and END things, to amplify my claim that non-standard things are
still C. But again, what do you think about #include "something. h"? It's
*not* standard C. I am rather saying that if program looks like
C, then it's likely to be C, and if C compilers can compile it, then
it's C. You are saying same thing, but you prefer to talk about lines of
code, or about precents or something.
Either you use standard language, i.e. you stick to calling "C"
only strictly conforming programs, or you invent more human things,
like your "C code" or my "C program". And these human things are
different only as coding styles differ.
No, it
was "fsking no, it's non-standard therefore not C", an emotional
response caused by feelings of one person to another one.
*If* someone was interested in that program he could ask what windows.h
was. If someone wasn't interested in it, he could ignore it. But "not
C because I pretend I have no clue what it is" is nonsense.
Oh well.
Topicality is enforced to keep the experts here and so keep the group
valuable. Jacob gets extreme reactions because of how often he has
flouted topicality pushing either Windows specific code or his own
extensions to C.
It's true, indeed.
<snip>
>>>>>How do you distinguish "C code" from "pseudo-C crap". As far as the
>standard is concerned, once you have any non-standard #include
>in your file, you get "pseudo-C crap".
>
Only if the non-standard header is not provided or is not itself C
code. If the non-standard header has no impact on the rest of the
file then only that one line is "pseudo-C crap", if you don't know
the contents of the header then the entire presented code can
validly be considered as "pseudo-C crap".
You see, here I tightened up the definition up so that my earlier
example given on its own because "not C code".
You miss the important fact here. If you have a non-standard #include
in your C code, it may fail to be processed by a conforming C compiler.
Even if that header is empty, for instance.
In that extreme case, just provide the empty header as well and it can
safely be called C code.
One more time: a program which has non-standard #include directive
is not strictly-conforming, i.e. not a C program according to
what you're saying. It's not a joke, check out comp.std.c for instance.
Even if your header is empty, the program isn't strictly conforming.
And it's not C? No way! It is C, I know that, you know that.
You have an escape here of course, you can say that all the lines
but the #include ones are "C code". I prefer not to employ such
tricks, I just honestly say that it's still a C program even if
not strictly conforming.
>
You are saying that it's
C code because reasonable compiler will indeed process it; or because
you can expand #include manually; or for whatever else reason. But the
standard doesn't agree. I, from the other hand, claim that it's totally
fine to say it's a C program (or C code if you prefer), even though
it's not standard.
As far as I can see the standard only considers it to be C if it can be
compiled, so if it includes a header that does not exist then it is just
plain broken.
If you say "this header defines the prototypes for these non-standard
functions" then we can consider everything apart from those non-standard
functions as C.
I do not see a need to say that even an entire file is C or not C, this
is why I emphasise that it is the code that is C or not C since then you
can graduate it as finely as you need.
This is the part why we disagree, I think. You don't need to say if
some file is C or not. I do, I prefer to call C programs C programs,
not "something which includes some amount of C code" (I prefer to use
the latter for those programs which use GCC extensions, assembly,
C++, other stuff like that).
>>>> Once you have one file in
>your program which uses a non-standard feature (even if the other
>thousand files are perfect standard C), then the program is "pseudo-C
>crap". So the question stands. You like to write pseudo-C crap,
>it's fine; I still believe there are lot of C programmers writing
>C programs, which are C programs even if they use POSIX api, windows
>api, foobar api, etc.
>
Personall y since I started writing C hardly any programs I have
written have been C programs (or do yo consider " LAC *+,AR0" to
be C?)
It can't be made C even using preprocessor tricks, so it's not C at
all.
I guess.
The point was there is a program where 90% or more is completely
standard C. Then there are a few linker tricks to get some variables
which are only ever declared as "extern" in the C mapped on to some
hardware (so the C code is not having to do tricks like converting
integers to pointers to access memory mapped devices). Then there are
one or two assembler files making up under 10% of the code. So 90% is
C but a small fraction is not, and the status of the 90% as being C
code is far more important than the status of the program as a whole.
I can't disagree here. Anyway, do you count #include <cheader.has
C code? As well as #include "cheader.h" (sure, provided the complete
listing of cheader.h is available, the standard doesn't say it will
help).
Given a reason to suppose that the C compiler will succeed (headers need
not actually be files) then yes, I would consider it to be a line of C
code.
Well, it's a line which makes the program to be not strictly conforming.
Absolutely fine for me, I accept even more non-standard stuff in C
programs ;)
>>>>but I have written a lot of C code that has been incorporated with
other stuff to produce programs.
>
>Somehow almost all programs on my computer are written in C. You
>may say they are written in "Pseudo-Unix pseudo-C crap", it's your
>choice. But it's not a sensible choice.
>
A lot of programs are written mostly in C, but if the program as a
whole is not written in C then calling it a C program is
misleadin g, although saying it is mostly written in C is not.
>
If I write a program with 25% assembler, 25% C, 25% Java and 25%
Fortran, what language is the program written in? My answer is "a
mixture".
Yes, it's a mixture. But I wasn't talking about such cases. I was
talking about programs which have 100% C code. Using non-standard
features like "libraries" though.
Those libraries are written in something. If they are written in C
then expand your scope to include them and you have a C program (I
use XML libraries which are at least mostly written in C for example).
"Expand scope", huh? If you include their source files, it's standard.
Yes, because then it is just a number of additional C translation units.
>If you use linker, it becomes non-standard,
The linker has nothing to do with it. After all, when combining multiple
translation unites (which is allowed by C) you are linking!
Yep. Now tell you are compiling xml library sources with your program.
I doubt that, you most likely use the library, use a linker to get
symbols from it in a non-standard way. And as long as there are #include
directives, it's all not strictly conforming. Funny, isn't it?
*You* are saying your program is not C, I think it is C (as long as
you don't have C++ or something inside).
>
i.e. just as standard-C
as embedded assembly.
<sighNo, because everything is standard C! It matters not to me
whether I have written the XML library in C or whether someone else has.
If the library is in C and my code using it is in C then everything is
in C.
Standard doesn't say this. It says that C files are C. If you process
those C files to get libxml.so and later use this libxml.so, you get
out of scope of the standard. *I understand* what you mean here,
but as far as the standard is concerned, what you are doing is no
more standard as embedded assembly (i.e. not standard).
(I presume you are using the library here)
However, if the library is in assembler (or I do not know it is C)
then what I have is C+XML-library rather than just C. If the XML library
is written in assembler then you can call it either C+XML-library or
C+assembler, your choice, if you do not know what the XML-library is
written in then all you can do is call it C+XML-library.
But the result is the same, the point is the same:
you have a C program (program consisting of C code if you prefer), you
use C headers.
No, if the libraries I am reliant on are C (i.e. part of what is defined
by the standard as C or written in C, with this applied recursively)
then the program as a whole is C.
See, you are no less creative than me in getting over the standard
to call something C ;)
If somewhere along the line you reach
something that is not C (i.e. not written in C or not part of the
standard C library) then the program as a whole is C+whatever-is-not-C
even though the headers describing the interface to the not-C may
themselves be C.
>>However, if either those extras are not C *or* you are not including
them in what you are presenting, then what you are presenting is no
longer C but C+whatever or Windows-C or POSIX-C.
Note that a header that is not part of standard C and is not provided
as part of what is presented could easily contain things which
convert your program from being valid C to being valid
some-other-language. C is not the only language to use #include! I
would assume it was C+something but I could not be completely
convinced, because I do know that there are files called windows.h
which are nothing to do with MS Windows.
Well, I just made an (completely reasonable) assumption that the
windows.h thing was indeed *that* windows.h thing. You can have
reasonable doubt in it, since it may or may not have been that
windows.h. But can you just claim "not C" because I/he didn't tell
what windows.h was? Can you tell that "beep beep not C" is just
as reasonable as my "I believe it's C program which uses windows
api"?
So you call it "C+Windows API" and I call it "Windows-C" (yes, I know
I've paraphrased you). That does not actually look like quite so far
apart. It is more that I and some others (particularly when dealing with
certain people who show repeated disregard for topicality)
Well, it was indeed a stupid idea to "defend" Jacob Navia. But it's
not only him who gets these stupid "not C period". And usually some
people find ways to put him down without resorting to such senseless
things like "beep beep not C".
put more
emphasis on the "+Windows API", and even more so when almost every line
is either using the Windows API or setting things up to use the Windows
API.
"+Windows API" is totally good, if it means "a C code which uses windows
api". And it's not about windows, by the way. I don't care much about
this crap. What I do care about is bunch of utilities in my /bin folder,
almost all of which are written in C. Even if none of them is written
in standard C (and mind you, without any assembly or something, single
#include <config.hmake s them non-standard).
Yevgen
Mark McIntyre wrote:
On Fri, 23 Feb 2007 21:22:14 GMT, in comp.lang.c , Yevgen Muntyan
<mu************ ****@tamu.eduwr ote:
>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? You did
say there are many windows.h headers, and I am still claiming you
knew very well that windows.h in JN's code was the windows api
header. I can't prove it of course, and you can tell I am wrong,
sure.
>If you don't know what windows.h was, you can ask.
see below !
>I was talking about programs which have 100% C code. Using non-standard
features like "libraries" though.
unless the header for the library is entirely valid C, the programme
isn't strictly a C programme any more. The difficulty is that many
libraries of the type of win32, posix, curses etc do rely on
nonstandard and often downright inadmissible functionality.
Come on, standard headers use same non-standard stuff. They are
protected by the standard which says "you don't care what's inside
the string.h", but nevertheless implementation is also free to
use any non-standard stuff in its own headers. windows.h is part
of particular implementation.
Take a look at glibc headers. string.h and regex.h are no different
in what's inside. Same load of __foobar and __attribute__. So a
program using <regex.hisn't C, right?
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? C and C++ compilers are famous
by very sane error messages which follow the first, real one.
and even this gem:
cguid.h(54) : warning C4179: '//*' : parsed as '/' and '/*'
cguid.h(124) : fatal error C1071: unexpected end of file found in
comment
which is schoolboy error of hilarious proportions.
Sure, MS makes schoolboy errors. Man, 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).
I did *not* say the program was strictly conforming. It surely
was not portable. You illustrate its non-portability by trying
to compile something which isn't intended to be compiled in
the way you did it. But why? It's non-portable from the start,
simply because it uses non-standard header.
Let's look at another thing, here on my linux:
muntyan@munt10:/tmp$ cat file.c
#include <windows.h>
int main(void)
{
return 0;
}
muntyan@munt10:/tmp$ gcc -I/usr/i586-mingw32msvc/include/ file.c
muntyan@munt10:/tmp$ icc -X -I/usr/i586-mingw32msvc/include/
-I/usr/lib/gcc/i586-mingw32msvc/3.4.5/include/ file.c
muntyan@munt10:/tmp$
See, it does compile. Mingw has nice headers and Microsoft has
shitty headers which work only with their compiler? Perhaps. So what?
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*. Note I am
not claiming it's a portable program because I can compile
it or something; I am not using your "oops I made it not compile"
trick, just demonstrating that your demonstration was nothing.
Any not strictly conforming program can fail to compile with
some compiler (just by definition), and you showed it. So?
Yevgen
In article <k27Eh.505$Tg7. 397@trnddc03>,
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? You did
say there are many windows.h headers, and I am still claiming you
knew very well that windows.h in JN's code was the windows api
header. I can't prove it of course, and you can tell I am wrong,
sure.
You do realize, don't you, that you are arguing with idiots?
These are people who will never admit that the emperor has no clothes.
No matter how much common sense you throw at them.
Yevgen Muntyan wrote, On 24/02/07 21:47:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 24/02/07 11:21:
<snip>
>>How about "C program is a program consisting of C code" anyway?
A C program consists *only* of C code.
I asked what you think about such a "definition ".
Perhaps I should have been clearer. What I think of your suggestion was
that it should be amended to what I provided o be clearer.
<snip>
>If you say "this header defines the prototypes for these non-standard
functions" then we can consider everything apart from those
non-standard functions as C.
I do not see a need to say that even an entire file is C or not C,
this is why I emphasise that it is the code that is C or not C since
then you can graduate it as finely as you need.
This is the part why we disagree, I think. You don't need to say if
some file is C or not. I do, I prefer to call C programs C programs,
not "something which includes some amount of C code" (I prefer to use
the latter for those programs which use GCC extensions, assembly,
C++, other stuff like that).
I agree that this is probably the heart of our disagreement, so I've
snipped a lot of other parts where we still disagree.
My position is probably coloured by me experience. I have often been in
the position where I an effectively writing code to extend the
implementation and writing programs to make use of the code I wrote to
extend the implementations . Therefore, I am writing those headers (which
in my case generally are standard C) and the whatever-is-not-C as well,
or sometimes just porting a not-C library to some other system because I
need it to make my code work there. It is possibly because of this that
I consider calling MyFancyApi() you are leaving the realms of C since I
would actually write MyFancyApi() in assembler or whatever.
<snip>
>>I can't disagree here. Anyway, do you count #include <cheader.has
C code? As well as #include "cheader.h" (sure, provided the complete
listing of cheader.h is available, the standard doesn't say it will
help).
Given a reason to suppose that the C compiler will succeed (headers
need not actually be files) then yes, I would consider it to be a line
of C code.
Well, it's a line which makes the program to be not strictly conforming.
Absolutely fine for me, I accept even more non-standard stuff in C
programs ;)
I never said strictly conforming :-)
Note that I consider it to still be C code when it depends on
implementation defined behaviour for its output and that makes it no
longer strictly conforming. Even more, I would call "i = ++i;" incorrect
C rather than not C.
<snip>
>>>>>If I write a program with 25% assembler, 25% C, 25% Java and 25%
>Fortran, what language is the program written in? My answer is "a
>mixture" .
>
Yes, it's a mixture. But I wasn't talking about such cases. I was
talking about programs which have 100% C code. Using non-standard
features like "libraries" though.
Those libraries are written in something. If they are written in C
then expand your scope to include them and you have a C program (I
use XML libraries which are at least mostly written in C for example).
"Expand scope", huh? If you include their source files, it's standard.
Yes, because then it is just a number of additional C translation units.
>>If you use linker, it becomes non-standard,
The linker has nothing to do with it. After all, when combining
multiple translation unites (which is allowed by C) you are linking!
Yep. Now tell you are compiling xml library sources with your program.
It depends. On some systems the versions I want are available, so I
don't compile them, on some systems they are either not available at the
version I want ot not available, so I do compile them. When I compile
them I also get the support department where I work to ship them to the
customers and install them!
I doubt that, you most likely use the library, use a linker to get
symbols from it in a non-standard way. And as long as there are #include
directives, it's all not strictly conforming. Funny, isn't it?
*You* are saying your program is not C, I think it is C (as long as
you don't have C++ or something inside).
Since I am using a library (which I compiled) written in standard C and
the rest of the applciation is standard C if you include the source code
for the library (which I did not write but did compile) then it is
strictly conforming. If, however, I sent it to someone without the
source for the library they could correctly say it is not strictly
conforming since it depends on things outside the C language which are
not part of what I provide.
By the way, I would say that most of my programs are not C but
C+whatever because they in general do depend on things beyond C since
they need to do things you cannot do with only C. I'm just ignoring
those parts of the programs for this discussion. :-)
> i.e. just as standard-C
as embedded assembly.
<sighNo, because everything is standard C! It matters not to me
whether I have written the XML library in C or whether someone else
has. If the library is in C and my code using it is in C then
everything is in C.
Standard doesn't say this. It says that C files are C. If you process
those C files to get libxml.so and later use this libxml.so, you get
out of scope of the standard.
No, if I do that and then post the code here *including* the C code used
to create libxml, then everyone will be happy that it is C (assuming no
other problems).
If, on the other hand, I only provide the code that *uses* libxml and
say, oh, that is just the standard XML functions provided by the
library) then I am not posting C but C+XML-library
*I understand* what you mean here,
but as far as the standard is concerned, what you are doing is no
more standard as embedded assembly (i.e. not standard).
(I presume you are using the library here)
No, it is very different from embedded assembly. If it is embedded
assembly then even if I post everything it is still C+embedded-assembly,
where as if I post the code to the XML library as well as the code using
it then it is once again standard C.
<snip>
> But the result is the same, the point is the same:
you have a C program (program consisting of C code if you prefer), you
use C headers.
No, if the libraries I am reliant on are C (i.e. part of what is
defined by the standard as C or written in C, with this applied
recursively) then the program as a whole is C.
See, you are no less creative than me in getting over the standard
to call something C ;)
The difference is I am actually putting some kind of limits on what is
C. With your definition you could call a program written in C++ using
the STL a C program because it is just C+extensions. So are you going to
suggest a definition that will make what is definitely C++ something
other than C or not? If not, then as far as I can see your suggestion is
of no use. I may be being creative beyond what the standard says, but at
least I have made some attempt to provide something that excludes C++
from being C and can be of some use.
<snip>
>put more emphasis on the "+Windows API", and even more so when almost
every line is either using the Windows API or setting things up to use
the Windows API.
"+Windows API" is totally good, if it means "a C code which uses windows
api". And it's not about windows, by the way. I don't care much about
this crap. What I do care about is bunch of utilities in my /bin folder,
almost all of which are written in C. Even if none of them is written
in standard C (and mind you, without any assembly or something, single
#include <config.hmake s them non-standard).
If you don't mind "+Windows API" or "+POSIX" etc then here we reach a
sensible compromise. I'm not bothered precisely how people interpret the
+whatever (is it the call to the API, or is it when the program actually
starts executing code within the API that it crosses the border, or
whatever), as long as they accept that it is not *just* C but C+whatever.
Of course, others on the group might not accept it ;-)
As I also said, you have not actually said where you draw the line, and
it is a line that needs to be drawn somewhere. Otherwise you can call
all C++ code C because it *is* just C+extensions, since that is the way
C++ was developed!
--
Flash Gordon
Flash Gordon wrote:
Yevgen Muntyan wrote, On 24/02/07 21:47:
>Flash Gordon wrote:
<snip>
>>put more emphasis on the "+Windows API", and even more so when almost
every line is either using the Windows API or setting things up to
use the Windows API.
"+Windows API" is totally good, if it means "a C code which uses windows
api". And it's not about windows, by the way. I don't care much about
this crap. What I do care about is bunch of utilities in my /bin folder,
almost all of which are written in C. Even if none of them is written
in standard C (and mind you, without any assembly or something, single
#include <config.hmake s them non-standard).
If you don't mind "+Windows API" or "+POSIX" etc then here we reach a
sensible compromise. I'm not bothered precisely how people interpret the
+whatever (is it the call to the API, or is it when the program actually
starts executing code within the API that it crosses the border, or
whatever), as long as they accept that it is not *just* C but C+whatever.
Of course, others on the group might not accept it ;-)
As I also said, you have not actually said where you draw the line, and
it is a line that needs to be drawn somewhere. Otherwise you can call
all C++ code C because it *is* just C+extensions, since that is the way
C++ was developed!
Quoting myself:
-----
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).
-----
C++ code like std::foo(bar) or foo<barisn't C. You may think I think
it is C, but I did say it's not. I *can't* say where I draw that line,
simply because it's too hard, hard to formulate it in clear English
(hard even in native language). My original claim was (and still is,
what we arguing about is rather not-so-important details): set of C
programs is strictly greater than the set of strictly conforming C
programs. I dislike that you are not calling most C programs "C
programs", but your terminology is still quite sensible, because it
actually carries the information about what is from what and from where.
And you do accept the idea of "not every line of C code is a line of
strictly conforming program", so we're in fact in agreement.
Yevgen
My read of Chapter 4 is that a program that does not implement any
undefined behavior is "correct" (and shall act in accordance with
section 5.1.2.3, Program Execution.)
I don't believe the the standard makes any statements concerning "just
C" or "C plus extensions", or "is C" or "is not C". You're even going
to be hard pressed to find the words "standard C" in the standard.
But never mind all that. The definitions of "correct" and "strictly
conforming" should cover all cases, right?
The degree to which you guys are willing to discuss non-conforming
code on clc, well, that's a different matter. :-)
-Beej
Beej wrote:
My read of Chapter 4 is that a program that does not implement any
undefined behavior is "correct" (and shall act in accordance with
section 5.1.2.3, Program Execution.)
I don't believe the the standard makes any statements concerning "just
C" or "C plus extensions", or "is C" or "is not C". You're even going
to be hard pressed to find the words "standard C" in the standard.
Of course.
But never mind all that. The definitions of "correct" and "strictly
conforming" should cover all cases, right?
It doesn't cover the following thing (not "program", it's what we
are 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 degree to which you guys are willing to discuss non-conforming
code on clc, well, that's a different matter. :-)
Nobody is discussing non-conforming code. We are discussing what
*conforming* code may be called "C". The following is conforming:
#include <windows.h>
int main (void)
{
return 0;
}
Yevgen
On Feb 25, 2:18 am, Yevgen Muntyan <muntyan.remove t...@tamu.edu>
wrote:
Nobody is discussing non-conforming code. We are discussing what
*conforming* code may be called "C".
Ah. My mistake. Carry on. :)
-Beej
Yevgen Muntyan wrote, On 25/02/07 08:22:
<snip>
C++ code like std::foo(bar) or foo<barisn't C. You may think I think
it is C, but I did say it's not. I *can't* say where I draw that line,
simply because it's too hard, hard to formulate it in clear English
(hard even in native language).
Yes, I have a rather large advantage over you their. For someone who is
not a native English speaker you do very well.
My original claim was (and still is,
what we arguing about is rather not-so-important details): set of C
programs is strictly greater than the set of strictly conforming C
programs. I dislike that you are not calling most C programs "C
programs", but your terminology is still quite sensible, because it
actually carries the information about what is from what and from where.
And you do accept the idea of "not every line of C code is a line of
strictly conforming program", so we're in fact in agreement.
OK, I think we can agree to disagree on where the line is drawn. As you
say this is not the most important thing.
--
Flash Gordon This thread has been closed and replies have been disabled. Please start a new discussion. |
