Flash said:
Yevgen Muntyan wrote, On 24/02/07 11:21:
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.
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.
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.
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.
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?
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.
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.
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.
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).
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
Yes, because then it is just a number of additional C translation units.
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).
<sigh> No, 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.
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.
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.h> makes them non-standard).
Yevgen
