C is fixed or not ?

[David Remacle]

Hello,

I am a french speaker but i will try to be clear.

My question is : The C langage is it fixed or still in change ?

Thank's.

ps I would not be a throll it is just a question.

 

[Chris H]

Hello,

I am a french speaker but i will try to be clear.

My question is : The C langage is it fixed or still in change ?

Thank's.

ps I would not be a throll it is just a question.

The C language is still in change. There should be a new version in
2012

 

[Joachim Schmitz]

Hello,

I am a french speaker but i will try to be clear.

My question is : The C langage is it fixed or still in change ?

The ISO commitee is still active and proposing changes for an upcomog C201x
See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf for the
current draft for the next C standard

See also comp.std.c, which is where these thing get discussed.

Bye, Jojo

 

[Stefan Ram]

My question is : The C langage is it fixed or still in change ?

The language described by »ISO/IEC 9899:1999 (E) C« is fixed
(ignoring possible inconsistences or absences of definitions).

However, what language is referred to as »C« by the folks
changes in time. Therefore, technically, »C« is not the name
of a specific language. This, partially, is done for marketing
reasons. (K&R [1st Edition] C was successful. ISO/IEC 9899:1999
(E) C is another language, but ISO called it »C« to inherit
the success of K&R [1st Edition] C, and people followed.)

So we now have to live with the possibility that »C« in 20
years from now might be quite a different language, again.

To name a specific language, precede its name by the specification
of its implementation or specification, such as, for example:

- K&R (1st edition) C
- ISO/IEC 9899:1999 (E) C
- GNU (compiler version) C
- ...

 

[Noob]

Hello,

I am a french speaker but i will try to be clear.

My question is : The C langage is it fixed or still in change ?

Thanks.

ps I would not be a throll it is just a question.

Bonjour,

In case you're wondering, the francophone news group is fr.comp.lang.c

Regards.

 

[Chris H]

My question is : The C langage is it fixed or still in change ?

The language described by ›ISO/IEC 9899:1999 (E) C‹ is fixed
(ignoring possible inconsistences or absences of definitions).

However, what language is referred to as ›C‹ by the folks
changes in time. Therefore, technically, ›C‹ is not the name
of a specific language. This, partially, is done for marketing
reasons. (K&R [1st Edition] C was successful. ISO/IEC 9899:1999
(E) C is another language, but ISO called it ›C‹ to inherit
the success of K&R [1st Edition] C, and people followed.)

So we now have to live with the possibility that ›C‹ in 20
years from now might be quite a different language, again.

To name a specific language, precede its name by the specification
of its implementation or specification, such as, for example:

- K&R (1st edition) C
- ISO/IEC 9899:1999 (E) C
- GNU (compiler version) C

What a load of drivel.

C is NOT fixed. It is a continually evolving language.

There were errors and erata's for K&R1
C90 (ISO9899:1990) had 1 amendment and THREE TC'1
C99 Also has TC's (Technical Corrigendum fixing, amending and
changing)

C1* is in development.

So your statement that ISO C 9899:1999 is fixed is incorrect.

GNU is NOT C... C is defined by ISO. GNU has it's own definition for
GCC. GCC was developed in parallel and diverged from what became ISO C.

 

[Malcolm McLean]

My question is : The C langage is it fixed or still in change ?

It's largely fixed. There was an attempt to update the language to
include features like variable-sized arrays, however it failed to be
widely accepted. The user community preferred the language as it was.

There will be a few changes in future, but expect them to be minor.

 

[Noob]

It's largely fixed. There was an attempt to update the language to
include features like variable-sized arrays [i.e. C99], however it
failed to be widely accepted. The user community preferred the
language as it was.

There will be a few changes in future, but expect them to be minor.

Do you consider multi-threading support and bounds-checking
interfaces minor features?

http://en.wikipedia.org/wiki/C1X

Or do you think these features will not make it into the
next standard?



Regards.

 

[James Kuyper]

It's largely fixed. There was an attempt to update the language to
include features like variable-sized arrays [i.e. C99], however it
failed to be widely accepted. The user community preferred the
language as it was.

There will be a few changes in future, but expect them to be minor.

Do you consider multi-threading support and bounds-checking
interfaces minor features?

http://en.wikipedia.org/wiki/C1X

Or do you think these features will not make it into the
next standard?

His comments about the past make sense only if he's referring to the
language as actually used, rather than as defined by the relevant
standards. His comments about the future are therefore, presumably,
about the language as it will be used, not about anticipated changes to
the standard.

The multi-threading features seem to be on track for approval, so his
comments imply that those changes will be just as unpopular as the ones
made in C99. Since support for multi-threaded code seems to be one of
the most popular requests in this forum, that suggests a judgment the
multi-threaded support in C1X is so poorly designed that it won't
actually be used. Is it? I can't tell, I've insufficient experience with
such things to judge.

 

[jacob navia]

Le 04/07/11 18:01, James Kuyper a écrit :

It's largely fixed. There was an attempt to update the language to
include features like variable-sized arrays [i.e. C99], however it
failed to be widely accepted. The user community preferred the
language as it was.

The multi-threading features seem to be on track for approval, so his
comments imply that those changes will be just as unpopular as the ones
made in C99. Since support for multi-threaded code seems to be one of
the most popular requests in this forum, that suggests a judgment the
multi-threaded support in C1X is so poorly designed that it won't
actually be used. Is it? I can't tell, I've insufficient experience with
such things to judge.

That will be a catastrophe.

There are mainly two competing standards that take 100% of the multi-
threaded code in C:

(1) POSIX pthreads
(2) Windows threads

The idea that people will REWRITE their threading code to please a
standard that isn't debugged, and has (at the start) ZERO support
is completely unconnected with software construction realities.

The features that were added to C99 didn't get wide support because
they weren't really essential but they were completely easy to
implement (and for many) GNU had already broken ground with them.

Implementing multi threading support however is completely different.

This needs a LOT of care to implement, and compiler vendors
will hesitate to implement something nobody asked them to do.

You say:

Since support for multi-threaded code seems to be one of
the most popular requests in this forum...

I do not remember ANYBODY asking for multi-threading support in
this forum for the pas 10 years or so, in any case as my
memory serves

If you search with google you will find a thread of about 2005
when somebody wrote here he was writing a multi-threaded TCP
server and he got the usual answer that multi-threading is system-
specific and should go somewhere else.


And you tell us "the most popular request"...

It is obvious that you want t support the committee, and maybe it is
right to do so. Bending the truth is not a good strategy however.

In this forum (and in comp.std.c) NOBODY has asked for that. The
committee decided to include that because Mr Plaugher decided that
he wanted that in the standard, not because in the user community
somebody asked for that.

The first versions of the specs were just a COPY AND PASTE from the
documentation of Plaugher's multi-thread library.

Maybe that has changed, I did not follow that since I consider that
the language can't do a THIRD specification that will ADD TO THE
CONFUSION of already two competing threading models.

I see that as completely ridiculous

 

[Ian Collins]

Le 04/07/11 18:01, James Kuyper a écrit :

Malcolm McLean wrote:

It's largely fixed. There was an attempt to update the language to
include features like variable-sized arrays [i.e. C99], however it
failed to be widely accepted. The user community preferred the
language as it was.

The multi-threading features seem to be on track for approval, so his
comments imply that those changes will be just as unpopular as the ones
made in C99. Since support for multi-threaded code seems to be one of
the most popular requests in this forum, that suggests a judgment the
multi-threaded support in C1X is so poorly designed that it won't
actually be used. Is it? I can't tell, I've insufficient experience with
such things to judge.

That will be a catastrophe.

There are mainly two competing standards that take 100% of the multi-
threaded code in C:

(1) POSIX pthreads
(2) Windows threads

The idea that people will REWRITE their threading code to please a
standard that isn't debugged, and has (at the start) ZERO support
is completely unconnected with software construction realities.

The features that were added to C99 didn't get wide support because
they weren't really essential but they were completely easy to
implement (and for many) GNU had already broken ground with them.

Implementing multi threading support however is completely different.

This needs a LOT of care to implement, and compiler vendors
will hesitate to implement something nobody asked them to do.

You say:

Since support for multi-threaded code seems to be one of
the most popular requests in this forum...

I do not remember ANYBODY asking for multi-threading support in
this forum for the pas 10 years or so, in any case as my
memory serves

Well it has been one of the most requested new features in C++. Having
native atomics built into the language will be a big win for both C and C++.

Thanks to the speed of adoption of the soon to be released C++0x, the
feature should have widespread support form vendors who provide both C
and C++ compilers.

 

[jacob navia]

Le 04/07/11 21:53, Ian Collins a écrit :

Well it has been one of the most requested new features in C++. Having
native atomics built into the language will be a big win for both C and
C++.

Thanks to the speed of adoption of the soon to be released C++0x, the
feature should have widespread support form vendors who provide both C
and C++ compilers.

OK, then, kif you want a change in the C standard you particiâte in
comp.lang.c++.

Now I understand...

NONE of the proposals discussed in cmp.std.c has made it into the
standard. Obviously we were in the wrong group

 

[Keith Thompson]

The language described by »ISO/IEC 9899:1999 (E) C« is fixed
(ignoring possible inconsistences or absences of definitions).

Not correct. Three Technical Corrigenda have been published since the
C99 standard. (And for some reason you ignored ISO C90.)

 

[Tim Rentsch]

It's largely fixed. There was an attempt to update the language to
include features like variable-sized arrays [i.e. C99], however it
failed to be widely accepted. The user community preferred the
language as it was.

There will be a few changes in future, but expect them to be minor.

Do you consider multi-threading support and bounds-checking
interfaces minor features?

http://en.wikipedia.org/wiki/C1X

Or do you think these features will not make it into the
next standard?

His comments about the past make sense only if he's referring to the
language as actually used, rather than as defined by the relevant
standards. His comments about the future are therefore, presumably,
about the language as it will be used, not about anticipated changes to
the standard.

The multi-threading features seem to be on track for approval, so his
comments imply that those changes will be just as unpopular as the ones
made in C99. Since support for multi-threaded code seems to be one of
the most popular requests in this forum, that suggests a judgment the
multi-threaded support in C1X is so poorly designed that it won't
actually be used. [snip]

The key question is not whether (or how widely) C1X might be
used but how widely it will be implemented. If C1X is widely
implemented then its new features will be used.

 

[Ian Collins]

Le 04/07/11 21:53, Ian Collins a écrit :

OK, then, kif you want a change in the C standard you particiâte in
comp.lang.c++.

Now I understand...

NONE of the proposals discussed in cmp.std.c has made it into the
standard. Obviously we were in the wrong group

Have you ever heard of cooperation?

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3137.html

 

[MikeP]

Hello,

I am a french speaker but i will try to be clear.

My question is : The C langage is it fixed or still in change ?

Neutered, but some people (oddly) are trying to reattach it's balls.

 

[MikeP]

Algol 60 is fixed. It's also not used anymore.

But Algol was surely a woman (note the complexity).

 

[MikeP]

The C language is still in change. There should be a new version in
2012

C cannot be changed, it can only be replaced.

 

[MikeP]

It's largely fixed. There was an attempt to update the language to
include features like variable-sized arrays, however it failed to be
widely accepted. The user community preferred the language as it was.

The one thing I liked about it over C++ and it was nixed... go figure!

 

[MikeP]

Le 04/07/11 18:01, James Kuyper a écrit :

Malcolm McLean wrote:

It's largely fixed. There was an attempt to update the language to
include features like variable-sized arrays [i.e. C99], however it
failed to be widely accepted. The user community preferred the
language as it was.

The multi-threading features seem to be on track for approval, so his
comments imply that those changes will be just as unpopular as the
ones made in C99. Since support for multi-threaded code seems to be
one of the most popular requests in this forum, that suggests a
judgment the multi-threaded support in C1X is so poorly designed
that it won't actually be used. Is it? I can't tell, I've
insufficient experience with such things to judge.

That will be a catastrophe.

There are mainly two competing standards that take 100% of the multi-
threaded code in C:

(1) POSIX pthreads
(2) Windows threads

The idea that people will REWRITE their threading code to please a
standard that isn't debugged, and has (at the start) ZERO support
is completely unconnected with software construction realities.

That seems to be either a silly statement or propaganda, for C (and C++)
lag behind industry usage, and the ISO just tries to bring some order to
the madness (or so I have heard).

The features that were added to C99 didn't get wide support because
they weren't really essential but they were completely easy to
implement (and for many) GNU had already broken ground with them.

Implementing multi threading support however is completely different.

This needs a LOT of care to implement, and compiler vendors
will hesitate to implement something nobody asked them to do.

I think I know where you are coming from: wishful thinking. I'm sure you
can or will be able to do something eventually, but it doesn't sound like
anything original.