Re: Automatically generate variables
- From: Yevgen Muntyan <muntyan.removethis@xxxxxxxx>
- Date: Fri, 23 Feb 2007 21:22:14 GMT
Flash Gordon wrote:
Yevgen Muntyan wrote, On 23/02/07 13:33:Richard Bos wrote:Yevgen Muntyan <muntyan.removethis@xxxxxxxx> wrote:
Richard Bos wrote:You're the one using non-Standard extensions and claiming they'reTry reading the thread, you'll find some discussion of this, what
perfectly good C. I suggest that _you_ come up with your definition of
what is and is not a C program. Be careful, now: some definitions are
trickier than they first seem. For example, simply replying "any
conforming program" would have some unforeseen consequences...
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. 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.
> And it's thereason why *on-topic* here are only strictly conforming programs.
But there is more to C than programs using only standard features.
Actually, a highly system specific program could be topical within certain limits depending on what the question being asked along with the program is. For example, if the question was "how much of the program is standard C?" then it could be considered an entirely topical post even if the only thing standard was the declaration of main. It could even lead to interesting discussions about why certain things were not covered by the standard.
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).
No, it is a POSIX-C program or a Windows-C program or whatever. If well written a large percentage of the code may well be C code, but that does not make it as a hole a C program whether it uses __asm() to introduce some assembler code, or calls a function written by the author in assembler, or calls a function written by MS or the GNU team in something other than C. You could call it a "mostly C program" if you prefer.
Personally I tend to talk about C code rather than C programs. There is a lit more C code around than C programs, and it could even be that you have a 10000 line file with 5 lines of C code in it!
So you prefer to use "C code" for C code, and call only strictly
conforming programs "C programs"? Completely fine for me, but note
that it's just as non-standard as my version. And just as vague.
It's as vague because for instance your above example with crapit
again could be C code, if you insert appropriate defines. From the
other hand, any C code may be screwed up using macro definitions.
And we get back to the fact that it's possible to say for sure
if something is standard C or not only for complete program.
Once you start saying
int a = 2;
or
int func (void)
{
return 0;
}
is C code, you get away from the safe route (standardise) and get to
area of "it looks and breathes like C", the stuff I am talking about.
In other words, you are saying my "definition" (which I don't really
have) is no good, and you just use another one, which is just as
non-strict as mine. Then you can ignore the question about what
"C programs" are since you can think about "C code" instead :)
-----------------------------------------------------
A long quote, but it was hard enough to write that, and I didn't
try to edit/compress it.
It does not address what you think is and is not C, it only says you don't agree with C code being only code which is specified (possibly as being implementation defined) by the C standard.
I didn't discuss "C code" term at all. I can tell that it seems
we have same ideas about what is C code and what isn't though.
Anyway, could you please confirm that the program was not C?
Of course it wasn't.
And could you tell (I am just curious) what you'd call it?
That one? Pseudo-Windows pseudo-C compatible-with-nothing crap.
Just what you think when you see such a piece of code, i.e.
99% of "C" code you see
I see a good deal of utter tripe, but 99% the same kind of tripe as that
chimaera posted upthread would be rather an exaggeration.
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".
> Once you have one file inyour 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.
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.
Yevgen
.
- Follow-Ups:
- Re: Automatically generate variables
- From: Mark McIntyre
- Re: Automatically generate variables
- From: Flash Gordon
- Re: Automatically generate variables
- References:
- Automatically generate variables
- From: Nate
- Re: Automatically generate variables
- From: Mark McIntyre
- Re: Automatically generate variables
- From: jacob navia
- Re: Automatically generate variables
- From: Mark McIntyre
- Re: Automatically generate variables
- From: Yevgen Muntyan
- Re: Automatically generate variables
- From: santosh
- Re: Automatically generate variables
- From: Yevgen Muntyan
- Re: Automatically generate variables
- From: santosh
- Re: Automatically generate variables
- From: Ian Collins
- Re: Automatically generate variables
- From: Mark McIntyre
- Re: Automatically generate variables
- From: Yevgen Muntyan
- Re: Automatically generate variables
- From: CBFalconer
- Re: Automatically generate variables
- From: Yevgen Muntyan
- Re: Automatically generate variables
- From: Richard Bos
- Re: Automatically generate variables
- From: Yevgen Muntyan
- Re: Automatically generate variables
- From: Richard Bos
- Re: Automatically generate variables
- From: Yevgen Muntyan
- Re: Automatically generate variables
- From: Flash Gordon
- Automatically generate variables
- Prev by Date: Re: Automatically generate variables
- Next by Date: Re: why learn C?
- Previous by thread: Re: Automatically generate variables
- Next by thread: Re: Automatically generate variables
- Index(es):
Relevant Pages
|
Loading