Still no dirent.h in C1X

[Joshua Maurice]

Haven't they already ignored C99?

I don't know. Have they? Then again, I think a lot of people have.
Still, I would think no reason to give them more excuses. So, maybe my
point is wrong in its supposed weight.

I'm still a very big fan of actual formal semantics, which is more or
less required when we start doing low level atomics. I'm specifically
a very big fan of how readable and understandable it is. (It's still
near impossible to reason about for anything but very small examples,
but I suspect it's a lot better than some of the hardware docs.)

 

[Phil Carmody]

Haven't they already ignored C99?

In totality, perhaps. However, reliance on subsets of C99 is far from
uncommon.

Phil

 

[Quentin Pope]

So what?

Should we eliminate file i/o because there are a lot of embedded systems
without any files?

I think you have an insular view of the world.

For desktop computing, C is ancient history. Sure it'll be around for a
while for operating systems and basic command line utilities, but for
most programming it's just a relic - why would anyone use C for a serious
program when there's C++ and Java and .NET?

Embedded programming is the only growth area for C. Embedded IS the
mainstream for C nowadays. But you live in a world where "everything is
an x86 running Windows" and you can't see the big picture.

Or should we eliminate math.h?

What is the use of having a time.h if the toaster has no clock?

No, because these pieces of cruft are now too well established, going all
the way back to C89. It would have been better if they'd never been
included in the standard library, but that ship has long since sailed.

But there is no reason to add any more cruft to the standard library that
would be better being supplied by implementations (maybe through
standards like POSIX that build on C) WHERE THEY MAKE SENSE on those
implementations.

I do not understand the philosophy:

"*I* do not need it therefore feature XXX is useless, just 'cruft'."

And if there are 1 million toasters around who cares?

There is surely 1 dvelopment system and ONE developer for all those!

The C standard library doesn't need to do everything. Other libraries can
be used too. Something like the directory structure on native filesystems
is inherently system-specific and non-portable, it has NO PLACE in the C
standard.

My 2c.

 

[John Tsiombikas]

For desktop computing, C is ancient history.

Seeing as more than 90% of the applications I use on my desktop are
written in C I can't see how you could possibly qualify that statement.

Sure it'll be around for a
while for operating systems and basic command line utilities, but for
most programming it's just a relic - why would anyone use C for a serious
program when there's C++ and Java and .NET?

Because those languages are terrible, especially the last two.
Also what's the definition of a "serious program"?

 

[jacob navia]

Le 02/12/11 23:26, Quentin Pope a écrit :

On Sat, 26 Nov 2011 23:43:47 +0100, jacob navia wrote:

For desktop computing, C is ancient history. Sure it'll be around for a
while for operating systems and basic command line utilities, but for
most programming it's just a relic - why would anyone use C for a serious
program when there's C++ and Java and .NET?

C is still very interesting language. Look at "Quentin Pope", the
anonymous troll in this group. He says:

why would anyone use C for a serious
program when there's C++ and Java and .NET?

But he does NOT go to a C# or .NET group. He comes to the
C group obviously, since he IS interested in C.

He says that he knows better how the C library should be.

Obviously.

Somebody that says C is "a relic" has surely the know
how and can be taken seriously as to what the future directions
of the language should be.