Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++14: Papers

Reply
Thread Tools

C++14: Papers

 
 
Rui Maciel
Guest
Posts: n/a
 
      04-08-2013
Alexander Terekhov wrote:

> Both OpenMP and pthreads are good examples that it can not be really
> done "as a library" without support on the language level (memory
> model), see e.g.:
>
> http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
> http://www.ccs.tsukuba.ac.jp/worksho...hm-iwomp10.pdf


Not true. Those papers make a case that compilers should not be "designed
independently of threading issues". That isn't the same thing as claiming
that threading and other forms of parallism can't be done "as a library".
Because that's what essentially has been done for over a decade.

Moreover, that also does not justify including a specific API for threading
in the standard.


Rui Maciel


 
Reply With Quote
 
 
 
 
Tiib
Guest
Posts: n/a
 
      04-08-2013
On Tuesday, 9 April 2013 00:57:38 UTC+3, Rui Maciel wrote:
> Alexander Terekhov wrote:
>
> > Both OpenMP and pthreads are good examples that it can not be really
> > done "as a library" without support on the language level (memory
> > model), see e.g.:
> >
> > http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
> > http://www.ccs.tsukuba.ac.jp/worksho...hm-iwomp10.pdf

>
> Not true. Those papers make a case that compilers should not be "designed
> independently of threading issues".


Yes and if to remove the quadruple negation weasel-wording from the sentence
then that means "have to support threading".

> That isn't the same thing as claiming that threading and other forms
> of parallism can't be done "as a library".
> Because that's what essentially has been done for over a decade.


With non-standard compiler extensions and platform-dependent libraries.
What was so good about it?

> Moreover, that also does not justify including a specific API for threading
> in the standard.


Do you propose to remove threads and atomic operations from C++ standard
library now because you are happy with POSIX and Win32 C API and those
OpenMP pragmas?
 
Reply With Quote
 
 
 
 
Rui Maciel
Guest
Posts: n/a
 
      04-09-2013
Öö Tiib wrote:

> On Tuesday, 9 April 2013 00:57:38 UTC+3, Rui Maciel wrote:
>> Alexander Terekhov wrote:
>>
>> > Both OpenMP and pthreads are good examples that it can not be really
>> > done "as a library" without support on the language level (memory
>> > model), see e.g.:
>> >
>> > http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
>> > http://www.ccs.tsukuba.ac.jp/worksho.../slides/Boehm-

iwomp10.pdf
>>
>> Not true. Those papers make a case that compilers should not be
>> "designed independently of threading issues".

>
> Yes and if to remove the quadruple negation weasel-wording from the
> sentence then that means "have to support threading".


You only miss the point if you really really want to.


>> That isn't the same thing as claiming that threading and other forms
>> of parallism can't be done "as a library".
>> Because that's what essentially has been done for over a decade.

>
> With non-standard compiler extensions and platform-dependent libraries.
> What was so good about it?


What you refer to as "non-standard compiler extensions" in reality means
"features which aren't included in a specific release of ISO/IEC 14882".
The computing world is built from features which aren't included in a
specific release of ISO/IEC 14882, and yet it manages to work.

Everyone is free to implement and use features which aren't defined through
an ISO standard. For example, OpenGL is a popular API, which happens to
require platform-dependent features. Do you believe OpenGL should also be
shoved onto the next C++ standard in order for C++ programmers to be able to
use it?


>> Moreover, that also does not justify including a specific API for
>> threading in the standard.

>
> Do you propose to remove threads and atomic operations from C++ standard
> library now because you are happy with POSIX and Win32 C API and those
> OpenMP pragmas?


Don't put words in other people's mouths. Stick to what people actually
say, and try not to invent imaginary claims.


Rui Maciel
 
Reply With Quote
 
Tiib
Guest
Posts: n/a
 
      04-09-2013
On Tuesday, 9 April 2013 09:52:30 UTC+3, Rui Maciel wrote:
> Tiib wrote:
> > Yes and if to remove the quadruple negation weasel-wording from the
> > sentence then that means "have to support threading".

>
> You only miss the point if you really really want to.


What point? That pthreads will work without -pthread compiler option?
No they won't. The support has to be built into compiler.

> What you refer to as "non-standard compiler extensions" in reality means
> "features which aren't included in a specific release of ISO/IEC 14882".


Having a pile of standards just does not work. There will be often
some contradiction because of defect even in one standard. Synchonizing
several seems to be impossible.

If C++ wants to stay alive then it needs to have its own libraries and not
to rely on libraries made for other languages.

> The computing world is built from features which aren't included in a
> specific release of ISO/IEC 14882, and yet it manages to work.


The computing world will manage to work without C++. Is that your point?

> Everyone is free to implement and use features which aren't defined through
> an ISO standard. For example, OpenGL is a popular API, which happens to
> require platform-dependent features.


Yet another C API.

> Do you believe OpenGL should also be shoved onto the next C++ standard
> in order for C++ programmers to be able to use it?


No, but indeed I would like C++ API for rendering. I am not against to
extend C++ standard library if there are no other ways to have stable
and well-specified C++ library otherwise.

> > Do you propose to remove threads and atomic operations from C++ standard
> > library now because you are happy with POSIX and Win32 C API and those
> > OpenMP pragmas?

>
> Don't put words in other people's mouths. Stick to what people actually
> say, and try not to invent imaginary claims.


I did not shove anything in your mouth. I did ask a question.

Sorry, it is hard to understand what you mean. You say "municipal
sanitary network" about thing that certainly is not one and "idiot"
about person who certainly is not one.


 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      04-09-2013
On Tue, 09 Apr 2013 01:27:09 -0700, Öö Tiib wrote:

> If C++ wants to stay alive then it needs to have its own libraries and not
> to rely on libraries made for other languages.


This statement is nonsensical on its face. If it was even remotely close
to the truth, C and C++ would never have achieved their dominant positions.

 
Reply With Quote
 
Tiib
Guest
Posts: n/a
 
      04-09-2013
On Tuesday, 9 April 2013 15:12:49 UTC+3, Nobody wrote:
> On Tue, 09 Apr 2013 01:27:09 -0700, Tiib wrote:
> > If C++ wants to stay alive then it needs to have its own libraries and not
> > to rely on libraries made for other languages.

>
> This statement is nonsensical on its face. If it was even remotely close
> to the truth, C and C++ would never have achieved their dominant positions.


Nonsense or not but those dominant positions feel right now about as dominant
as those of Objective-C, Shell script and Perl.
 
Reply With Quote
 
Tiib
Guest
Posts: n/a
 
      04-09-2013
On Tuesday, 9 April 2013 17:51:46 UTC+3, Scott Lurndal wrote:
> =?ISO-8859-1?Q?=D6=F6_Tiib?= <(E-Mail Removed)> writes:
> >On Tuesday, 9 April 2013 15:12:49 UTC+3, Nobody wrote:
> >> On Tue, 09 Apr 2013 01:27:09 -0700, =D6=F6 Tiib wrote:
> >> > If C++ wants to stay alive then it needs to have its own libraries and =

> >not
> >> > to rely on libraries made for other languages.
> >>=20
> >> This statement is nonsensical on its face. If it was even remotely close
> >> to the truth, C and C++ would never have achieved their dominant position=

> >s.
> >
> >Nonsense or not but those dominant positions feel right now about as domina=
> >nt
> >as those of Objective-C, Shell script and Perl.


> What's your point? COBOL is still alive. C++ will still be alive in 30
> years.


Drop of COBOL's popularity is profitable for experienced users ... less competition to available positions and less likelihood that some new
project will be started in it ... safe maintenance-mushrooming.

I do not want it. I do not have desire to become gradually such
grumpy experienced user of dying language who maintains some corporate
legacy code-base somewhere in corner. I like to do new things, have
teams ... etc. Such perspective is unlikely with language that long
term user (you) classifies like "still alive" in its forum.

I understand very well that some other people have other goals and
desires here and some may want to be specialists of such dying
legacy language.
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      04-09-2013
Öö Tiib wrote:

> On Tuesday, 9 April 2013 09:52:30 UTC+3, Rui Maciel wrote:
>> Öö Tiib wrote:
>> > Yes and if to remove the quadruple negation weasel-wording from the
>> > sentence then that means "have to support threading".

>>
>> You only miss the point if you really really want to.

>
> What point? That pthreads will work without -pthread compiler option?
> No they won't. The support has to be built into compiler.


Read what I wrote. Stick to what people actually say, not to what you
imagine in its place.


>> What you refer to as "non-standard compiler extensions" in reality means
>> "features which aren't included in a specific release of ISO/IEC 14882".

>
> Having a pile of standards just does not work.


That is a public declaration that you don't know anything about what you are
talking about. Here's a hint: eurocodes.


> If C++ wants to stay alive then it needs to have its own libraries and not
> to rely on libraries made for other languages.


Bullshit.

Here's another hint: "going the way of C++" has become a derogatory
expression.


>> The computing world is built from features which aren't included in a
>> specific release of ISO/IEC 14882, and yet it manages to work.

>
> The computing world will manage to work without C++. Is that your point?


You either have a hard time reading or dealing with what others actually
say. Either way, read what people actually say, not what you invent in its
place.


>> Everyone is free to implement and use features which aren't defined
>> through
>> an ISO standard. For example, OpenGL is a popular API, which happens to
>> require platform-dependent features.

>
> Yet another C API.


Irrelevant.


>> Do you believe OpenGL should also be shoved onto the next C++ standard
>> in order for C++ programmers to be able to use it?

>
> No


See? Was that hard? The same applies to essentially any component.


> , but indeed I would like C++ API for rendering.


Go ahead, pick any API or toolkit that fits your needs, or even write your
own. There's no need to wait for a committee to hogtie you to a specific
solution to be able to do what people have already been doing for decades.


> I am not against to
> extend C++ standard library if there are no other ways to have stable
> and well-specified C++ library otherwise.


Specifications only help with guaranteeing interoperability between
components created by multiple independent vendors. If, instead, a
component is freely distributed then it's quite possible to simply download
the component and use it as you wish. Have you heard of, for example,
Boost?

Another aspect that you've missed is the fact that once a component finds
its way to a standard, it stays there, and stays there no matter how buggy,
inept, unsafe and insecure it might end up being. Read up on C's standard
library to get an idea of the problems originated in bloating a standard
with all sorts of components.


>> > Do you propose to remove threads and atomic operations from C++
>> > standard library now because you are happy with POSIX and Win32 C API
>> > and those OpenMP pragmas?

>>
>> Don't put words in other people's mouths. Stick to what people actually
>> say, and try not to invent imaginary claims.

>
> I did not shove anything in your mouth. I did ask a question.


Don't play dumb.


> Sorry, it is hard to understand what you mean. You say "municipal
> sanitary network" about thing that certainly is not one and "idiot"
> about person who certainly is not one.


You clearly failed to read the proposals and the thread.


Rui Maciel
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      04-09-2013
Öö Tiib wrote:

> Nonsense or not but those dominant positions feel


Feel?

Meanwhile, in spite of your feelings, people keep writing software, some of
which using C++. Among those, some without having even migrated to C++11.


Rui Maciel
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-09-2013
Tiib wrote:
> On Tuesday, 9 April 2013 09:52:30 UTC+3, Rui Maciel wrote:
>
>> What you refer to as "non-standard compiler extensions" in reality means
>> "features which aren't included in a specific release of ISO/IEC 14882".

>
> Having a pile of standards just does not work. There will be often
> some contradiction because of defect even in one standard. Synchonizing
> several seems to be impossible.
>
> If C++ wants to stay alive then it needs to have its own libraries and not
> to rely on libraries made for other languages.


Where "other languages" == C?

C libraries are the glue that holds most of today's computing together.
Do you hear Python or PHP programmers complaining about their
languages incorporating C libraries? No.

C++ has done very well building on its C foundations, what is to be
gained by throwing them away and building a new set of wheels?

--
Ian Collins
 
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
2nd Call for Papers | Extended deadline: April 07 |CENTERIS'2009 - Conference on ENTERprise Information Systems | 2nd Callfor Papers CENTERIS'2009 - Conference on ENTERprise Information Systems Python 0 03-16-2009 01:59 PM
Submitted papers for the Conference: 489. Accepted papers: 158. Fromthem 6 BEST papers are also accepted to the WSEAS journals Kostas I. C++ 0 11-29-2007 11:03 AM
Submitted papers for the Conference: 489. Accepted papers: 158. Fromthem 6 BEST papers are also accepted to the WSEAS journals shuchen. C Programming 0 11-29-2007 10:59 AM
call for papers INFO VHDL 0 08-20-2003 07:24 PM
DesignCon 2004 Call for Papers J. Bhasker VHDL 0 08-05-2003 04:13 PM



Advertisments