15 ms·

Why the C++ standard ships every three years

229 points by frostmatthew 7y ago

nayuki 7y ago
This is similar to Java's transition from a feature-based release model to a time-based release model. The first rapid release was Java 10 in March 2018.
Rexxar 7y ago
The 1998-2011 gap has made a lot of damage to c++ in term of "market share". I think it's necessary to avoid something similar happen again.
- bogwog 7y ago
  Alternatively, releasing new features every 3 years to an already-bloated language could cause even worse damage.
  - arcticbull 7y ago
    This. They keep adding half-finished features apparently for the sake of releasing every 3 years. Move types that may not move (std::move is just a cast / suggestion that if taken leaves the receiver in an indeterminate, useable state), pattern matching that isn't (std::variant). Frankly, I wish they'd stop.
  - hellofunk 7y ago
    This suggests you aren't aware of the many huge benefits that have come from introducing modern features that other languages have. C++ since 2011 is quite a different language to what it was before, and this is hardly a bad thing. So many of the challenges of writing C++ were significantly simplified with the introduction of lambdas, smart pointers, and threading primitives.
    - arcticbull 7y ago
      The issue isn't that it gets new features it's that they're half-assed because you can't impose new restrictions on old code. The power of these features in modern languages comes from their ability to protect you from yourself. That has more to do with what you can't do than what you can. Bolting more legs onto C++ doesn't protect you from anything, it just increases the surface area of the language. They haven't introduced the features other language have, they've introduced poor rip-offs that fail to work as one might expect having worked in any of the other languages they're derived from. The problem is it's not different than it used to be, the cracked foundations are exactly the same as they've always been always been but there's a bigger and more complicated house on them. C++ is starting to feel like the Winchester mystery house.
      - jdsully 7y ago
        The C++ philosophy is not about protecting you from yourself. Its about allowing you to express your idea in as low or high level terms as you require. This lets you write a highly optimized tight loop and then abstractly describe less performance sensitive parts. In the past it was thought that people would use safer high level languages and then drop down to C for performance. That vision just doesn’t seem to work out in practice - except at the cross process level. The trade off to this is language complexity. If you want a simple language C++ isn’t for you - and that’s OK.
        marcosdumay 7y ago
        > That vision just doesn’t seem to work out in practice Well, about half of the Python ecosystem seems to disagree.
        jdsully 7y ago
        Python is likely the best example of this working, however even in Python the boundaries between high and low performance sections are very formal. It's a lot simpler to go in and optimize a piece of code the profiler has pointed out with C++. I really don't understand the animosity non-C++ developers have towards the language. You can still use Python, Rust, etc if you want. Nobody wants to force you to use C++.
- 0815test 7y ago
  > The 1998-2011 gap has made a lot of damage to c++ in term of "market share". Not really... Rust 1.0 is from mid-2015, well past 2011.
  - zone411 7y ago
    Not saying Rust is bad by any means, but it has about 20 times smaller market share than C++ according https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ and 11 times smaller according to http://pypl.github.io/PYPL.html http://pypl.github.io/PYPL.html.
    - tdsamardzhiev 7y ago
      Tiobe and PYPL are not market share indices, they're googling indices. I'd be very surprised if Rust really has 1/20 of C++'s market share as in number of companies and programmers that use it.
      - zone411 7y ago
        True, they are not great indices. Indeed.com shows me around 40 times more job openings for C++ and StackOverflow shows 14 times more C++ questions this year. Github shows 12 times more commits in C++ this year. None of these are great by themselves but a guess of around 20x seems reasonable.
        AsyncAwait 7y ago
        Rust only reached 1.0 status in 2015, keep that in mind.
- asveikau 7y ago
  I kind of see it differently, that the 98 and 03 standards had a lot of mileage and as necessary as the more recent changes may have been, people felt the old standard pretty usable for a long time. C++11 was a really big shakeup. In contrast, C11 isn't a major difference over C99. Sometimes I read about the rapidly evolving modern C++ and I wonder if they are moving too fast, as large chunks of the community have not even caught up with what is already there.
  - fredophile 7y ago
    I think it's worth noting that up until 2010 C++11 was known as C++0x. Everyone knew it was coming. You could get a good idea of what it was going to contain by looking at things like Boost. C++03 wasn't some abnormally stable version, it just took a longer than expected time to write the standard for C++11.
    - asveikau 7y ago
      Yes I remember. Also, by the time c++0x seemed "right around the corner" for several years, a lot of the library features like smart pointers were already common practice, the standard just, well, standardized them. It was possible and common to have pretty "modern" styles in c++03, you'd just have to do without lamdbas etc. and be using less of the 'std' namespace.
      - humanrebar 7y ago
        Strong disagree. The nonsense needed for "variadic" templates in C++03 isn't "just do without lambdas". You basically have to walk on eggshells to get the equivalent of unique_ptr. Not having to type std::vector<SomeTypeName, WhateverBuffer>::const_iterator changes the way you write code, too. The stronger guarantees on copy elision lets you skip return by reference nonsense more aggressively.
  - pingyong 7y ago
    > Sometimes I read about the rapidly evolving modern C++ and I wonder if they are moving too fast Sure there are a lot of small accumulating changes, but they can easily be caught up on by reading the documentation when you actually need those features. On the other hand, I've been waiting for modules, concepts and networking literally since 2012 - and I only started using C++ in 2011, with around 2 years of experience in C. I don't think anyone is moving too fast in that direction. Edit: I still remember the graphic from the committee/Herb, which showed 2014 for the networking TS, and 2017 for concepts/modules. The "networking TS" then ended up being like one .pdf file with functions for LE/BE conversion, and well obviously concepts and modules aren't in C++17. (Neither is any actual networking.) And while concepts look to be on a fairly good path for C++20, I'm going to be very surprised (and happy) if they'd manage to get modules in, too.
- gurkendoktor 7y ago
  This was also the timeframe in which boost::shared_ptr, boost::filesystem, boost::variant, and boost::thread have matured to the point where they could be imported into the standard, and when people discovered all these dark corners like SFINAE. The C++ language was frozen, but the C++ ecosystem never really stopped moving. I actually think that the lack of a popular cross-platform package manager is much more harmful. It's amazing what GitHub and CocoaPods did to the niche Objective-C community in such a short time, while C++ still isn't a language where people celebrate cool open source libraries.
  - prewett 7y ago
    Maybe this is my old skool C++ bias, but every time I’ve inherited a project using CocoaPods I’ve found the code to be of poor quality and the Pods to be either corporate libraries (third-party analytics, crash logs, etc.) or wrapper code of questionable quality that hasn’t really provided any benefits over a couple of hours of writing some simpler code yourself. And you yourself mentioned Boost, which is kind a code ecosystem of its own, all open source. But I think C++ has problems with libraries because it’s such a pain to add a library to C++. If the library is C++, you can’t ship a binary and header file like with a C library because the ABI needs to match, so you have to compile the thing. And then people like Boost do template wizardry that consumes compile time to produce magic, but some developers value the compilation speed over magic, so they don’t use anything heavily templated. But if it isn’t templated, it likely could be written in C if it isn’t a big UI framework, and be available for everyone. So, no C++ library ecosystem.
    - gurkendoktor 7y ago
      Swift had the same ABI issues as C++, but when most packages ship as source code, it's not that big of an problem. This is precisely the thing that a standardized package manager can establish. I think it's a bit of a catch-22. C++ projects are so rare and monolithic that reinventing the wheel every now and then. But maybe more (smaller) projects would happen in C++ if there were polished libraries for reasonably common requirements like sending a SOAP request.
NTDF9 7y ago
Glad to have left C++ behind. I thank it for making me a better software engineer but I don't think I want to work with core dumps for the rest of my life.
- 0815test 7y ago
  > I thank it for making me a better software engineer It's especially nice that Rust has kept this basic attitude from C/C++ and in fact strengthened it a lot and aligned it with modern trends, even as it got rid of the annoying "core dumped" part almost in its entirety. (The latest tagline of Rust is "A language empowering everyone to build reliable and efficient software." Do notice the everyone part, and especially the empowering bit - as opposed to letting even novice developers hobble themselves with substandard, bootcamp-level software-dev practices!)
  - jimmaswell 7y ago
    I wish Rust would have kept saner OOP style classes from C++ instead of this bizarre trait stuff. The whole language feels like everything is just different for the sake of being different. Why is it "fn blah (x -> int.. -> int" or whatever when the rest of the tokens seem designed to save keystrokes at the cost of readability? Everyone is used to "int x(int y..". I've learned it some and the concepts around memory ownership and everything are good but the syntax is needlessly weird and annoying.
    - Retra 7y ago
      Rust is not based on C++. People coming from Haskell/ML aren't used to C's backwards type declarations, and that's why they're not in Rust; the people who make Rust have experience with more than just C/C++. So it's not different for the sake of being different, it is actually trying to be similar ... just not similar to C.
      - jimmaswell 7y ago
        Similar to languages much fewer people use, instead of languages more commonly used as systems languages which Rust is meant to be.
steveklabnik 7y ago
I’m a huge fan of this strategy; we use it with Rust, for virtually identical reasons. Ruby also ships each Christmas.
- mehrdadn 7y ago
  Can't speak for Rust, and I imagine it makes more sense for them since it's a young language, but I wish the C++ folks would chill a bit and take their time a little more; it's getting kind of ridiculous. They don't need to move fast and break things (which they literally have; see e.g. result_of and invoke_result). By the time the tooling across various platforms has finally had a chance to take a breath, they've already got the next version of the standard out, and it's getting hard to keep up with all their changes. I feel there's a better balance between the 13 years ('98->'11; '03 wasn't really a new standard) and the 3 years we have now. Maybe every 5-6 years?
  - usefulcat 7y ago
    So maybe choose not to use the very newest features? That's what I've always done and it's worked quite well.
    - mehrdadn 7y ago
      That's exactly what I do on my end, but it's more than annoying when I have to deal with other projects and I suddenly can't even compile them anymore until I upgrade my toolchain and learn what's basically a new language.
  - steveklabnik 7y ago
    I don’t think that making the cycle time longer helps; I think making it shorter helps. There’s less pressure to put something in a specific release when they happen less frequently. You can, counter-intuitively, take your time. I know less about the exact details, but I also think that having something to play with helps; I believe that this is what’s going on with with the move towards more TSes before shipping spec text, right? Being able to try things out in nightly helps us a lot.
cousin_it 7y ago
This sounds like a great idea, can't believe I didn't see it earlier. Maybe I should adopt it for my personal projects (software, music, etc): pick a regular release schedule and stick to it, even if it means releasing less feature-rich stuff. Does anyone have experience with this approach?
- aninteger 7y ago
  OpenBSD does (2 releases every year, approximately 6 months apart).
- skummetmaelk 7y ago
  This is sort of what scrum does isn't it? Release every cycle no matter what was completed. Whatever was not completed goes back into the backlog and potentially into the next cycle.
  - Quekid5 7y ago
    Ideally, yes. In practice there are often complications, however. Usually, it's just office politics: Those cases can be quite difficult -- you really need buy-in and TRUST from management (and have to do the right political plays, etc.) to be able to cut through the bullshit and "allow" feature slips. Books have been written about this scenario. Rarely, deadlines are imposed by Real Politics, aka: law... which can make for Interesting Times. This can range from "quite difficult" to "too easy!", so I have no advice here.
  - saagarjha 7y ago
    > Release every cycle no matter what was completed. What happens when your software is in a broken state that's worse than what you had before?
    - justinator 7y ago
      I guess the keyword is, "completed". If something is broken, I doubt it would be in master, or the team has done something terribly strange. Or they should be nicer to QA ;)
freyr 7y ago
Considering that C++ has evolved a lot over the years (and grown quite large), what are good resources for a programmer to get started with the language in 2019? I've heard Accelerated C++ is a good introduction, but it's quite old at this point. Would Accelerated C++ followed by Effective Modern C++ bring someone up to speed with modern C++? Is there a single book or online resource that would service this purpose better?
- umanwizard 7y ago
  “A tour of C++” (second edition) by Stroustrup is a great starting point.
- colmvp 7y ago
  I've been learning C++ for the first time starting in 2019. I used Marc Gregoire's Professional C++ which has a version that was published last year and includes C++17, alongside Scott Meyer's line of books, and watching a variety of YouTube videos (e.g. Jason Turner, CPP talks...)
  - ExtremisAndy 7y ago
    I second the recommendation of Professional C++. I am just a self-taught programmer, and to be quite honest, felt I was getting in a bit over my head by buying a book aimed at professionals. But I have found the material to be perfectly accessible even for someone without a CS degree, and I am now using C++ for my personal projects. I cannot recommend that book highly enough. Just my $.02
- bvod 7y ago
  C++ is deep and nuanced, so reading books will help structure your learning. I've found Scott Meyer's books to be great for starting out. Those will give you a fantastic foundation, from which you can dive deeper. Those and others have added significantly to my ability to write clean and maintainable software. This SO post is a great guide for where to look: https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list https://stackoverflow.com/questions/388242/the-definitive-c-...
- 7y ago
abductee_hg 7y ago
as long as basic things like __alignment__ are still fundamentally broken I simply do not care about the syntax. (I mean it doesn't get anything more basic than this, no?)
- edflsafoiewq 7y ago
  What's wrong with alignment?
  - abductee_hg 7y ago
    well there is this: #ifdef _MSC_VER __declspec( align(16) ) struct float4 { float v[4]; }; #else struct float4 { float v[4]; } __attribute__ ((aligned(16))); #endif but the main problem ist tthat alignment is _not_ part of the typing system. ( alignas vs alignof ) butt, to put it more general: 90% of your performance is in memory access and compilers are rubbish optimizing those, they are however getting increasingly good at the 10%. see also https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc for realworld examples/exploration
    - account42 7y ago
      > well there is this: #ifdef _MSC_VER __declspec( align(16) ) struct float4 { float v[4]; }; #else struct float4 { float v[4]; } __attribute__ ((aligned(16))); #endif I don't understand what you are trying to say here? Why not just use struct alignas(16) float4 { float v[4]; }; You can even put both __declspec( align(16) ) and __attribute__ ((aligned(16))) in the same place if you want to have a fallback for older compilers.
carlsborg 7y ago
C++ needs to merge with Python to create the uber-language: Python for rapid development, and drop to C++ for performance. Like Cython, but with native integration.
- AdieuToLogic 7y ago
  Boost.Python[0] is not an "official merging" of C++ and Python, but might be something of interest to you. On that page is the link "Building Hybrid Systems with Boost.Python", which is an intro article on it. 0 - https://www.boost.org/doc/libs/1_70_0/libs/python/doc/html/index.html https://www.boost.org/doc/libs/1_70_0/libs/python/doc/html/i...
- keerthiko 7y ago
  Please don't because you know we'll end up with a frankenstein language with the cons of both rather than the pros of both.
- readams 7y ago
  What stops you from doing this now? This is pretty much how Python works currently when you need performance.
  - carlsborg 7y ago
    For the most part, today's solutions let you write python modules in C/C++. So your core app is in python. I am thinking of the scenario where your core is in C++ and extendable in python for the business logic -- where the core can be a trading system engine, or a webserver for example. The rationale is python serves the algos/data scientists/quants use case really well, and C++ does the "engine" part of things really well.
- fredophile 7y ago
  No. In my opinion, one of the biggest benefits of Python is that the code looks consistent. There is a single "correct" way to do things. Merging it with C++ would remove this. I use both C++ and Python on a regular basis.
- 7y ago
hellofunk 7y ago
So, in 2019, if you want the execution speed and efficiency of C++, high level features, without the complexity of C++ or rust, how about Nim??
- vips7L 7y ago
  Isn't nim garbage collected? The better alternative is probably Zig.
deleted 7y ago
[deleted]
corysama 7y ago
I’m sure the committee has thought about this 1000x as much as me. But, I wish they would go further and release every year. IMHO, that would relieve most of the pressure to push out features that aren’t fully baked. 3 more years is a long time to wait if you’ve already been working on something for several years. 1 more year, when you know you could use “maybe a couple more months” (likely 8 in practice), not so bad.
- dwaite 7y ago
  The final review process (for ISO standards) is most probably the bottleneck there.
  - motajaxxer 7y ago
    ISO generally allows only 5 year cycle. 3 years for C++ is a special case. Furthermore, the bureaucratic overhead will dominate the proceedings then (not unlike thread thrashing).

229 points by frostmatthew 7y ago

This is similar to Java's transition from a feature-based release model to a time-based release model. The first rapid release was Java 10 in March 2018.

Rexxar 7y ago

The 1998-2011 gap has made a lot of damage to c++ in term of "market share". I think it's necessary to avoid something similar happen again.

bogwog 7y ago
Alternatively, releasing new features every 3 years to an already-bloated language could cause even worse damage.
- arcticbull 7y ago
  This. They keep adding half-finished features apparently for the sake of releasing every 3 years. Move types that may not move (std::move is just a cast / suggestion that if taken leaves the receiver in an indeterminate, useable state), pattern matching that isn't (std::variant). Frankly, I wish they'd stop.
- hellofunk 7y ago
  This suggests you aren't aware of the many huge benefits that have come from introducing modern features that other languages have. C++ since 2011 is quite a different language to what it was before, and this is hardly a bad thing. So many of the challenges of writing C++ were significantly simplified with the introduction of lambdas, smart pointers, and threading primitives.
  - arcticbull 7y ago
    The issue isn't that it gets new features it's that they're half-assed because you can't impose new restrictions on old code. The power of these features in modern languages comes from their ability to protect you from yourself. That has more to do with what you can't do than what you can. Bolting more legs onto C++ doesn't protect you from anything, it just increases the surface area of the language. They haven't introduced the features other language have, they've introduced poor rip-offs that fail to work as one might expect having worked in any of the other languages they're derived from. The problem is it's not different than it used to be, the cracked foundations are exactly the same as they've always been always been but there's a bigger and more complicated house on them. C++ is starting to feel like the Winchester mystery house.
    - jdsully 7y ago
      The C++ philosophy is not about protecting you from yourself. Its about allowing you to express your idea in as low or high level terms as you require. This lets you write a highly optimized tight loop and then abstractly describe less performance sensitive parts. In the past it was thought that people would use safer high level languages and then drop down to C for performance. That vision just doesn’t seem to work out in practice - except at the cross process level. The trade off to this is language complexity. If you want a simple language C++ isn’t for you - and that’s OK.
      - marcosdumay 7y ago
        > That vision just doesn’t seem to work out in practice Well, about half of the Python ecosystem seems to disagree.
        jdsully 7y ago
        Python is likely the best example of this working, however even in Python the boundaries between high and low performance sections are very formal. It's a lot simpler to go in and optimize a piece of code the profiler has pointed out with C++. I really don't understand the animosity non-C++ developers have towards the language. You can still use Python, Rust, etc if you want. Nobody wants to force you to use C++.
0815test 7y ago
> The 1998-2011 gap has made a lot of damage to c++ in term of "market share". Not really... Rust 1.0 is from mid-2015, well past 2011.
- zone411 7y ago
  Not saying Rust is bad by any means, but it has about 20 times smaller market share than C++ according https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ and 11 times smaller according to http://pypl.github.io/PYPL.html http://pypl.github.io/PYPL.html.
  - tdsamardzhiev 7y ago
    Tiobe and PYPL are not market share indices, they're googling indices. I'd be very surprised if Rust really has 1/20 of C++'s market share as in number of companies and programmers that use it.
    - zone411 7y ago
      True, they are not great indices. Indeed.com shows me around 40 times more job openings for C++ and StackOverflow shows 14 times more C++ questions this year. Github shows 12 times more commits in C++ this year. None of these are great by themselves but a guess of around 20x seems reasonable.
      - AsyncAwait 7y ago
        Rust only reached 1.0 status in 2015, keep that in mind.
asveikau 7y ago
I kind of see it differently, that the 98 and 03 standards had a lot of mileage and as necessary as the more recent changes may have been, people felt the old standard pretty usable for a long time. C++11 was a really big shakeup. In contrast, C11 isn't a major difference over C99. Sometimes I read about the rapidly evolving modern C++ and I wonder if they are moving too fast, as large chunks of the community have not even caught up with what is already there.
- fredophile 7y ago
  I think it's worth noting that up until 2010 C++11 was known as C++0x. Everyone knew it was coming. You could get a good idea of what it was going to contain by looking at things like Boost. C++03 wasn't some abnormally stable version, it just took a longer than expected time to write the standard for C++11.
  - asveikau 7y ago
    Yes I remember. Also, by the time c++0x seemed "right around the corner" for several years, a lot of the library features like smart pointers were already common practice, the standard just, well, standardized them. It was possible and common to have pretty "modern" styles in c++03, you'd just have to do without lamdbas etc. and be using less of the 'std' namespace.
    - humanrebar 7y ago
      Strong disagree. The nonsense needed for "variadic" templates in C++03 isn't "just do without lambdas". You basically have to walk on eggshells to get the equivalent of unique_ptr. Not having to type std::vector<SomeTypeName, WhateverBuffer>::const_iterator changes the way you write code, too. The stronger guarantees on copy elision lets you skip return by reference nonsense more aggressively.
- pingyong 7y ago
  > Sometimes I read about the rapidly evolving modern C++ and I wonder if they are moving too fast Sure there are a lot of small accumulating changes, but they can easily be caught up on by reading the documentation when you actually need those features. On the other hand, I've been waiting for modules, concepts and networking literally since 2012 - and I only started using C++ in 2011, with around 2 years of experience in C. I don't think anyone is moving too fast in that direction. Edit: I still remember the graphic from the committee/Herb, which showed 2014 for the networking TS, and 2017 for concepts/modules. The "networking TS" then ended up being like one .pdf file with functions for LE/BE conversion, and well obviously concepts and modules aren't in C++17. (Neither is any actual networking.) And while concepts look to be on a fairly good path for C++20, I'm going to be very surprised (and happy) if they'd manage to get modules in, too.
gurkendoktor 7y ago
This was also the timeframe in which boost::shared_ptr, boost::filesystem, boost::variant, and boost::thread have matured to the point where they could be imported into the standard, and when people discovered all these dark corners like SFINAE. The C++ language was frozen, but the C++ ecosystem never really stopped moving. I actually think that the lack of a popular cross-platform package manager is much more harmful. It's amazing what GitHub and CocoaPods did to the niche Objective-C community in such a short time, while C++ still isn't a language where people celebrate cool open source libraries.
- prewett 7y ago
  Maybe this is my old skool C++ bias, but every time I’ve inherited a project using CocoaPods I’ve found the code to be of poor quality and the Pods to be either corporate libraries (third-party analytics, crash logs, etc.) or wrapper code of questionable quality that hasn’t really provided any benefits over a couple of hours of writing some simpler code yourself. And you yourself mentioned Boost, which is kind a code ecosystem of its own, all open source. But I think C++ has problems with libraries because it’s such a pain to add a library to C++. If the library is C++, you can’t ship a binary and header file like with a C library because the ABI needs to match, so you have to compile the thing. And then people like Boost do template wizardry that consumes compile time to produce magic, but some developers value the compilation speed over magic, so they don’t use anything heavily templated. But if it isn’t templated, it likely could be written in C if it isn’t a big UI framework, and be available for everyone. So, no C++ library ecosystem.
  - gurkendoktor 7y ago
    Swift had the same ABI issues as C++, but when most packages ship as source code, it's not that big of an problem. This is precisely the thing that a standardized package manager can establish. I think it's a bit of a catch-22. C++ projects are so rare and monolithic that reinventing the wheel every now and then. But maybe more (smaller) projects would happen in C++ if there were polished libraries for reasonably common requirements like sending a SOAP request.

NTDF9 7y ago

Glad to have left C++ behind. I thank it for making me a better software engineer but I don't think I want to work with core dumps for the rest of my life.

0815test 7y ago
> I thank it for making me a better software engineer It's especially nice that Rust has kept this basic attitude from C/C++ and in fact strengthened it a lot and aligned it with modern trends, even as it got rid of the annoying "core dumped" part almost in its entirety. (The latest tagline of Rust is "A language empowering everyone to build reliable and efficient software." Do notice the everyone part, and especially the empowering bit - as opposed to letting even novice developers hobble themselves with substandard, bootcamp-level software-dev practices!)
- jimmaswell 7y ago
  I wish Rust would have kept saner OOP style classes from C++ instead of this bizarre trait stuff. The whole language feels like everything is just different for the sake of being different. Why is it "fn blah (x -> int.. -> int" or whatever when the rest of the tokens seem designed to save keystrokes at the cost of readability? Everyone is used to "int x(int y..". I've learned it some and the concepts around memory ownership and everything are good but the syntax is needlessly weird and annoying.
  - Retra 7y ago
    Rust is not based on C++. People coming from Haskell/ML aren't used to C's backwards type declarations, and that's why they're not in Rust; the people who make Rust have experience with more than just C/C++. So it's not different for the sake of being different, it is actually trying to be similar ... just not similar to C.
    - jimmaswell 7y ago
      Similar to languages much fewer people use, instead of languages more commonly used as systems languages which Rust is meant to be.

steveklabnik 7y ago

I’m a huge fan of this strategy; we use it with Rust, for virtually identical reasons. Ruby also ships each Christmas.

mehrdadn 7y ago
Can't speak for Rust, and I imagine it makes more sense for them since it's a young language, but I wish the C++ folks would chill a bit and take their time a little more; it's getting kind of ridiculous. They don't need to move fast and break things (which they literally have; see e.g. result_of and invoke_result). By the time the tooling across various platforms has finally had a chance to take a breath, they've already got the next version of the standard out, and it's getting hard to keep up with all their changes. I feel there's a better balance between the 13 years ('98->'11; '03 wasn't really a new standard) and the 3 years we have now. Maybe every 5-6 years?
- usefulcat 7y ago
  So maybe choose not to use the very newest features? That's what I've always done and it's worked quite well.
  - mehrdadn 7y ago
    That's exactly what I do on my end, but it's more than annoying when I have to deal with other projects and I suddenly can't even compile them anymore until I upgrade my toolchain and learn what's basically a new language.
- steveklabnik 7y ago
  I don’t think that making the cycle time longer helps; I think making it shorter helps. There’s less pressure to put something in a specific release when they happen less frequently. You can, counter-intuitively, take your time. I know less about the exact details, but I also think that having something to play with helps; I believe that this is what’s going on with with the move towards more TSes before shipping spec text, right? Being able to try things out in nightly helps us a lot.

cousin_it 7y ago

This sounds like a great idea, can't believe I didn't see it earlier. Maybe I should adopt it for my personal projects (software, music, etc): pick a regular release schedule and stick to it, even if it means releasing less feature-rich stuff. Does anyone have experience with this approach?

aninteger 7y ago
OpenBSD does (2 releases every year, approximately 6 months apart).
skummetmaelk 7y ago
This is sort of what scrum does isn't it? Release every cycle no matter what was completed. Whatever was not completed goes back into the backlog and potentially into the next cycle.
- Quekid5 7y ago
  Ideally, yes. In practice there are often complications, however. Usually, it's just office politics: Those cases can be quite difficult -- you really need buy-in and TRUST from management (and have to do the right political plays, etc.) to be able to cut through the bullshit and "allow" feature slips. Books have been written about this scenario. Rarely, deadlines are imposed by Real Politics, aka: law... which can make for Interesting Times. This can range from "quite difficult" to "too easy!", so I have no advice here.
- saagarjha 7y ago
  > Release every cycle no matter what was completed. What happens when your software is in a broken state that's worse than what you had before?
  - justinator 7y ago
    I guess the keyword is, "completed". If something is broken, I doubt it would be in master, or the team has done something terribly strange. Or they should be nicer to QA ;)

freyr 7y ago

Considering that C++ has evolved a lot over the years (and grown quite large), what are good resources for a programmer to get started with the language in 2019? I've heard Accelerated C++ is a good introduction, but it's quite old at this point. Would Accelerated C++ followed by Effective Modern C++ bring someone up to speed with modern C++? Is there a single book or online resource that would service this purpose better?

umanwizard 7y ago
“A tour of C++” (second edition) by Stroustrup is a great starting point.
colmvp 7y ago
I've been learning C++ for the first time starting in 2019. I used Marc Gregoire's Professional C++ which has a version that was published last year and includes C++17, alongside Scott Meyer's line of books, and watching a variety of YouTube videos (e.g. Jason Turner, CPP talks...)
- ExtremisAndy 7y ago
  I second the recommendation of Professional C++. I am just a self-taught programmer, and to be quite honest, felt I was getting in a bit over my head by buying a book aimed at professionals. But I have found the material to be perfectly accessible even for someone without a CS degree, and I am now using C++ for my personal projects. I cannot recommend that book highly enough. Just my $.02
bvod 7y ago
C++ is deep and nuanced, so reading books will help structure your learning. I've found Scott Meyer's books to be great for starting out. Those will give you a fantastic foundation, from which you can dive deeper. Those and others have added significantly to my ability to write clean and maintainable software. This SO post is a great guide for where to look: https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list https://stackoverflow.com/questions/388242/the-definitive-c-...
7y ago

abductee_hg 7y ago

as long as basic things like __alignment__ are still fundamentally broken I simply do not care about the syntax. (I mean it doesn't get anything more basic than this, no?)

edflsafoiewq 7y ago
What's wrong with alignment?
- abductee_hg 7y ago
  well there is this: #ifdef _MSC_VER __declspec( align(16) ) struct float4 { float v[4]; }; #else struct float4 { float v[4]; } __attribute__ ((aligned(16))); #endif but the main problem ist tthat alignment is _not_ part of the typing system. ( alignas vs alignof ) butt, to put it more general: 90% of your performance is in memory access and compilers are rubbish optimizing those, they are however getting increasingly good at the 10%. see also https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc for realworld examples/exploration
  - account42 7y ago
    > well there is this: #ifdef _MSC_VER __declspec( align(16) ) struct float4 { float v[4]; }; #else struct float4 { float v[4]; } __attribute__ ((aligned(16))); #endif I don't understand what you are trying to say here? Why not just use struct alignas(16) float4 { float v[4]; }; You can even put both __declspec( align(16) ) and __attribute__ ((aligned(16))) in the same place if you want to have a fallback for older compilers.

carlsborg 7y ago

C++ needs to merge with Python to create the uber-language: Python for rapid development, and drop to C++ for performance. Like Cython, but with native integration.

AdieuToLogic 7y ago
Boost.Python[0] is not an "official merging" of C++ and Python, but might be something of interest to you. On that page is the link "Building Hybrid Systems with Boost.Python", which is an intro article on it. 0 - https://www.boost.org/doc/libs/1_70_0/libs/python/doc/html/index.html https://www.boost.org/doc/libs/1_70_0/libs/python/doc/html/i...
keerthiko 7y ago
Please don't because you know we'll end up with a frankenstein language with the cons of both rather than the pros of both.
readams 7y ago
What stops you from doing this now? This is pretty much how Python works currently when you need performance.
- carlsborg 7y ago
  For the most part, today's solutions let you write python modules in C/C++. So your core app is in python. I am thinking of the scenario where your core is in C++ and extendable in python for the business logic -- where the core can be a trading system engine, or a webserver for example. The rationale is python serves the algos/data scientists/quants use case really well, and C++ does the "engine" part of things really well.
fredophile 7y ago
No. In my opinion, one of the biggest benefits of Python is that the code looks consistent. There is a single "correct" way to do things. Merging it with C++ would remove this. I use both C++ and Python on a regular basis.
7y ago

hellofunk 7y ago

So, in 2019, if you want the execution speed and efficiency of C++, high level features, without the complexity of C++ or rust, how about Nim??

vips7L 7y ago
Isn't nim garbage collected? The better alternative is probably Zig.

deleted 7y ago

[deleted]

corysama 7y ago

I’m sure the committee has thought about this 1000x as much as me. But, I wish they would go further and release every year. IMHO, that would relieve most of the pressure to push out features that aren’t fully baked. 3 more years is a long time to wait if you’ve already been working on something for several years. 1 more year, when you know you could use “maybe a couple more months” (likely 8 in practice), not so bad.

dwaite 7y ago
The final review process (for ISO standards) is most probably the bottleneck there.
- motajaxxer 7y ago
  ISO generally allows only 5 year cycle. 3 years for C++ is a special case. Furthermore, the bureaucratic overhead will dominate the proceedings then (not unlike thread thrashing).