7 ms·

C++ Standards Committee Meeting in Rapperswil, June 2014

72 points by dochtman 12y ago

r-s 12y ago
Great Write Up. There is a ton of information packed in there. C++17 looks like it will be a major improvement like C++11 was. Very much looking forward to Modules. The (elem : range) proposal seen here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n385... I'm really looking forward to as well. I wish it could have been in C++14. STL (the guy) is right when he says (auto elem : range) is very tempting. Its so easy for a novice user to not understand they are making a ton of potentially (and likely) unneeded copies. Also in code review its quite common, to see (const auto &elem : range) when it should be (const auto &&elem : range). After getting bogged down years ago in a crappy C++03 codebase I eased off C++ for a few years, but i must say, the language is really getting better. 5 years ago if you would have told me I would be looking forward to writing something major in C++ I would have laughed.
- cageface 12y ago
  I've had the same experience. Hadn't really touched C++ since the late 90's and had traumatic memories from those times but working in my own C++11 codebase recently has been both pleasant and surprisingly productive. The language is headed in the right direction but it's a big ship to steer.
  - pjmlp 12y ago
    I love the language, but mostly on personal projects. For the typical enterprise developer, at least in many of our projects, I am happy that we manly use other languages. I feel like crying every time I see C style coding in C++, with its usual set of security exploits.
    - shmerl 12y ago
      I'm pretty glad we use C++ in enterprise development (and extra glad we use C++11) ;) There are barely any other languages which can replace it yet. Rust is a good candidate.
      - pjmlp 12y ago
        Well I imagine you are lucky to work in an enterprise world where you get to pick skilled developers and are allowed to make proper use of C++. I have seen quite a few projects with developers that could barely handle VB, being thrown to C++ projects. Others where the style guide was making it, C compiled with a C++ compiler.
        shmerl 12y ago
        > I have seen quite a few projects with developers that could barely handle VB, being thrown to C++ projects. I'm not sure why would anyone do that, if they want to produce a quality result. Finding good programmers and engineers is hard though. > Others where the style guide was making it, C compiled with a C++ compiler. Yes, that can be pretty annoying, and I had to deal with maintaining such code in the past. Luckily this doesn't happen anymore in our development.
        pjmlp 12y ago
        > I'm not sure why would anyone do that, if they want to produce a quality result. Pay as less as possible for project costs.
      - cageface 12y ago
        You're lucky to be able to use such a recent standard in enterprise dev. Those shops tend to be pretty conservative in my experience. Where do you work?
        deleted 12y ago
        [deleted]
- StephanTLavavej 12y ago
  It took me some time to recognize the problem with range-for (after testing its implementation in VC 2012), and more time to work up the courage to write a Core Language proposal. I also wish next-gen range-for had gotten into C++14, but that's mostly a formality - compilers can (and often do) ship features as soon as they're voted into the Working Paper. Note that nothing's wrong with "const auto& elem", except that it prohibits modification. On the other hand, "const auto&& elem" will typically not compile (it'll insist on binding to rvalues, which only proxy iterators return).
  - r-s 12y ago
    First off, its Great to see you on HN! For the few of you who don't know, Stephan maintains Visual Studio's C++ Standard Library implementation and he is extremely well regarded in C++ circles. Thats of course right about const auto &&.. It won't work, I did mean (auto &&elem : range).
  - jzwinck 12y ago
    As I was reading through your "for (elem : range)" proposal I became quite anxious to know how adding const would be handled. I was hoping that "for (const elem : range)" would be added to mean "for (const auto& elem : range)" because I very often find myself within a non-const method having a non-const container but wanting to iterate with no chance of modifying it. I was at first relieved to see this topic addressed at the top of Q&A, then disappointed to see "Just do it the old way if you want const." I feel that we don't use const enough in C++, and making it easier (yet still clear) to use would be of significant benefit. If you agree, perhaps there is still time to support "for (const elem : range)" - it seems to me natural and no more disruptive than the rest of the proposal.
    - StephanTLavavej 12y ago
      I talked about this some more in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3994.htm http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n399... Q17. Many people have asked for such syntax, but I am wary of adding more complexity to the Core Language. Ultimately, I believe that this should be handled on the range side instead of the element side. What Evolution/Core needs to do is to fix the problem with nested temporaries in range-for loops - the problem (affecting both C++11's range-for and mine) is that range-for will keep temporary ranges alive if they're the topmost thing returned, but not if you have "const T& noop(const T&)" and you try to loop over noop(return_temporary_range()). They're aware of the problem, which is a start. If and when that's fixed, then what you want can be handled through library tech: "for (elem : as_const(range))".
- deleted 12y ago
  [deleted]
deleted 12y ago
[deleted]
cdi 12y ago
Making Cairo C API a C++ standard, through automatic conversion, looks all kinds of wrong to me. The result is not properly generified like Boost GIL, and it carries vaguely defined implementation details like for example font hinting style from freetype (not even cairo library itself). I hope this and the ABI proposal will never make it as the C++ TS or standard.
- deleted 12y ago
  [deleted]
jokoon 12y ago
(cheering) modules ! modules ! modules !
synthos 12y ago
Glad to see named parameters and introspection on the table
ape4 12y ago
The extern "abi" for an Application Binary Interface would be so useful.
en4bz 12y ago
Shameless plug for my implementation of the Executors & Schedulers TS: https://github.com/en4bz/executors https://github.com/en4bz/executors
- deleted 12y ago
  [deleted]
frozenport 12y ago
What is the motivation behind including Cairo?
- zanny 12y ago
  Herb wants new users to be able to draw graphics without using third party toolkits. It is not meant to be all encompassing, but if you need custom 2d it is a nice feature, albeit very out of scope of a standard library implementation.
  - pjmlp 12y ago
    It is pretty much in scope. We old timers remember the days when compilers came with graphics libraries. So why forcing everyone to jump through hurdles just to do some simple uses of 2D programming?
    - zanny 12y ago
      Because, I guess, Swing. Unless the standard compels implementations to use platform native windowing systems and theming engines (since you can't really leave it out if you want visual output) then its going to be an ugly mess. And, for example, a huge amount of Qt is just native theming on all its supported platforms.
      - pjmlp 12y ago
        The point is not replace WxWidgets, Qt or flavor of the month GUI framework. Plain simple 2D graphics like BGI, to allow any C++ beginner not to worry which bazillion libraries s/he needs to download to draw some colored squares.
cheepin 12y ago
The information seems pretty exciting, but I still don't feel like I have fully grasped the changes in C++11 yet. What are some good resources for getting up to speed with the latest and greatest C++?
- packetslave 12y ago
  Scott Meyers has an Introduction: http://www.artima.com/shop/overview_of_the_new_cpp http://www.artima.com/shop/overview_of_the_new_cpp He's also writing a new book that's available in Rough Cuts from O'Reilly that covers C++11/14: http://scottmeyers.blogspot.com/2014/06/effective-modern-c-status-report.html http://scottmeyers.blogspot.com/2014/06/effective-modern-c-s... and has given a talk covering some of the same ground: http://vimeo.com/97318797 http://vimeo.com/97318797 Herb Sutter has "Elements of Modern C++ Style": http://herbsutter.com/elements-of-modern-c-style/ http://herbsutter.com/elements-of-modern-c-style/ and has given several talks, such as http://channel9.msdn.com/Events/Build/2014/2-661 http://channel9.msdn.com/Events/Build/2014/2-661 Finally, you can't really beat Stroustrup's book: http://www.amazon.com/The-Programming-Language-4th-Edition/dp/0321563840 http://www.amazon.com/The-Programming-Language-4th-Edition/d...
- SupremumLimit 12y ago
  If you already know C++ and just want to get up to speed with C++11/14 features, I wrote several books aimed at specific feature sets supported by different compilers (GCC, Clang, MSVC). Check them out at http://cpprocks.com http://cpprocks.com.
_kst_ 12y ago
"Modules is, in my opinion, one of the most sorely needed features in C++. They have the potential of increasing compile times by an order of magnitude or more, thus bringing compile-time performance more in line with more modern languages, ..." Presumably that should be "decreasing", not "increasing" (or "compilation speed" rather than "compile times").

72 points by dochtman 12y ago

r-s 12y ago

Great Write Up. There is a ton of information packed in there. C++17 looks like it will be a major improvement like C++11 was. Very much looking forward to Modules. The (elem : range) proposal seen here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n385... I'm really looking forward to as well. I wish it could have been in C++14. STL (the guy) is right when he says (auto elem : range) is very tempting. Its so easy for a novice user to not understand they are making a ton of potentially (and likely) unneeded copies. Also in code review its quite common, to see (const auto &elem : range) when it should be (const auto &&elem : range). After getting bogged down years ago in a crappy C++03 codebase I eased off C++ for a few years, but i must say, the language is really getting better. 5 years ago if you would have told me I would be looking forward to writing something major in C++ I would have laughed.

cageface 12y ago
I've had the same experience. Hadn't really touched C++ since the late 90's and had traumatic memories from those times but working in my own C++11 codebase recently has been both pleasant and surprisingly productive. The language is headed in the right direction but it's a big ship to steer.
- pjmlp 12y ago
  I love the language, but mostly on personal projects. For the typical enterprise developer, at least in many of our projects, I am happy that we manly use other languages. I feel like crying every time I see C style coding in C++, with its usual set of security exploits.
  - shmerl 12y ago
    I'm pretty glad we use C++ in enterprise development (and extra glad we use C++11) ;) There are barely any other languages which can replace it yet. Rust is a good candidate.
    - pjmlp 12y ago
      Well I imagine you are lucky to work in an enterprise world where you get to pick skilled developers and are allowed to make proper use of C++. I have seen quite a few projects with developers that could barely handle VB, being thrown to C++ projects. Others where the style guide was making it, C compiled with a C++ compiler.
      - shmerl 12y ago
        > I have seen quite a few projects with developers that could barely handle VB, being thrown to C++ projects. I'm not sure why would anyone do that, if they want to produce a quality result. Finding good programmers and engineers is hard though. > Others where the style guide was making it, C compiled with a C++ compiler. Yes, that can be pretty annoying, and I had to deal with maintaining such code in the past. Luckily this doesn't happen anymore in our development.
        pjmlp 12y ago
        > I'm not sure why would anyone do that, if they want to produce a quality result. Pay as less as possible for project costs.
    - cageface 12y ago
      You're lucky to be able to use such a recent standard in enterprise dev. Those shops tend to be pretty conservative in my experience. Where do you work?
      - deleted 12y ago
        [deleted]
StephanTLavavej 12y ago
It took me some time to recognize the problem with range-for (after testing its implementation in VC 2012), and more time to work up the courage to write a Core Language proposal. I also wish next-gen range-for had gotten into C++14, but that's mostly a formality - compilers can (and often do) ship features as soon as they're voted into the Working Paper. Note that nothing's wrong with "const auto& elem", except that it prohibits modification. On the other hand, "const auto&& elem" will typically not compile (it'll insist on binding to rvalues, which only proxy iterators return).
- r-s 12y ago
  First off, its Great to see you on HN! For the few of you who don't know, Stephan maintains Visual Studio's C++ Standard Library implementation and he is extremely well regarded in C++ circles. Thats of course right about const auto &&.. It won't work, I did mean (auto &&elem : range).
- jzwinck 12y ago
  As I was reading through your "for (elem : range)" proposal I became quite anxious to know how adding const would be handled. I was hoping that "for (const elem : range)" would be added to mean "for (const auto& elem : range)" because I very often find myself within a non-const method having a non-const container but wanting to iterate with no chance of modifying it. I was at first relieved to see this topic addressed at the top of Q&A, then disappointed to see "Just do it the old way if you want const." I feel that we don't use const enough in C++, and making it easier (yet still clear) to use would be of significant benefit. If you agree, perhaps there is still time to support "for (const elem : range)" - it seems to me natural and no more disruptive than the rest of the proposal.
  - StephanTLavavej 12y ago
    I talked about this some more in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3994.htm http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n399... Q17. Many people have asked for such syntax, but I am wary of adding more complexity to the Core Language. Ultimately, I believe that this should be handled on the range side instead of the element side. What Evolution/Core needs to do is to fix the problem with nested temporaries in range-for loops - the problem (affecting both C++11's range-for and mine) is that range-for will keep temporary ranges alive if they're the topmost thing returned, but not if you have "const T& noop(const T&)" and you try to loop over noop(return_temporary_range()). They're aware of the problem, which is a start. If and when that's fixed, then what you want can be handled through library tech: "for (elem : as_const(range))".
deleted 12y ago
[deleted]

deleted 12y ago

[deleted]

cdi 12y ago

Making Cairo C API a C++ standard, through automatic conversion, looks all kinds of wrong to me. The result is not properly generified like Boost GIL, and it carries vaguely defined implementation details like for example font hinting style from freetype (not even cairo library itself). I hope this and the ABI proposal will never make it as the C++ TS or standard.

deleted 12y ago
[deleted]

jokoon 12y ago

(cheering) modules ! modules ! modules !

synthos 12y ago

Glad to see named parameters and introspection on the table

ape4 12y ago

The extern "abi" for an Application Binary Interface would be so useful.

en4bz 12y ago

Shameless plug for my implementation of the Executors & Schedulers TS: https://github.com/en4bz/executors https://github.com/en4bz/executors

deleted 12y ago
[deleted]

frozenport 12y ago

What is the motivation behind including Cairo?

zanny 12y ago
Herb wants new users to be able to draw graphics without using third party toolkits. It is not meant to be all encompassing, but if you need custom 2d it is a nice feature, albeit very out of scope of a standard library implementation.
- pjmlp 12y ago
  It is pretty much in scope. We old timers remember the days when compilers came with graphics libraries. So why forcing everyone to jump through hurdles just to do some simple uses of 2D programming?
  - zanny 12y ago
    Because, I guess, Swing. Unless the standard compels implementations to use platform native windowing systems and theming engines (since you can't really leave it out if you want visual output) then its going to be an ugly mess. And, for example, a huge amount of Qt is just native theming on all its supported platforms.
    - pjmlp 12y ago
      The point is not replace WxWidgets, Qt or flavor of the month GUI framework. Plain simple 2D graphics like BGI, to allow any C++ beginner not to worry which bazillion libraries s/he needs to download to draw some colored squares.

cheepin 12y ago

The information seems pretty exciting, but I still don't feel like I have fully grasped the changes in C++11 yet. What are some good resources for getting up to speed with the latest and greatest C++?

packetslave 12y ago
Scott Meyers has an Introduction: http://www.artima.com/shop/overview_of_the_new_cpp http://www.artima.com/shop/overview_of_the_new_cpp He's also writing a new book that's available in Rough Cuts from O'Reilly that covers C++11/14: http://scottmeyers.blogspot.com/2014/06/effective-modern-c-status-report.html http://scottmeyers.blogspot.com/2014/06/effective-modern-c-s... and has given a talk covering some of the same ground: http://vimeo.com/97318797 http://vimeo.com/97318797 Herb Sutter has "Elements of Modern C++ Style": http://herbsutter.com/elements-of-modern-c-style/ http://herbsutter.com/elements-of-modern-c-style/ and has given several talks, such as http://channel9.msdn.com/Events/Build/2014/2-661 http://channel9.msdn.com/Events/Build/2014/2-661 Finally, you can't really beat Stroustrup's book: http://www.amazon.com/The-Programming-Language-4th-Edition/dp/0321563840 http://www.amazon.com/The-Programming-Language-4th-Edition/d...
SupremumLimit 12y ago
If you already know C++ and just want to get up to speed with C++11/14 features, I wrote several books aimed at specific feature sets supported by different compilers (GCC, Clang, MSVC). Check them out at http://cpprocks.com http://cpprocks.com.

_kst_ 12y ago

"Modules is, in my opinion, one of the most sorely needed features in C++. They have the potential of increasing compile times by an order of magnitude or more, thus bringing compile-time performance more in line with more modern languages, ..." Presumably that should be "decreasing", not "increasing" (or "compilation speed" rather than "compile times").