C++14: Papers

[Rui Maciel]

Here are three links which showcase which features are being proposed for
C++14:

http://www.meetingcpp.com/index.php/br/items/a-look-at-cpp14-papers-
part-1.html
http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-papers-
part-2.html
http://meetingcpp.com/index.php/br/items/a-look-at-c14-and-beyond-papers-
part-3.html

I don't know which features will make their way into C++14, but after
browsing through those papers it looks like some people weren't satisfied
C++11 included the kitchen sink, they also want to add the rest of the
municipal sanitary network as well.

Any thoughts?


Rui Maciel

 

[?? Tiib]

On 05/04/2013 21:40, Rui Maciel wrote:
boost.asio would be a great addition to C++.

Yes, but currently it works only on POSIX or Windows AFAIK.

 

[Stefan Ram]

Yes, but currently it works only on POSIX or Windows AFAIK.

See also

http://www.purl.org/stefan_ram/pub/c++_standard_extensions_en

(published 2003-09-02).

 

[Alain Ketterlin]

Here are three links which showcase which features are being proposed for
C++14:

http://www.meetingcpp.com/index.php/br/items/a-look-at-cpp14-papers-
part-1.html
http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-papers-
part-2.html
http://meetingcpp.com/index.php/br/items/a-look-at-c14-and-beyond-papers-
part-3.html

I don't know which features will make their way into C++14, but after
browsing through those papers it looks like some people weren't satisfied
C++11 included the kitchen sink, they also want to add the rest of the
municipal sanitary network as well.

Any thoughts?

Many items on this list are library issues/proposals, and many of them
are orthogonal to each other.

I'm no language lawyer, but I really think we should split the standard
into two parts: one for the core language itself, another (or more) for
the libraries. This would make the standardization of libraries faster
(I guess), which would also provide more feedback to those in charge of
the core.

-- Alain.

 

[Rui Maciel]

Many items on this list are library issues/proposals, and many of them
are orthogonal to each other.

I'm no language lawyer, but I really think we should split the standard
into two parts: one for the core language itself, another (or more) for
the libraries. This would make the standardization of libraries faster
(I guess), which would also provide more feedback to those in charge of
the core.

I would go a slightlly different route: stop adding library stuff to the
standard, and instead make them available through Boost or a Boost-like
library aggregator service with a license that authorizes all forms of use.
There is absolutely no need to standardize a component if it's possible to
freely download and install it on any computer, or even store the source
files in the project tree.


Rui Maciel

 

[Rui Maciel]

Yeah, how dare they try to add even more utility features to the
language! Who needs things like multithreading or vectorization?
In the good old days we coded directly in asm. Using pencil and paper.

It's as if it wasn't possible to use third-party components with C++.

Don't be an idiot.


Rui Maciel

 

[88888 Dihedral]

Rui Maciel? 2013?4?6????UTC+8??4?40?31????

Here are three links which showcase which features are being proposed for

C++14:



http://www.meetingcpp.com/index.php/br/items/a-look-at-cpp14-papers-

part-1.html

http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-papers-

part-2.html

http://meetingcpp.com/index.php/br/items/a-look-at-c14-and-beyond-papers-

part-3.html



I don't know which features will make their way into C++14, but after

browsing through those papers it looks like some people weren't satisfied

C++11 included the kitchen sink, they also want to add the rest of the

municipal sanitary network as well.



Any thoughts?





Rui Maciel

Well, the objective C got all the sanitary GC part built-in.
This will drive the C++ to evolve definitely.

 

[Alexander Terekhov]

Scott Lurndal wrote:
[...]

Seems OpenMP has done so for vectorization, and pthreads for multithreading. Why
does it have to be in the language syntax?

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/workshop/IWOMP2010/slides/Boehm-iwomp10.pdf

regards,
alexander.

 

[Nobody]

Yeah, how dare they try to add even more utility features to the
language! Who needs things like multithreading or vectorization?
In the good old days we coded directly in asm. Using pencil and paper.

It isn't just a question of desirability. There's also the question of
whether the end result is something which can only be implemented on
full-featured desktop/server platforms and only then by a team of a
hundred experienced, full-time developers.

 

[Rui Maciel]

How exactly do you expand the syntax of the language with third-party
components, idiot?

If you had read what I wrote, you would understand why your comment is
silly.

Again, don't be an idiot.


Rui Maciel

 

[Rui Maciel]

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/workshop/IWOMP2010/slides/Boehm-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

 

[Öö Tiib]

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?

 

[Rui Maciel]

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.

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?

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

 

[Öö Tiib]

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.

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.

 

[Nobody]

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.

 

[Öö Tiib]

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.

 

[Öö Tiib]

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.

 

[Rui Maciel]

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.

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

Yet another C API.
Irrelevant.



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.

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

 

[Rui Maciel]

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

 

[Ian Collins]

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?