Automatically generate variables

[jacob navia]

Yevgen Muntyan a écrit :

I'm afraid I can't understand this.



And? Is this program C or not? If not, what is it (just curious
what ridiculous things people can invent instead of using standard
"strictly conforming" term). And please don't tell "this is not standard
C", I didn't say that. I am saying "it is a C program".

Yevgen

Look. The criteria is simple. If I wrote it, it
it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE
and all the other nonsense. Besides, windows is considered harmful
here...

It is hopeless.

 

[Richard Heathfield]

jacob navia said:

Look. The criteria is simple. If I wrote it, it
it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE
and all the other nonsense.

No. Whilst the criterion is indeed simple, that isn't it. The criterion
is simply that, if the code makes use of non-standard extensions, it's
off-topic here.

Besides, windows is considered harmful here...

By some, yes, but that's irrelevant. What *is* relevant is that Windows
is considered off-topic here.

It is hopeless.

It depends what you want. If you want a newsgroup where Windows
programming is topical, hope can be found at
comp.os.ms-windows.programmer.win32 - and if you want a newsgroup where
what you call "Navia C" is topical, it is likely - or at least possible
- that comp.compilers.lcc will prove hopeful for you. But if you want a
newsgroup where the C programming language, unfettered by extensions,
is discussed, then comp.lang.c is that newsgroup.

 

[Keith Thompson]

No it isn't. If it had #include "windows.h" it would be. There is
no such header in standard C, but the user is allowed to create all
the headers he wishes elsewhere. All he has to do is provide them.

It is a "conforming program", as defined in C99 4p7, as long as
there's some conforming C implementation that accepts it.

 

[Keith Thompson]

Look. The criteria is simple. If I wrote it, it
it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE
and all the other nonsense. Besides, windows is considered harmful
here...

It is hopeless.

It is hopeless as long as you have that attitude.

I've been reading your postings here for a long time. Trust me on
this: sarcasm doesn't work for you. It's not possible to have a
constructive discussion with you if you insist on parodying what you
think are other people's opinions. It simply guarantees that you will
not be taken seriously.

On the other hand, if you write what *you* believe, and perhaps even
back it up with evidence, the worst that can happen is that people
will disagree with you. It's even possible that somebody might learn
something.

I've told you this before, and I'm not optimistic that it will get
through this time.

 

[CBFalconer]

Chapter & Verse, please ;-)

From N869:

6.10.2 Source file inclusion

Constraints

[#1] A #include directive shall identify a header or source
file that can be processed by the implementation.

Semantics

[#2] A preprocessing directive of the form

# include <h-char-sequence> new-line

searches a sequence of implementation-defined places for a
header identified uniquely by the specified sequence between
the < and > delimiters, and causes the replacement of that
directive by the entire contents of the header. How the
places are specified or the header identified is
implementation-defined.

Note that no such actual file need exist, and that the response to
the #include <filename> may be entirely contained within the
compiler.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Mark McIntyre]

CBFalconer wrote:

I'm afraid I can't understand this.

What CBF was trying to say is the <> and "" forms of #include
potentially search different places. By convention. the <> form
searches your system header paths, while "" searches
application-specific paths. However this has nothing to do with
whether a header is ISO standard or not, so the point isn't relevant.

And? Is this program C or not? If not, what is it (just curious
what ridiculous things people can invent instead of using standard
"strictly conforming" term). And please don't tell "this is not standard
C", I didn't say that. I am saying "it is a C program".

It is _potentially_ a C programme. However since we have no idea at
all what is in "windows.h", we can't tell what nonstandard and
nonportable atrocities might be therein. Any one of these could render
the code no longer C.

The point CBF was making here is that had the user supplied the
contents of windows.h, we oculd have been certain whether it was C or
not. As it is, it could be packed with assembler, platform-specific
memory access which violates C standards, etc etc etc.
--
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]

Look. The criteria is simple. If I wrote it, it
it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE

Don't be such an idiot. The criterion is simple - if it contains
platform-specific stuff its offtopic here, irrespective of who wrote
it. If it contains nonstandard constructs, grammar etc then its not C.
Again irrespective of who wrote it.

and all the other nonsense. Besides, windows is considered harmful
here...

Bullshit. Now you're displaying your own prejudices.

It is hopeless.

I agree. You are determined to martyr yourself on a nonexistent altar,
no point trying to stop you I think.
--
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

 

[Yevgen Muntyan]

What CBF was trying to say is the <> and "" forms of #include
potentially search different places. By convention. the <> form
searches your system header paths, while "" searches
application-specific paths. However this has nothing to do with
whether a header is ISO standard or not, so the point isn't relevant.

Now I got it, I didn't notice <> vs "". Well, that's a wrong statement.
C standard says as much about #include "windows.h" as about
#include <windows.h>. Namely, using either form makes your program
not strictly conforming. And if you talk real compilers, you can
make the compiler pick your header instead of system one
when you use #include <windows.h>, and vice versa. In any case,
it's out of standard business. So are we talking about common
sense here or about what?

It is _potentially_ a C programme. However since we have no idea at

Yes you do. That's the point. You know pretty well the program was
a C program but you wanted to tell couple nice words to Jacob Navia,
so you did "beep beep not C". Bullshit.

all what is in "windows.h", we can't tell what nonstandard and
nonportable atrocities might be therein. Any one of these could render
the code no longer C.

Yes it could, sure.

The point CBF was making here is that had the user supplied the
contents of windows.h, we oculd have been certain whether it was C or
not. As it is, it could be packed with assembler, platform-specific
memory access which violates C standards, etc etc etc.

Well, the point was hidden pretty well. This is obvious, the
non-standard header may do what it wants to. So why do you
say *not C* if you do *not* know that? I simply assume that
header is indeed the famous windows.h thing, windows C api,
for C programs. You?

Yevgen

 

[Richard Heathfield]

Mark McIntyre said:

You are determined to martyr yourself on a nonexistent altar

An altar could be arranged.

 

[Keith Thompson]

No it isn't. If it had #include "windows.h" it would be. There is
no such header in standard C, but the user is allowed to create all
the headers he wishes elsewhere. All he has to do is provide them.

There's a difference between "not a C program" and "off-topic in
comp.lang.c". The above is a C program, though not a portable one,
and saying it isn't just muddies the waters. The program is merely
off-topic in comp.lang.c.

 

[boa]

Chapter & Verse, please ;-)

From N869:

6.10.2 Source file inclusion

Constraints

[#1] A #include directive shall identify a header or source
file that can be processed by the implementation.

Semantics

[#2] A preprocessing directive of the form

# include <h-char-sequence> new-line

searches a sequence of implementation-defined places for a
header identified uniquely by the specified sequence between
the < and > delimiters, and causes the replacement of that
directive by the entire contents of the header. How the
places are specified or the header identified is
implementation-defined.

Note that no such actual file need exist, and that the response to
the #include <filename> may be entirely contained within the
compiler.

My impression was that you describe programs with non-standard header
files within <> as "not C". The standard is silent on this issue,
AFAICT. So

#include <windows.h>
int main(void) { return 0;}

is a valid C program, just as this snippet is.

#include "stdio.h"
int main(void) {return 0;}

Source file inclusion is all implementation-defined, according to C99
§6.10.2. Even "STDIO.H" and "sTdIo.H" seems to be perfectly fine file
names too, according to 6.10.2#5 <shudder>

Boa

 

[Kenny McCormack]

There's a difference between "not a C program" and "off-topic in
comp.lang.c". The above is a C program, though not a portable one,
and saying it isn't just muddies the waters.
Indeed.

The program is merely off-topic in comp.lang.c.

How very reasonable of you to say so. Unfortunately, some of your fellow
twits-in-arms say otherwise (and have done so repeatedly time and again
in this ng).

 

[Richard Bos]

And? Is this program C or not? If not, what is it (just curious
what ridiculous things people can invent instead of using standard
"strictly conforming" term). And please don't tell "this is not standard
C", I didn't say that. I am saying "it is a C program".

You're the one using non-Standard extensions and claiming they're
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...

Richard

 

[Yevgen Muntyan]

You're the one using non-Standard extensions and claiming they're
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...

Try reading the thread, you'll find some discussion of this, what
you're saying and more. Anyway, could you please confirm that
the program was not C? And could you tell (I am just curious) what
you'd call it? No, I am not asking you to invent definitions or
something, just wondering what you call that, "C-like", "a piece
of text resembling a C program", "a piece of text which looks
like java to me"... Just what you think when you see such a piece
of code, i.e. 99% of "C" code you see (quotes used because you
might say it's not C and so on).

Yevgen

 

[Andrew Poelstra]

Try reading the thread, you'll find some discussion of this, what
you're saying and more. Anyway, could you please confirm that
the program was not C? And could you tell (I am just curious) what
you'd call it? No, I am not asking you to invent definitions or
something, just wondering what you call that, "C-like", "a piece
of text resembling a C program", "a piece of text which looks
like java to me"... Just what you think when you see such a piece
of code, i.e. 99% of "C" code you see (quotes used because you
might say it's not C and so on).

It isn't C because you used WCHAR without defining it, and so it was a
syntax error.

 

[Chris Dollin]

It isn't C because you used WCHAR without defining it, and so it was a
syntax error.

I think it's at least plausible that some fragment of text "is C"
if there is standard C header and footer text that can surround it
and make it legal & grammatical (and non-trivial [1]).

Otherwise if I said "consider the fragment `int i = i + 1;`" I could
be dismissed because that fragment wasn't C.

[1] Otherwise the header "/*" and footer "*/" would ruin (most) things.

 

[Yevgen Muntyan]

It isn't C because you used WCHAR without defining it, and so it was a
syntax error.

There was no WCHAR even in the original JN's program, nor in my
purified version

#include <windows.h>
int main (void)
{
return 0;
}

Yevgen

 

[Mark McIntyre]

Yes you do. That's the point.

No, you don't. That is indeed the point. If stdlib.h were included,
you would know it was a C programme, since stdlib.h is a standard
header. if foobar.h is included, you have no idea at all unless you
have the contents of foobar.h

You know pretty well the program was
a C program but you wanted to tell couple nice words to Jacob Navia,

You think I have a vendetta against Jacob. You're wrong. I do have an
objection to people posting gratuitously offtopic stuff here tho.
Windows-specific code is offtopic.

so you did "beep beep not C". Bullshit.
Horsefeathers.


Well, the point was hidden pretty well.

Possibly. See my sig.

say *not C* if you do *not* know that? I simply assume that

We know what "assume" makes out of you and me.

header is indeed the famous windows.h thing, windows C api,
for C programs. You?

I have several headers called Windows.h, two of which deal with the
win32API, but for different compilers and with slightly different
contents. Both of them give rise to compilation errors during
compilation in ISO C mode. A third is for PalmOS as far as I remember
(I haven't used it in a while). A few years ago, I worked for a
company that gathered together all their GUI control declarations into
a file called - you guess.

--
Mark McIntyre

"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield

 

[Richard Bos]

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.

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.

Richard

 

[Yevgen Muntyan]

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
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).
-----------------------------------------------------

A long quote, but it was hard enough to write that, and I didn't
try to edit/compress it.

Of course it wasn't.


That one? Pseudo-Windows pseudo-C compatible-with-nothing crap.


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". 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.

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.

Yevgen