Why do you like C more than other programming languages?

[Chris H]

Yet the standard includes _Complex and all that wonderful stuff in
<tgmath.h> that programmers of 8 bit micros had (not) been crying out for.

Which explains the rapid take up of C99....

 

[santosh]

DVD players with no graphics are not going to be too popular...

The graphics (video display) is either built-in (to a screen), or
present in the video output.

Well, I was talking about Graphical User Interfaces (GUI), not raw
audio/video processing.

 

[rahul]

rahul said:

Really? Okay, pretend I'm from Missouri - show me a Java program that can
open a network connection on my 80286 (which has no IP stack, no network
card, and no Java implementation).

If C has some feature that is not supported on some platform, that
does not mean its violating portability. Pretend that C has a
standardized set of network libraries. How is that going to make any
difference to your task of programming an 80286? Even then the code
which you write in standard C is not going to be different.

 

[rahul]

Many systems that C excels in targetting (embedded micros) often do not
have *any* support for network, graphics etc, (think micros in your car
engine or DVD player).

Fine. When you are writing for DVD player, you can pretend C has no
network and other functions. What difference will that make to your
code?

If the C Standard codified interfaces for networking or graphics they
would either have to be left out on implementations targetting these
platforms (thus non-confirming), or create stubs and no-ops for these
routines. Both will break source code portability.

How come? If an implementation X does not have support for networking,
why(perhaps how is more appropriate) will you use the networking
library on that system?

There is a very great difference (in terms of magnitude) between
implementing basic arithmetic operations and something like a portable
graphics library.

There is a great difference; but portable libraries do exist. And by
portable, I mean that is supported on commonly used environments.
Specialized purposes will always be there and you need to write
specialized code for that.

Unfortunately learning only one (or a few) language and expecting it to
provide built-in routines to solve all problems is an easy trap to fall

You generally do not write a TCP/IP protocol stack or a raster
graphics library, do you? So, more often than not, it is the built-in
routines that we use.

 

[Chris H]

DVD players with no graphics are not going to be too popular...

None of the DVD players in my PC's have a screen...

 

[Bartc]

None of the DVD players in my PC's have a screen...

You're talking about a DVD drive then.

An actual display is always going to be an optional part of any computer
system, although a PC is usually expected to have one.

 

[Bartc]

rahul said:


Just because ISO says "here is a standard set of networking functions",
that does NOT mean that hardware manufacturers are suddenly obliged to put
networking hardware onto their engine management system or washing machine
or programmable calculator. The lack of portability is a fact of life.

I was once at a talk by Vint Cerf (the internet guy) who suggested that
nearly everything in the future will be connected to the internet. Even
socks (so that you can always find the missing one of a pair; exactly how
I'm not sure, perhaps they have gps too).

So washing machines and every other household appliance will almost
certainly be on-line.

It might be about time then to incorporate networking into C, before it gets
left behind.

 

[Chris H]

I was once at a talk by Vint Cerf (the internet guy) who suggested that
nearly everything in the future will be connected to the internet. Even
socks (so that you can always find the missing one of a pair; exactly how
I'm not sure, perhaps they have gps too).

So washing machines and every other household appliance will almost
certainly be on-line.

It might be about time then to incorporate networking into C, before it gets
left behind.

Certainly not as part of the core language.

 

[soscpd]

Hello Santosh, List

Well, I was talking about Graphical User Interfaces (GUI), not raw
audio/video processing.- Hide quoted text -

Any DVD menu is enough GUI to me.

Regards
Rafael

 

[CBFalconer]

DVD players with no graphics are not going to be too popular...

The graphics (video display) is either built-in (to a screen), or
present in the video output.

You need to realize what you are talking about. First, actually
develop at least one, preferably six, complete such graphics or DVD
interface packages for use with the present language. Then
consider the size of the code, and the relationship to the
language. Also consider what percentage of applications require
that interface. If the number is sufficiently large you have
developed a business, and you can start selling your interface.
Make sure it doesn't require anything outside the normal C standard
language though.

Then you can consider _proposing_ a standard revision. You can
detail how it will affect the existing language (shouldn't alter
it) and how much extra will have to be supplied in any
implementation. This latter will be horrendous.

 

[Bartc]

You need to realize what you are talking about. First, actually
develop at least one, preferably six, complete such graphics or DVD

I was just pointing out that DVD /players/ (as opposed to mere optical
drives) are quite likely to have graphics hardware incorporated. I wasn't
proposing anything.

 

[santosh]

I was just pointing out that DVD /players/ (as opposed to mere optical
drives) are quite likely to have graphics hardware incorporated. I
wasn't proposing anything.

Ah, we misunderstood it seems. I was talking about DVD drives. Anyway,
it's beside the point, which is that there are many gadgets and systems
that use primitive processors that would be quite unable to support
anything beyond a freestanding C implementation.

Even systems that can support current hosted implementations might not
be able to support a future hosted implementation that aims to conform
to a Standard that requires support for network, graphics, threading
etc. One example that comes to mind is DOS, but I'm sure that there are
others too.

Besides, there already are de facto and actual standards for such tasks
which are reasonably widely implemented and I doubt that anything that
WG14 could codify would surpass these in terms of implementations or
portability. WG14 can just wave a wand and do magic, implementors must
feel motivated to follow, and after C99...

 

[Bartc]

Bartc wrote:

Ah, we misunderstood it seems. I was talking about DVD drives. Anyway,
it's beside the point, which is that there are many gadgets and systems
that use primitive processors that would be quite unable to support
anything beyond a freestanding C implementation.

Even systems that can support current hosted implementations might not
be able to support a future hosted implementation that aims to conform
to a Standard that requires support for network, graphics, threading
etc. One example that comes to mind is DOS, but I'm sure that there are
others too.

Besides, there already are de facto and actual standards for such tasks
which are reasonably widely implemented and I doubt that anything that
WG14 could codify would surpass these in terms of implementations or
portability. WG14 can just wave a wand and do magic, implementors must
feel motivated to follow, and after C99...

I don't use networking or threads but graphics would be nice to have in a
/simple/ package, not something monstrous like GTK; quote from the webpage:

"You will need to get the GLib, cairo, Pango, ATK, GTK+, gettext-runtime,
libpng, libjpeg, libtiff and zlib developer packages to build against GTK+,
and the corresponding runtime packages to run GTK+ programs." Oh, is that
all?

All I want is something only slightly more advanced than readpixel() and
writepixel(). And by simple I suggest *one* include file and *one* dll file
(or equivalent). The GTK download seems to contain about 1800 files.

 

[santosh]

I don't use networking or threads but graphics would be nice to have
in a /simple/ package, not something monstrous like GTK; quote from
the webpage:

"You will need to get the GLib, cairo, Pango, ATK, GTK+,
gettext-runtime, libpng, libjpeg, libtiff and zlib developer packages
to build against GTK+, and the corresponding runtime packages to run
GTK+ programs." Oh, is that all?

Well GTK does do a *lot* for you. If you wanted to do all that yourself,
you would probably find yourself duplicating at least the core
functionality of most of the above. Would your objections be put aside
if GTK had bundled all the above in one package? It makes no difference
either way, IMHO, as s/w like GTK is *meant* to run under modern
operating systems which contain *thousands* of other s/w alongside.
Admittedly it's not pretty, nor elegant, like say DOS, or the Linux of
early 90s, code size and leanness is often the first victim of
functionality and portability. I don't see any easy way out.

All I want is something only slightly more advanced than readpixel()
and writepixel(). And by simple I suggest *one* include file and *one*
dll file (or equivalent).

Ah, if that's all that you want, you ought to be able to write it
youself for the platforms that interest you. Unfortunately an average
GUI s/w developer needs more than this to produce the type of programs
that are appreciated these days.

The GTK download seems to contain about 1800 files.

Well if I counted the number of files on my system and tried to wrap my
brain around them all, I'm sure I'd soon go mad. You'll have to deal
with them piece by piece, and yes, that leads to a distressing feeling
of lack of understanding or control, but I don't see what can be done
about it short of going back to DOS.

PS. Perhaps one of these s/w might be what you are looking for?

<http://en.wikipedia.org/wiki/Simple_DirectMedia_Layer>
<http://en.wikipedia.org/wiki/Allegro_library>
<http://en.wikipedia.org/wiki/Freeglut>
<http://en.wikipedia.org/wiki/GLUI>
<http://en.wikipedia.org/wiki/FLTK>

and

<http://en.wikipedia.org/wiki/List_of_widget_toolkits>

 

[Bartc]

Bartc wrote:

Well GTK does do a *lot* for you. If you wanted to do all that yourself,

Sure, but for quick, basic stuff?

Ah, if that's all that you want, you ought to be able to write it
youself for the platforms that interest you.

Well I have done that (although my platform Windows GDI seems to go out of
it's way to make things as difficult as possible).

For basic graphics (forget GUI and imaging and whatever), wouldn't it great
if, as well as stdout, there was say stdwind (or some such name), with
half-a-dozen or a dozen functions to display graphics on it, and maybe even
working with fprintf()? Then we could have output a little more interesting
than printf() gives, and with very little effort.

 

[santosh]

Sure, but for quick, basic stuff?


Well I have done that (although my platform Windows GDI seems to go
out of it's way to make things as difficult as possible).

For basic graphics (forget GUI and imaging and whatever), wouldn't it
great if, as well as stdout, there was say stdwind (or some such
name), with half-a-dozen or a dozen functions to display graphics on
it, and maybe even working with fprintf()? Then we could have output a
little more interesting than printf() gives, and with very little
effort.

Your functions would not be implementable on machines that do not have
displays or do not have bitmapped displays. Now such machines may be a
minority (or unimportant) from your point of view, but keep in mind
that the C Standard (i.e., the Standardisation Committee) strives to
retain the _maximal_ portability of C. Graphics would seriously
conflict with their stated objectives. Happily though there is curses
and variants to do what you want, and they have been ported to just
about all platforms that you would probably care about and the
libraries are small enough to statically link with your program too, if
needed.

 

[Serve Lau]

True, though tgmath.h isn't required under freestanding implementations.

Always the same discussion. First somebody claims something is not portable
because it doesnt work on some arcane system. Then somebody else brings in
something from the current standard that doesnt work on that same system
either. And then the talk about hosted/freestanding starts.

So we have an easy fix then. Just add to the standard:

*networking support is not required under freestanding implementations*

 

[santosh]

Always the same discussion. First somebody claims something is not
portable because it doesnt work on some arcane system. Then somebody
else brings in something from the current standard that doesnt work on
that same system either. And then the talk about hosted/freestanding
starts.

So we have an easy fix then. Just add to the standard:

*networking support is not required under freestanding
implementations*

The problem is, not all currently hosted implementations will be able to
support networking (or graphics or threading etc). I gave one example
earlier: DOS.

Besides why should everthing be standardised by WG14 when other
perfectly good standards like POSIX, pthreads, OpenGL etc already
exist? Portability will *not* magically increase just because WG14 has
mandated some functions. Rather, what I suspect will happen is that
implementors (except perhaps a marginal few like lcc-win) will ignore
WG14 even more than they have thus far done.

 

[jacob navia]

I don't understand why you make an exception for lcc-win - its maintainer's
attitude towards the Standard seems to be an idyllic combination of
ignorance and contempt.

I have worked now something like 10 years implementing the C99
standard. Library, syntax, headers, it is an enormous amount of work.

And now comes this... well... "individual"
that has always cried AGAINST the C99
standard in all discussions we have had in comp.lang.c,
that has always tried
to recommend people AWAY from that standard telling me:

> I don't understand why you make an exception for lcc-win - its
> maintainer's
> attitude towards the Standard seems to be an idyllic combination of
> ignorance and contempt.

What can I say?

There is no limit to his hypocrisy.

 

[santosh]

Richard Heathfield wrote:

I have worked now something like 10 years implementing the C99
standard. Library, syntax, headers, it is an enormous amount of work.

Is there any reason why having come so far, you are yet to implement the
remaining few features that would enable you declare proudly that your
lcc-win is among the very few fully conformant C99 implementations
(modulo bugs, misinterpretations and so on)?