C++14: Papers

Discussion in 'C++' started by Rui Maciel, Apr 5, 2013.

  1. Rui Maciel

    Rui Maciel Guest

    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
    Rui Maciel, Apr 5, 2013
    #1
    1. Advertising

  2. Rui Maciel

    ?? Tiib Guest

    On Sunday, 7 April 2013 02:44:59 UTC+3, Leigh Johnston wrote:
    > 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.
    ?? Tiib, Apr 7, 2013
    #2
    1. Advertising

  3. Rui Maciel

    Stefan Ram Guest

    ?? Tiib <> writes:
    >On Sunday, 7 April 2013 02:44:59 UTC+3, Leigh Johnston wrote:
    >>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.


    See also

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

    (published 2003-09-02).
    Stefan Ram, Apr 7, 2013
    #3
  4. Rui Maciel <> writes:

    > 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.
    Alain Ketterlin, Apr 7, 2013
    #4
  5. Rui Maciel

    Rui Maciel Guest

    Alain Ketterlin wrote:

    > 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, Apr 7, 2013
    #5
  6. Rui Maciel

    Rui Maciel Guest

    Juha Nieminen wrote:

    > 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
    Rui Maciel, Apr 7, 2013
    #6
  7. 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.
    88888 Dihedral, Apr 7, 2013
    #7
  8. Alexander Terekhov, Apr 8, 2013
    #8
  9. Rui Maciel

    Nobody Guest

    On Sun, 07 Apr 2013 09:38:06 +0000, Juha Nieminen wrote:

    > Rui Maciel <> wrote:
    >> 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.

    >
    > 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.
    Nobody, Apr 8, 2013
    #9
  10. Rui Maciel

    Rui Maciel Guest

    Juha Nieminen wrote:

    > 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, Apr 8, 2013
    #10
  11. Rui Maciel

    Rui Maciel Guest

    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/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
    Rui Maciel, Apr 8, 2013
    #11
  12. Rui Maciel

    Öö Tiib Guest

    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/workshop/IWOMP2010/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".

    > 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?
    Öö Tiib, Apr 8, 2013
    #12
  13. Rui Maciel

    Rui Maciel Guest

    Öö 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/workshop/IWOMP2010/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
    Rui Maciel, Apr 9, 2013
    #13
  14. Rui Maciel

    Öö Tiib Guest

    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.
    Öö Tiib, Apr 9, 2013
    #14
  15. Rui Maciel

    Nobody Guest

    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.
    Nobody, Apr 9, 2013
    #15
  16. Rui Maciel

    Öö Tiib Guest

    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.
    Öö Tiib, Apr 9, 2013
    #16
  17. Rui Maciel

    Öö Tiib Guest

    On Tuesday, 9 April 2013 17:51:46 UTC+3, Scott Lurndal wrote:
    > =?ISO-8859-1?Q?=D6=F6_Tiib?= <> 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.
    Öö Tiib, Apr 9, 2013
    #17
  18. Rui Maciel

    Rui Maciel Guest

    Öö 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
    Rui Maciel, Apr 9, 2013
    #18
  19. Rui Maciel

    Rui Maciel Guest

    Öö 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
    Rui Maciel, Apr 9, 2013
    #19
  20. Rui Maciel

    Ian Collins Guest

    Öö 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
    Ian Collins, Apr 9, 2013
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. J. Bhasker

    DesignCon 2004 Call for Papers

    J. Bhasker, Aug 5, 2003, in forum: VHDL
    Replies:
    0
    Views:
    1,049
    J. Bhasker
    Aug 5, 2003
  2. INFO

    call for papers

    INFO, Aug 20, 2003, in forum: VHDL
    Replies:
    0
    Views:
    1,028
  3. INFO

    Final Call for Papers

    INFO, Oct 29, 2003, in forum: VHDL
    Replies:
    0
    Views:
    501
  4. shuchen.
    Replies:
    0
    Views:
    428
    shuchen.
    Nov 29, 2007
  5. Kostas I.
    Replies:
    0
    Views:
    446
    Kostas I.
    Nov 29, 2007
Loading...

Share This Page