«

jacob navia wrote:
> Le 04/07/11 21:53, Ian Collins a écrit :
>> On 07/ 5/11 05:20 AM, jacob navia wrote:
>>>
>>> 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.
>>
>
> 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.

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

Ian Collins wrote:
> On 07/ 5/11 08:39 AM, jacob navia wrote:
>> Le 04/07/11 21:53, Ian Collins a écrit :
>>> On 07/ 5/11 05:20 AM, jacob navia wrote:
>>>>
>>>> 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.
>>>
>>
>> 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/WG...10/n3137.htmlj

I don't understand y'all. Why don't you just merge and do the best you
can with both obsolete technologies? "Have you ever heard of
cooperation?", funny guy.

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.

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.

Noob wrote:

> Do you consider multi-threading support and bounds-checking
> interfaces minor features?
>
> http://en.wikipedia.org/wiki/C1X

On the subject of threading, I found this discussion
rather interesting.

Should "volatile" Acquire Atomicity and Thread Visibility Semantics?
http://www.open-std.org/jtc1/sc22/wg...006/n2016.html

Regards.

On Jul 4, 7:01*pm, James Kuyper <jameskuy...@verizon.net> wrote:
>
> 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.
--
Vist my website
http://www.malcolmmclean.site11.com/www

jacob navia wrote:
> Le 04/07/11 18:01, James Kuyper a écrit :
....
> > 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.

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?

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

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.

jameskuyper wrote:

> jacob navia wrote:

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

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

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


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

Ian Collins wrote:

> 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

On 07/ 6/11 02:11 PM, Rui Maciel wrote:
> jameskuyper wrote:
>
>> jacob navia wrote:
>
>>> 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.
>
> 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.

--
Ian Collins