C is fixed or not ?

[jacob navia]

Le 06/07/11 06:09, (e-mail address removed) a écrit :

Obviously. Strangely, none of the proposals I've made in
alt.usage.english to change the English language have made it into the
OED, either.

Your arrogance is without limits. Go ahead

 

[deeanabrown33]

hi,
i'm new here,
can you tell me about this forum?
=================================================

 

[jacob navia]

Le 05/07/11 23:47, jameskuyper a écrit :

There's always a lot of old code that never gets rewritten to work
with/take advantage of new features in the language. That's one of the
key reasons why both I and the committee prefer a more conservative
approach to language change than you usually do. It's rather
refreshing to see you recognizing this as a potential problem. There's
some hope for you yet!

NONE of the proposal I have developped (operator overloading,
usage of const, container library) makes ANY incompatible changes
with existing code or makes for a full replacement of existing code.
My proposals centered in NEW syntax/semantics for NEW code.

If the committee does a better job of this than you give them credit
for, the reason why new code might be written using the new facilities
is portability. Code that's targeted to run in both Windows and POSIX
environments could be simplified by using the new C features, rather
than being written separately for each environment. This is a
relatively minor advantage, which is why it's taken so long to
convince the committee to consider the issue, but it is still and
advantage.

The fact is that Plauger (who works for microsoft) pushed this
into C++ apparently, and the C committee "decided" to follow him
even if nobody was asking for that. It is a priority because
the C++ changes, not because of the C language needs.


The committee hasn't done any improvement of the completely obsolete
C library, refuses to consider (for 5 years) a revision of the
overflow bug for asctime() in the language standard text, refuses
any change and suddenly wakes up to life, and will promulgate
a new standard in record time because Plauger needs his multi-
threading library as a standard.

OK, go ahead.

I certainly hope that someone will have proven that the new features
are implementable, by implementing them, before the final vote is made
on the decision to mandate them. Do you have any rational reason to
think that they won't be?

Microsoft has abandoned C as a language and tries to get away from
it with the new versions of windows OS. C# and .net are now their
focus, and the decisions of the C standards committee are not much
worth for them: they never implemented c99, and probably will not
do anything for the next one either.

Gnu stopped caring about C some time ago, and even if their
implementation of c99 is a good one they stopped developing
it some years ago since their main effort is c++. They may
implement the new features or not, nobody knows. If they stopped
implementing c99 it is unlikely that they give much credit to
the committee for the next standard.

They weren't widely supported ... because they were easy to
implement?! Do you think they would have been more widely adopted if
they had been harder to implement?

You are misquoting me because you have nothing to say.

...

The frequent use of "thread" in this forum to refer to a connected set
of messages makes it difficult to search for such things accurately.
However, I quickly found such a suggestion that had been made as
recently as January this year, in the thread titled "Interview with
Mr. Stroustrup". Considering the source, I wouldn't consider it a
serious suggestion, but it was widely discussed by many people,
including yourself.

That was a C++ guy that told here: Do as C++ does. Since C++ wants
multi-threading support C should do it too. It was a two lines
sentence, and all the discussion was about Stroustroup and C++,
not C.

I have no desire to support them any farther than I actually am in
agreement with them. As I'm frequently in disagreement with them, and
have frequently expressed such disagreement, I'm at a loss as to how
you could conclude otherwise.

...

Well, in that case it should be pretty easy to confirm whether the
proposal can be implemented; if nothing else, Plaugher can make the
needed modifications to his own library, and determine whether they
work. Since his library is fairly popular, that also suggests that
there's a reasonable amount of existing experience with how to use a
library that's not too different from the final proposal.

But WHY do we have to include that library in the core language?

 

[Keith Thompson]

Obviously. Strangely, none of the proposals I've made in
alt.usage.english to change the English language have made it into the
OED, either.

I'll just mention that
<http://www.open-std.org/JTC1/SC22/WG21/docs/standards> says:

The public can submit proposed defect reports via the Internet news
group comp.std.c++

and that I personally would like comp.std.c to have a similar status
with the C committee.

 

[Chris H]

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

C cannot be changed, it can only be replaced.[/QUOTE]

Wrong.... We are constantly updating C

 

[Jens Gustedt]

Am 06.07.2011 04:46, schrieb Ian Collins:

On 07/ 6/11 02:21 PM, Rui Maciel wrote:
Atomics are a language feature, not something that can be specified in a
library.

I disagree.

I consider the library part of the new standard about atomic
operations the most interesting one. Compiler vendors already provide
extensions for this (I know particularly of gcc) and it is a very
interesting move to standardize this.

In particular I think you don't need support of atomic types (_Atomic
in C1x) to implement these new library calls.

 

[Chris H]

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.

That is the crux of the problem. C99 was very slow in it's uptake and
then only partially. IF C1X is also not what the industry wants then
it too will be ignored.

This will damage the credibility of the ISO C Group

ISO C standards should be standardising current practice not introducing
new things. If new things are wanted compiler companies would already
be implementing them for their customers.

If there is (or is not) customer demand compiler companies will (or
will not) implement features no matter what the standard says.

 

[Ian Collins]

Le 05/07/11 23:47, jameskuyper a écrit :


The fact is that Plauger (who works for microsoft) pushed this
into C++ apparently, and the C committee "decided" to follow him
even if nobody was asking for that. It is a priority because
the C++ changes, not because of the C language needs.

Care to cite where that rumour originated? I don't see PJP as authour
of any of the C++ threading proposal papers.

 

[Stefan Ram]

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

I have learned that not everyone participating in this
newsgroup has a background in computer science. So it
seems that I'll have to explain:

A programming language is a »formal language«:

»In computer science[, formal languages] are used, among
other things, for the precise definition of data formats
and the syntax of programming languages.«

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

, and a formal language is a »set of words«. Sets do not
change in time. If one changes just one word, however tiny
the change is, one gets a different set. This is, why
programming languages cannot change in time.

However, the meaning of words can change in time, for
example, »C« today is another programming language than »C«
in 1995. To avoid confusion, we also need time-independent
identifiers for programming language. For C, one thus can
prefix »C« with the name of the publication or publications
defining it, such as, for example »ISO/IEC 9899:1999 (E)+TR1 C«.

 

[jacob navia]

Le 06/07/11 10:10, Ian Collins a écrit :

Care to cite where that rumour originated? I don't see PJP as authour of
any of the C++ threading proposal papers.

The original proposal for the C library presented was a copy and paste
of the documentation of Plauger's multi-threading library.

 

[Shao Miller]

Perhaps it's irrelevant to you; but it's of interest to me, particular
insofar as I lack both sufficient experience with POSIX threads, and
sufficient understanding of the C201X proposal, to compare them.

The "thread" discussion in even C1X strikes me as simply a natural part
of the establishment of the sequencing model. Since sequencing detail
perhaps left a bit to be desired in C99, its development in C1X might as
well consider threads, since there are sequencing concerns there, too.
Why, even sequencing concerns about 'volatile' appear to be addressed.
Surely, sequencing is a big part of C1X.

If there's any point at all to having a separate C API, it seems to me
that the C API should have sufficient flexibility to be efficiently
implementable using either POSIX calls, or Windows calls. That would
almost certainly not be achievable by simply duplicating the POSIX standard.

I'd appreciate knowing, from someone who's at least familiar with all
three, and preferably an expert in all three, whether that is indeed
what the proposal has attempted? If so, how well has it succeeded?

Right.

 

[Rui Maciel]

Pressure from the vendor is irrelevant; pressure from users is
important; and it is, unfortunately, one of the more widely used
platforms. I'm agnostic about whether adding threading to the C standard
was a good idea, but I can certainly see why it might be desirable to
have a threading API that can be used on both Windows and POSIX systems.

You are implying that it is impossible to use pthreads on a Windows system,
which is false[1].

[1] http://technet.microsoft.com/en-us/library/bb463209.aspx

...

I've had poor results from message links, but you can give it a try:
<http://groups.google.com/group/comp...subject:Interview+insubject:with+insubject:Mr.
+insubject:Stroustrup#109b360e785de90c>;
if that link doesn't work for you, search on groups.google.com for a
message posted to comp.lang.c with the subject line "Interview with Mr.
Stroustrup", and you'll find it quickly enough; more quickly than the
time it took you to write a request for a link.

The key words from the very first message in that thread were:

I don't see any way to deny that this is, indeed, an example of someone
"asking for multi-threading support in this forum", and far more
recently than 10 years ago. But I have faith in jacob; he'll find a way.

The problem with that statement is that it reads as if prior to C201x there
was no standard for implementing threads in C, which is obviously false.
Therefore, if the only case which is made to justify forcing threads into
the revamped C standard is that "multi-threading is the future", C++ will
have it and that a standard that covers multi-threading in C "provides
support for portable and efficient concurrency" then I have to say that the
wrong approach is being justified for all the wrong reasons, which includes
the suspicion that some proponents are oblivious to current standards that
already cover this very same subject.


Rui Maciel

 

[Rui Maciel]

Where does the international standard for the C threading API define
lock-free types?

Where does ISO/IEC 9899:1999 define lock-free types?


Rui Maciel

 

[Rui Maciel]

Perhaps it's irrelevant to you; but it's of interest to me, particular
insofar as I lack both sufficient experience with POSIX threads, and
sufficient understanding of the C201X proposal, to compare them.

You didn't understand what I said. The reason why it is irrelevant to
compare similarities between both APIs is that, as it was acceptable to
create a brand new standard that covers the exact same subject that a widely
establised standard already covers for over a decade, then it would also be
acceptable to update any part of the pre-existing standard which might need
updating. This would simplify the C 201x standardization process a great
deal. If the new C 201x standard simply added somewhere in the text the
following snippet:

"In ISO/IEC 9899:201x, the support for threads is intended to be in
conjunction with:
- IEEE Std 1003.1c-1995 - POSIX threads API"

Then the C standard would be leaner, the standardization process would be
simpler and, most importantly, the relevant implementation details could be
cleanly separated from each other.

If there's any point at all to having a separate C API, it seems to me
that the C API should have sufficient flexibility to be efficiently
implementable using either POSIX calls, or Windows calls. That would
almost certainly not be achievable by simply duplicating the POSIX
standard.

You are talking about POSIX threads as if they were some foreign API which
was impossible to implement in any OS. It isn't that case, quite the
contrary. POSIX was specificallly designed to be a set of portable
interfaces, and you will be hard-pressed to find any relevant platform that
supports threads but not only doesn't provide a standard-compliant threads
API but also is technically incapable of supporting it. As I've already
pointed out, even Microsoft provides pthreads for the Windows platform. So,
knowing this, why do you refer to pthreads as something other than a
standard for implementing threads in a portable and flexible way?



Rui Maciel

 

[Chris H]

Actually he works for http://dinkumware.com/ who produce libraries for
many compiler companies of whom Microsoft is but one.

I would agree that C does not need it.

Care to cite where that rumour originated?

Which bit that he works for Microsoft? (which he clearly doesn't at
least not more than any other compiler company)

Or the threading stuff?

 

[Chris H]

I have learned that not everyone participating in this
newsgroup has a background in computer science.

Correct... But I do and I have also been on the ISO C panel and have
just done two days on the MISRA-C working group.

A programming language is a ›formal language‹:

›In computer science[, formal languages] are used, among
other things, for the precise definition of data formats
and the syntax of programming languages.‹

Other than the large amount of known undefined and implementation
specific stuff in the standard there are the errors and mistakes that
cause TC's and amendments. The C standard is NOT fixed it is evolving
at least it was when I was on the ISO C panel.

As for
http://en.wikipedia.org/wiki/Formal_language

Wiki is NOT a valid reference for this. (An ISO standard might be)

Some of us also have to work in reality of critical systems. So take
your word games elsewhere where they may be appreciated.

 

[jacob navia]

Le 06/07/11 10:10, Ian Collins a écrit :

Care to cite where that rumour originated? I don't see PJP as authour of
any of the C++ threading proposal papers.

Dinkumware thread library
-------------------------
int thrd_create(thrd_t *, thrd_start_t, void*);
thrd_t thrd_current(void);
int thrd_detach(thrd_t);
int thrd_equal(thrd_t thr0, thrd_t thr1);
void thrd_exit(int);
int thrd_join(thrd_t, int*);
void thrd_sleep(const xtime*);
void thrd_yield(void);


Proposed C standard
-------------------
int thrd_create(thrd_t *thr, thrd_start_t func,void *arg);
thrd_t thrd_current(void);
int thrd_detach(thrd_t thr);
int thrd_equal(thrd_t thr0, thrd_t thr1);
void thrd_exit(int res);
int thrd_join(thrd_t thr, int *res);
void thrd_sleep(const xtime *xt);
void thrd_yield(void);

I did not pursue this further. If you do not believe me please look in
http://www.dinkumware.com/manuals/?manual=compleat&page=threads.html

 

[lawrence.jones]

I'll just mention that
<http://www.open-std.org/JTC1/SC22/WG21/docs/standards> says:

The public can submit proposed defect reports via the Internet news
group comp.std.c++

and that I personally would like comp.std.c to have a similar status
with the C committee.

That's a perfectly reasonable desire. However, the C committee decided
a LONG time ago that the signal to noise ratio here is far too low for
it to be a useful source of input. I don't frequent comp.std.c++ so I
don't know if it's any better or not, but the C++ committee has a lot
more resources than the C committee does.

 

[lawrence.jones]

If there's any point at all to having a separate C API, it seems to me
that the C API should have sufficient flexibility to be efficiently
implementable using either POSIX calls, or Windows calls. That would
almost certainly not be achievable by simply duplicating the POSIX standard.

That is exactly the point of the C1X threads API. It was specifically
designed (by Dinkumware, who proposed it for inclusion in the Standard)
to be easily implemented as a very thin layer on top of either pthreads
or Windows threads, allowing multithreaded programs to be easily
portable to either system. It does not provide access to all of the
features of either system, but it does provide access to the commonly
used ones in a portable manner. My understanding is that it is in
active use by Dinkumware itself as well as its customers.

 

[jacob navia]

Le 06/07/11 16:59, Chris H a écrit :

Actually he works for http://dinkumware.com/ who produce libraries for
many compiler companies of whom Microsoft is but one.


I would agree that C does not need it.


Which bit that he works for Microsoft? (which he clearly doesn't at
least not more than any other compiler company)

Or the threading stuff?

Dinkumware thread library
-------------------------
int thrd_create(thrd_t *, thrd_start_t, void*);
thrd_t thrd_current(void);
int thrd_detach(thrd_t);
int thrd_equal(thrd_t thr0, thrd_t thr1);
void thrd_exit(int);
int thrd_join(thrd_t, int*);
void thrd_sleep(const xtime*);
void thrd_yield(void);


Proposed C standard
-------------------
int thrd_create(thrd_t *thr, thrd_start_t func,void *arg);
thrd_t thrd_current(void);
int thrd_detach(thrd_t thr);
int thrd_equal(thrd_t thr0, thrd_t thr1);
void thrd_exit(int res);
int thrd_join(thrd_t thr, int *res);
void thrd_sleep(const xtime *xt);
void thrd_yield(void);

I did not pursue this further. If you do not believe me please look in
http://www.dinkumware.com/manuals/?manual=compleat&page=threads.html

I complained about this around 2 years ago, when I objected to the
numerous errors in the proposed document.