problem with macros

[s0suk3]

Right. It's the domain of other standards, not of a programming
language standard.

Java supports networking, Python supports networking, Perl supports
networking, Ruby supports networking, C# supports networking, many
others support networking.

Right. It's the domain of other standards (and less formal quasi-
standards), not of a programming language standard.

Java supports graphics, Python supports graphics, others probably
support graphics.

You're repeating yourself.

GUIs are not the same as graphics, if that's what you meant. Anyway,
Java supports GUIs, Python supports GUIs, others probably support
GUIs.

Right. It's the domain of other standards, not of a programming
language standard.

Java supports directory operations, Python supports directory
operations, Perl supports directory operations, C# supports directory
operations, Ruby supports directory operations, many others support
directory operations.

<snip>

So, you see, many people (perhaps most people) do think those things
should be part of a programming language's standard (I mean "standard"
in a general sense, not necessarily a document like C's standard), and
some of them have worked hard on them. They're just not what you think
should be "a programming language standard."

Sebastian

 

[jacob navia]

[...]
You're repeating yourself from many earlier threads. You've
told us more than once that C is a dead language,

You are lying, as always

Then I've been misled by my own memory -- and by that of Google,
which quotes you as writing:

"There isn't a single interesting software written in ISO C."

Sure I said that. And I go on saying that.

You haven't got any example of any important software in ISO C.

"All people with an interest in language development, software
development are gone."

I was speaking about THIS GROUP you liar. Not about C. But you
take quotes without context and there you go!

"C++ is the way, C is dead, go away."

I was saying that the attitudes of the regulars leads to that
You took out the quote of its context, as the other one
above. That is why you do not put the URLs to those
quotes.

"Why KEEP this OLD interfaces that have proven wrong over
decades? strncpy, gets, asctime, trigraphs, all that CRUFT?"

Yes, Why keep them?

[snip rest of misquotes]

 

[jacob navia]

Java supports networking, Python supports networking, Perl supports
networking, Ruby supports networking, C# supports networking, many
others support networking.


Java supports graphics, Python supports graphics, others probably
support graphics.


GUIs are not the same as graphics, if that's what you meant. Anyway,
Java supports GUIs, Python supports GUIs, others probably support
GUIs.


Java supports directory operations, Python supports directory
operations, Perl supports directory operations, C# supports directory
operations, Ruby supports directory operations, many others support
directory operations.

<snip>

So, you see, many people (perhaps most people) do think those things
should be part of a programming language's standard (I mean "standard"
in a general sense, not necessarily a document like C's standard), and
some of them have worked hard on them. They're just not what you think
should be "a programming language standard."

Sebastian

Exactly. And those things ARE supported in C. Not in ISO C, but in most
implementations of the languages there are libraries that fill those
gaps.

The regulars however would like to strip the language of all
practical significance.

 

[santosh]

Java supports networking, Python supports networking, Perl supports
networking, Ruby supports networking, C# supports networking, many
others support networking.

What you chose perhaps to overlook is that one of the real advantages of
ISO C is it's easy implementability (leaving aside for the moment the
tragedy of C99 which was perhaps more a result of implementor
pragmatism than any technical difficulty) on a very wide range of
systems from the PICs to supercomputers. Even hosted implementations of
C are much more widespread than nearly any other language. This is a
side effect of the Committee keeping the standardised features to those
with existing implementations and in common use.

There is no *need* to bring in networking within C, because one of the
most popular networking API, the Berkeley sockets (and it's WinSock
Windows imitation), is written in C and more easily accessible from C
than in those other languages that you mention (whose primitives in
most cases are implemented on top of the BSD API anyway.)

Java supports graphics, Python supports graphics, others probably
support graphics.

Are you saying that graphics is impossible in C. Note that GTK+, X
Windows, and earlier versions of Windows GDI are all done in C. The
language Standard doesn't include graphics, but again, it can be easily
done with any of the many toolkits and APIs.

GUIs are not the same as graphics, if that's what you meant. Anyway,
Java supports GUIs, Python supports GUIs, others probably support
GUIs.

And you can use GTK+ from C. There is also the Win32 API and Xlib for
the adventerous.

Java supports directory operations, Python supports directory
operations, Perl supports directory operations, C# supports directory
operations, Ruby supports directory operations, many others support
directory operations.

Personally, I wouldn't mind directory support being added to C1x, but in
any case I suspect that the POSIX directory APIs are available on all
the systems that the above languages are themselves available on.

<snip>

So, you see, many people (perhaps most people) do think those things
should be part of a programming language's standard (I mean "standard"
in a general sense, not necessarily a document like C's standard), and
some of them have worked hard on them. They're just not what you think
should be "a programming language standard."

No. You yourself admit above that those things need not be all included
in a single all encompassing document. And you're perfectly right. All
those things have either formal or de facto standards already and all
are easily accessible from C. Indeed most of them are *implemented* in
C.

 

[Ben Bacarisse]

Java supports networking, Python supports networking, Perl supports
networking, Ruby supports networking, C# supports networking, many
others support networking.

This is drifting off-topic, but unless I am looking at the wrong
standard C# (to take one example) does not have networking. As one
would expect it is an extra library that provides it. C# plus .NET
would be better compared to C + POSIX. In that sense C has networking
exactly like C# has networking -- via another specified interface
*outside* the language.

The trouble with cross-language discussions in comp.lang.X is the lack
of experts about Y and Z who will corrects the myths that get posted
about the other languages. (I am not setting myself up as C# expert,
by the way, I just happen to have the document to hand.)

 

[Keith Thompson]

Eric Sosman wrote:

[Eric Sosman quoting jacob navia:]

Yes, Why keep them?

[...]

If that's a serious question, I'll be glad to answer it for you.

 

[Keith Thompson]

Right. It's the domain of other standards, not of a programming
language standard.


Right. It's the domain of other standards (and less formal quasi-
standards), not of a programming language standard.


You're repeating yourself.


Right. It's the domain of other standards, not of a programming
language standard.


Right. It's the domain of other standards, which some experts
consider premature: The state of the art, they say, is insufficiently
advanced to warrant standardization. In any event, it's not an
appropriate matter for a programming language standard. (And before
somebody hollers "Java," read the serious and sometimes virulent
criticisms that have been leveled at its attempts to parallelize.)


You're repeating yourself.

[snip]

Eric, I think you're overstating the case. The listed features aren't
part of the C language standard, and IMHO most or all of them don't
need to be. But there are plenty of *other* languages that provide
such things as built-in features. (Ada has built-in multitasking;
Perl has just about everything, though much of it is in the form of
libraries.)

I see no fundamental reason why threads, for example, *shouldn't* be
part of a language standard, depending on the intended scope of the
language. It just isn't part of the C language standard.

 

[Keith Thompson]

Exactly. And those things ARE supported in C. Not in ISO C, but in most
implementations of the languages there are libraries that fill those
gaps.
Right.

The regulars however would like to strip the language of all
practical significance.

No, we would not.

After all the years you've been reading and posting to this
newsgroup, you still don't understand this simple point.

All this stuff (GUIs, networking, threads, directories, etc.) can be
done in C by the use of add-on libraries outside the ISO C standard.
That's great. The standard itself specifically permits extensions
provided in the form of additional library functions. One of
C's greatest strengths is its ability to support these kinds of
extensions, and to allow *non-portable* programming when it's needed.

There's nothing wrong with additional libraries. Without them,
C would not be nearly as useful as it actually is.

You see? We're in agreement. How did manage not to notice that?

And yes, I disagree with those who say that code that uses
non-standard extensions is "not C".

But *there are other newsgroups* in which the details of those
non-standard libraries can be discussed. This newsgroup, by the
consensus of most of the participants (remember, we had a survey
less than a year ago), is for discussion of the standard C language,
which is more than enough to keep us busy indefinitely. And if you
think that questions about how to declare main() or what's wrong
with ``i=i++'' are the only things within that scope, that's just
a failure of your imagination and powers of observation.

If you want to talk about features provided by POSIX, go to
comp.unix.programmer. If you want to talk about features provided
by lcc-win, go to comp.compilers.lcc. If you want to push for new
features in the C standard, go to comp.std.c. If you want to talk
about the C language itself, this is the right place.

If I point out that something is off-topic, I'm not trying to limit
the scope of C, just of this newsgroup. ISO C is a big subject,
and I want to have a place where I can discuss it.

And somehow you'll manage yet again to fail to understand this.
I'm almost curious to see how you do it this time.

 

[Kenny McCormack]

which is more than enough to keep us busy indefinitely. And if you
think that questions about how to declare main() or what's wrong
with ``i=i++'' are the only things within that scope, that's just
a failure of your imagination and powers of observation.

You are outrageously misrepresenting Jacob's (and others, including
myself) position. We deman an apology. We all know what a heinous
crime it is in CLC-land to misrepresent what someone says (and we know
how seriously folks here take this!).

Jacob's and my position (and that of many others) is that the list below
represents the totality of CLC's usefulness (as CLC is at present):

1) How to declare main()
2) What's wrong with `i=i++'
3) Why you should not cast the return value of malloc()

You do us a grevious disservice by not including that last, all
important, element from the list.

 

[santosh]

[ ... ]

o no network
o no graphics
o no GUI
o no directories
o no parallelism
o no threads

Right. It's the domain of other standards, [ ... ]
[ ... ] In any event, it's not an appropriate matter for a
programming language standard.

[ ... ]

Eric, I think you're overstating the case. The listed features aren't
part of the C language standard, and IMHO most or all of them don't
need to be. [ ... ]

That's exactly what many people fail to understand. I admit that it *is*
tempting to wish that one language/framework had support for most of
the typical tasks (and as you note, many languages like Python, Java,
Perl and others do implement this philosophy), but Standard C isn't the
right choice.

C's future lies in areas where ease of implementation, and efficiency
matter. Burdening C with innumerable features will be catastrophic for
the language, since it will simply mean that such a Standard will be
ignored outright by just about every implementor, except perhaps jacob
(and even he, I doubt, will be able to implement such a "super" C,
given that he is yet to fully implement the current language). Why
would they want to re-implement things that either they or someone else
has already done, and why would WG14 want to standardise functionality
that is either already standardised or is not suitable for
standardisation? Besides where is WG14 going to get the resources to
accomplish such a task?

But there are plenty of *other* languages that provide
such things as built-in features. (Ada has built-in multitasking;
Perl has just about everything, though much of it is in the form of
libraries.)

I see no fundamental reason why threads, for example, *shouldn't* be
part of a language standard, depending on the intended scope of the
language. It just isn't part of the C language standard.

I admit that it's tempting to wish that one well known language/tool had
all that you could desire, but not all languages are (or should) going
to go down that path.

 

[Antoninus Twink]

You are lying, as always


same lie


same lie

This is the way with Sossman, he's a Jeckell-and-Hyde character.
Sometimes he's funny and good-natured and provides useful information
and interesting historical anecdotes; other times, he behaves just like
Heathfield.

 

[Antoninus Twink]

They are not written in 'regulars C'
o no network
o no graphics
o no GUI
o no directories
o no parallelism
o no threads
o no nothing actually

The thing that always amuses me is that all the regulars drool over K&R2
and recommend it to newbies... presumably they all tear out Chapter 8 of
any copy they own, seeing as it's "non-portable, not standard, can't
discuss it" by their definitions. Oh, and it casts the return value of
malloc(), too - the most famous clc shibboleth.

 

[Antoninus Twink]

Sure I said that. And I go on saying that.

You haven't got any example of any important software in ISO C.

Come now, are you discounting CBFalconer's brilliant ggets function?

 

[Antoninus Twink]

But when you accuse people of lying, as you've done twice
to me in this thread alone, that is not all right. That is an
accusation of dishonesty and bad faith, and assault not on ideas
but on character.

Be ashamed. And stop it.

An interesting sensitivity for one who's systematically tried to destroy
the character and reputation of Jacob Navia over the past few years,
along with Heathfield, Mackintyre, "Old Wolf" and the rest of your cabal
of bullies, liars and cowards.

 

[Antoninus Twink]

This newsgroup, by the consensus of most of the participants
(remember, we had a survey less than a year ago), is for discussion of
the standard C language

This is misleading. You mean "most of the participants in the survey",
not "most of the participants in the newsgroup". The participants in the
survey were a self-selecting group of those who care deeply enough about
topicality to bother participating in a stupid and rigged survey about
it.

Truth is, clc is not moderated and has no charter. In those
circumstances what is discussed here is whatever is discussed here - de
facto.

 

[s0suk3]

What you chose perhaps to overlook is that one of the real advantages of
ISO C is it's easy implementability (leaving aside for the moment the
tragedy of C99 which was perhaps more a result of implementor
pragmatism than any technical difficulty) on a very wide range of
systems from the PICs to supercomputers. Even hosted implementations of
C are much more widespread than nearly any other language. This is a
side effect of the Committee keeping the standardised features to those
with existing implementations and in common use.

There is no *need* to bring in networking within C, because one of the
most popular networking API, the Berkeley sockets (and it's WinSock
Windows imitation), is written in C and more easily accessible from C
than in those other languages that you mention (whose primitives in
most cases are implemented on top of the BSD API anyway.)

That seems reasonable; I agree. I just don't think they're not the
"domain of a programming language standard," only because they're not
in C's standard. Although on the accessibility matter, I don't think
this is so. It's true that most popular OSs support their APIs in C,
and with C you get direct access to them (unlike in Python, for
example, where you get the functionality through a module that's
actually written in C). But if you're going to port to another OS, you
need to depend on a specific OS's API or develop a portable framework
for your app alone (unlike in the above mentioned languages, where
even though you get most of the functionality through a lower-level
and less accessible module, you get the same interface in every
supported OS). Anyway, I do think it's worth the advantages you
mentioned in the first paragraph.

Are you saying that graphics is impossible in C. Note that GTK+, X
Windows, and earlier versions of Windows GDI are all done in C. The
language Standard doesn't include graphics, but again, it can be easily
done with any of the many toolkits and APIs.



And you can use GTK+ from C. There is also the Win32 API and Xlib for
the adventerous.



Personally, I wouldn't mind directory support being added to C1x, but in
any case I suspect that the POSIX directory APIs are available on all
the systems that the above languages are themselves available on.



No. You yourself admit above that those things need not be all included
in a single all encompassing document. And you're perfectly right. All
those things have either formal or de facto standards already and all
are easily accessible from C. Indeed most of them are *implemented* in
C.

In essence I was just trying to point out that those things /can/ be
the domain of a programming language. But I agree that most of them
would be inconvenient or unnecessary to standarize in C, for the exact
reasons you pointed out.

Sebastian

 

[Kenny McCormack]

An interesting sensitivity for one who's systematically tried to destroy
the character and reputation of Jacob Navia over the past few years,
along with Heathfield, Mackintyre, "Old Wolf" and the rest of your cabal
of bullies, liars and cowards.

Funny how that works, isn't it? Double standards and all...

 

[CBFalconer]

.... snip ...

They are not written in 'regulars C'
o no network
o no graphics
o no GUI
o no directories
o no parallelism
o no threads
o no nothing actually

Now you are getting the idea. You can write conforming code to do
those things, but they don't exist in a purely standard C program.
I trust this means your posts will be closer to topical in future.

 

[Richard]

Now you are getting the idea. You can write conforming code to do
those things, but they don't exist in a purely standard C program.
I trust this means your posts will be closer to topical in future.

That is of course total and utter nonsense.

The C standard does not define a function called ChuckIsASelfImportantBlowhard()
either but that doesn't mean I can't write one in standard C. My program
is still written in standard C.

You probably meant to say they do not exist in the C standard and not
that they dont exist in a purely standard C program.

 

[Coffee Pot]

An interesting sensitivity for one who's systematically tried to destroy
the character and reputation of Jacob Navia over the past few years,
along with Heathfield, Mackintyre, "Old Wolf" and the rest of your cabal
of bullies, liars and cowards.

Twink you know nothing about Navia. Like you he wants to ruin this group.
He could care less about C, only his lccwin32. This IS NOT C. He refuses
to conform to the ISO Standard. He attacks people who report
conformance bugs. He is a paranoid liar. Navia has caused division in this
group. Navia is a disgrace to C programming.

Regards,
Coffee Pot