C is fixed or not ?

M

MikeP

jacob said:
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++.

What's the point of limiting one's creative possibilities to the C SUBSET
of C++? I GET "simplicity". I also get TOO SIMPLE/INADEQUATE. You really
need to have a defined audience for any such dialog. I do desktop/server
apps in C++, call me crazy if you must, but I can foresee phones and such
(other embedded actually) in my future. And I'm a SLOW (last?) ADOPTER!
Once, there was the ubiquitous "C API" that was the glue for all else.
That time is gone and is going away.
Now I understand...

Sounds "hissy-ish", FYI.
 
J

jacob navia

Le 05/07/11 06:28, MikeP a écrit :
What's the point of limiting one's creative possibilities to the C SUBSET
of C++?

The point is that it is another distinct computer language that has
several advantages from its bloated counterpart.

I GET "simplicity". I also get TOO SIMPLE/INADEQUATE.

Yes, that is why I am trying to preserve its simplicity without
keeping its inadequacies.
You really
need to have a defined audience for any such dialog.

C programmers
I do desktop/server
apps in C++, call me crazy if you must, but I can foresee phones and such
(other embedded actually) in my future.

ell, I am programmming applications for the iphone in C99 and
objective C. Both languages go very well together and yes
there isn't any C++ that I can see.

And I'm a SLOW (last?) ADOPTER!

Adopter of the wrong language.
Once, there was the ubiquitous "C API" that was the glue for all else.
That time is gone and is going away.

Excuse me but that will never go away. The C api is the only glue
that can hold two C++ applicatons compiled with different compilers.
 
J

jacob navia

Le 05/07/11 06:20, MikeP a écrit :
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.

WOW !

I am scared, completely shaken by your terrible words.

When I am done with this message I will immediately commit suicide
obviously, since you have just sealed my fate.

:)
 
M

Malcolm McLean

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.
A good design is only one factor in acceptance. Others are support
from compiler vendors, some solid reason for abandoning competing
methods, sufficient stability in underlying technologies to give the
design longevity, and marketing issues.
 
J

jameskuyper

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

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.

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!

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.

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?
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.

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?

....
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

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.
It is obvious that you want t support the committee, and maybe it is

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.

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

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.
 
R

Rui Maciel

jameskuyper said:
jacob navia wrote:

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!

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.

As POSIX is already an international standard intended to provide a Portable
Operating System Interface, and therefore designed specifically to provide
portability, wouldn't it make sense if the new C standard simply referenced
this widely established standard instead of designing yet another redundant
set of interfaces intended to duplicate (or triplicate) already existing
APIs? Refusing to reference existing standards due to pressure from a
single platform which is sold by a single vendor doesn't make sense.

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?


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?

If you read jacob's post you will realize he didn't say that.

...

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.

Could you please provide a link to that post, specifically to the post where
someone asked for multi-threading support in the next C programming
language?



Rui Maciel
 
R

Rui Maciel

Ian said:
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++.

The case regarding C++ isn't comparable, because using pthreads with C++'s
OO features forced the programmer to jump through loops, and there wasn't
any standard way of handling threads "the C++ way".

This isn't the case with C. Using pthreads in C doesn't constitute a
problem. Adding to this, the pthreads API is already defined in an
international standard for a good number of years. I understand the need to
define some behavior which helps implement threading, but ignoring pre-
existing standards while wasting time developing a redundant API... That
doesn't make sense.

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.

Then again, I'm not aware of a single C compiler which fails to support
pthreads. So, in essence shoving threading into the new C standard will
provide C programmers with nothing new besides the need to waste time
relearning an API which they could already use for a good number of years.


Rui Maciel
 
I

Ian Collins

As POSIX is already an international standard intended to provide a Portable
Operating System Interface, and therefore designed specifically to provide
portability, wouldn't it make sense if the new C standard simply referenced
this widely established standard instead of designing yet another redundant
set of interfaces intended to duplicate (or triplicate) already existing
APIs? Refusing to reference existing standards due to pressure from a
single platform which is sold by a single vendor doesn't make sense.

Atomics are a language feature, not something that can be specified in a
library.
 
R

Rui Maciel

MikeP said:
What's the point of limiting one's creative possibilities to the C SUBSET
of C++? I GET "simplicity". I also get TOO SIMPLE/INADEQUATE. You really
need to have a defined audience for any such dialog. I do desktop/server
apps in C++, call me crazy if you must, but I can foresee phones and such
(other embedded actually) in my future. And I'm a SLOW (last?) ADOPTER!
Once, there was the ubiquitous "C API" that was the glue for all else.
That time is gone and is going away.

Your comment sounds a bit like zealotry.

Regarding the reference to «ubiquitous "C API"», one of the main reasons
some APIs were mainly written in C is because linking to C code from any
language is a relatively simple and easy task which is widely understood,
and due to this feature the API providers avoided wasting time providing
APIs for other languages. In comparisson, linking to C++ code from within
any programming language is a daunting task.

So, as you can see, the reason why C was frequently adopted for this
particular task wasn't some irrational, fanboyish stance. There were and
are very strong motives to do it this way.



Rui Maciel
 
K

Keith Thompson

Rui Maciel said:
Then again, I'm not aware of a single C compiler which fails to support
pthreads. So, in essence shoving threading into the new C standard will
provide C programmers with nothing new besides the need to waste time
relearning an API which they could already use for a good number of years.

Can somebody who's familiar with both comment on how similar POSIX
threading and C201X threading are?
 
I

Ian Collins

The case regarding C++ isn't comparable, because using pthreads with C++'s
OO features forced the programmer to jump through loops, and there wasn't
any standard way of handling threads "the C++ way".

Atomics are a language feature, not something that can be specified in a
library.
 
R

Rui Maciel

Ian said:
Atomics are a language feature, not something that can be specified in a
library.

The pthreads standard doesn't specify a threading library, it only specifies
the API. Therefore, this is a non-issue.

Regarding atomics, the ISO/IEC 9899:201x draft defines atomics as "several
macros" and "several types and functions" intended to perform atomic
operations on data. That is, the section on the draft focuses on the API.
Naturally, the aspects pertraining to the language behaviour, specifically
the bits regarding memory access, if needed, should be covered in the
language definition. As far as I know (and correct me if I'm wrong), the
draft's section on atomics doesn't specify any behaviour that the language
must follow. So, if no behaviour is defined and if the section is dedicated
to defining a section of the threading API, why should this be in the C
programming standard instead of where it belongs, which is the international
standard for the C threading API?


Rui Maciel
 
R

Rui Maciel

Ian said:
Atomics are a language feature, not something that can be specified in a
library.

As I've stated in a previous thread, the pthreads standard defines an API,
not a library. Adding to this, the pthreads standard defines an API, and
the section of C201x's draft covering atomics only defines an API.


Rui Maciel
 
R

Rui Maciel

Keith said:
Can somebody who's familiar with both comment on how similar POSIX
threading and C201X threading are?

The degree to which both APIs are similar and which features differ from
each standard is irrelevant. If if is acceptable to cover this issue by
developing from scratch a redundant definition as part of an update to an
international standard then it is also acceptable to simply update the
international standard which already covers this issue. The atomics
definition, as it currently stands, basically consists of two sections
divided in 12 pages: one covering the definition of an atomic type (less
than 1 page) and the remaining covering the atomic's library. IIRC,
pthreads doesn't cover atomic data types, but I don't see any reason why it
can't cover them.


Rui Maciel
 
I

Ian Collins

The pthreads standard doesn't specify a threading library, it only specifies
the API. Therefore, this is a non-issue.

Regarding atomics, the ISO/IEC 9899:201x draft defines atomics as "several
macros" and "several types and functions" intended to perform atomic
operations on data. That is, the section on the draft focuses on the API.
Naturally, the aspects pertraining to the language behaviour, specifically
the bits regarding memory access, if needed, should be covered in the
language definition. As far as I know (and correct me if I'm wrong), the
draft's section on atomics doesn't specify any behaviour that the language
must follow. So, if no behaviour is defined and if the section is dedicated
to defining a section of the threading API, why should this be in the C
programming standard instead of where it belongs, which is the international
standard for the C threading API?

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

James Kuyper

....
As POSIX is already an international standard intended to provide a Portable
Operating System Interface, and therefore designed specifically to provide
portability, wouldn't it make sense if the new C standard simply referenced
this widely established standard instead of designing yet another redundant
set of interfaces intended to duplicate (or triplicate) already existing
APIs? Refusing to reference existing standards due to pressure from a
single platform which is sold by a single vendor doesn't make sense.

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.

....
Could you please provide a link to that post, specifically to the post where
someone asked for multi-threading support in the next C programming
language?

I've had poor results from message links, but you can give it a try:
<http://groups.google.com/group/comp...ect: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:
Multithreading is the future - many-core processors are already becoming
the norm. Recommendation: C should follow the lead of C++ and standardize
multithreading in the same way.

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.
 
J

James Kuyper

The degree to which both APIs are similar and which features differ from
each standard is irrelevant.

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.

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?
 
L

lawrence.jones

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

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top