Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C is fixed or not ?

Reply
Thread Tools

C is fixed or not ?

 
 
Rui Maciel
Guest
Posts: n/a
 
      07-06-2011
MikeP wrote:

> 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
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      07-06-2011
Rui Maciel <(E-Mail Removed)> writes:
[...]
> 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?

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      07-06-2011
On 07/ 6/11 02:21 PM, Rui Maciel wrote:
> 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".


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

--
Ian Collins
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      07-06-2011
Ian Collins wrote:

> 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
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      07-06-2011
Ian Collins wrote:

> 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
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      07-06-2011
Keith Thompson wrote:

> 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
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      07-06-2011
On 07/ 6/11 03:00 PM, Rui Maciel wrote:
> Ian Collins wrote:
>
>> 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?


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

--
Ian Collins
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      07-06-2011
On 07/05/2011 10:11 PM, Rui Maciel wrote:
> jameskuyper wrote:
>
>> jacob navia wrote:

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

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


I've had poor results from message links, but you can give it a try:
<http://groups.google.com/group/comp.lang.c/browse_frm/thread/21e07a877fbc1bdd/109b360e785de90c?q=group:comp.lang.c+insubject:Int erview+insubject:with+insubject:Mr.+insubject:Stro ustrup#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.
--
James Kuyper
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      07-06-2011
On 07/05/2011 11:15 PM, Rui Maciel wrote:
> Keith Thompson wrote:
>
>> 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.


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?
--
James Kuyper
 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      07-06-2011
jacob navia <(E-Mail Removed)> wrote:
>
> 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.
--
Larry Jones

Talk about someone easy to exploit! -- Calvin
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Newbie: fixed and not-empty element monique XML 3 01-27-2006 09:20 AM
Has 2.0 Fixed this 1.1 bug? Radio Buttons Are Not Mutually Exclusive When Used in a Repeater Server Control sloan@ipass.net ASP .Net 0 01-06-2006 09:23 PM
Free Fixed-Width/Fixed-Pitch fonts? johnp HTML 4 05-23-2005 06:14 AM
"Transparent" div not possible in IE - "background-attachment: fixed" not properly rendered GuyBrush Treepwood HTML 4 03-29-2005 07:16 AM
Fixed: Pix 501 which will not send on VPN AnyBody43 Cisco 0 10-28-2004 02:25 PM



Advertisments