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.
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.
> 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.
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.
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.
I would say that the primary driver for growing the niche Objective-C community was iOS, not CocoaPods. And Objective-C is dying again with the introduction of Swift.
Also, I see cool C++ open-source projects being released fairly frequently.
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.
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.
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?
Many of my personal projects have only existed because of deadlines.
If you go to shows or conferences, showing or talking about something is the best way to have something, and the deadline focuses you like nothing else.
(that said, sometimes I wonder if I would have something much more polished with a last-minute magical 2-week reprieve)
> If you go to shows or conferences, showing or talking about something is the best way to have something, and the deadline focuses you like nothing else.
The same applies for a personal project that's delivered as a gift to a family or friend. I guess I should write sometime about the Raspberry Pi-based Christmas present I gave my father in 2014, even though he stopped using it scarcely a year later. For this thread, the point is that the deadline made this the only personal coding side project that I've completed in several years.
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.
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.
I actually hate it when software teams adopt the "we will release it when it is ready" stance, because it makes it practically impossible to plan and prepare for the new version.
I am also a strong believer that it is a sign of gross lack of internal discipline, or at least severe lack of confidence. It means you still suffer from "unknown unknowns" and therefore can't come up with and stick to a proper estimate (even if it is something broad, like Q2 2019). This doesn't say good things about a software team, in my opinion.
I know very well that estimates are difficult. But, again in my opinion, going with "we will release the next version on February 20th, now let's discuss what features we can implement during that timeframe" as opposed to "here is a list of features we want in the next version, now let's discuss when we can finish them by... actually never mind, we will just tell people 'when it is ready'".
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?
I'll second Scott Meyers and add that Essential C++ covers the most fundamental parts of the language. Books beyond that tend to cover much more specific and optional tools.
Reading Essential C++ cover-to-cover was very worthwhile in my job as a programmer in AAA games. Books beyond that have mostly involved thumbing around different items to see which I might find useful at some point. Games in particular tend to be very performance sensitive, but also compile-time and debug-performance-sensitive. A lot of the STL is not as respectful of those latter two, meaning a lot of game code uses little or even none of the STL. (Working with UE4 will involve using none, for example.) I'd definitely focus more attention on understanding core language features that the huge amount of content that exists in the STL.
By far the best element of C++ that a lot of other languages lack is const and const-correctness. The second best would be the robust features templates have in comparison to generics of other languages (though the applications allowed by that robustness can be mildly horrifying at times).
Const correctness in C++ is a nice feature, but to say it is missing in many other languages is a bit exaggeration. Many other languages offer a much superior tool - immutable data types. Immutability is stronger than C++ const correctness and easier to use at the same time.
Templates are nowhere near capabilities and ease of use of languages with proper (read: not accidental) macro/metaprogramming systems (e.g. Lisps) or languages with modern generic type systems designed from the ground up (Haskell, Scala/Dotty, Idris, etc). Templates are IMHO a powerful hack, but hack is still a hack with all the consequences - terrible error messages, slow compile times, difficult debugging, late error detection, a lot of accidental complexity caused by templates not being first-class citizens etc.
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.
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...)
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
I recommend going through some recent CppCon presentations, especially these by committee members and people who implemented features/libraries -- Bjarne Stroustrup, Herb Sutter, Howard Hinnant, Chandler Carruth, etc.
Also have a look at Mike Acton's DOD videos -- he'll tell you that modern c++ (and even oop) is garbage, and he'll be right for his own particular case :)
It's hard to name just a single resource and some HN mates have already listed excellent resources. I'd like to add a little bit that perhaps someone will find useful:
- Books by B. Stroustrup are excellent if you already know programming. I wish for a new edition of "The C++ Programming Language" to be honest. I learnt a lot of useful "tips" from many books but only by reading his books was I able to see why C++ made certain choices. That really helped me "level up".
Tour of C++, 2nd edition, from Bjarne Stroustroup is quite good to get to know all major updates how to write good C++20 code (the book goes through all relevant updates since C++11).
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.
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).
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?
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.
You’re missing one of the major points in the post: making release cycles take a long time means that small features aren’t finalized for that long period either.
You seem to be thinking that the compiler devs wait until a release is done to start implementing a release, which is not what happens. Part of the big benefit of releasing every three years is that it makes continuous development actually possible: compiler devs have a better idea of how stable things are, and so which things aren’t going to need to be completely reimplement in another 3 years.
I do not understand where you get a “catch their breath” mentality - none of the modern c++ compilers have a three year cadence, most run with approximately annual major releases.
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.
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.
I'm giving a talk [1] at PyCon AU in a few weeks on a similar topic. Though you're suggesting Python/C++ and I'm covering MicroPython/C.
The concept is to use MicroPython on embedded devices but, if performance is lacking, drop into C to create a module that can be easily accessed from MicroPython.
I've found this to be an exceptionally productive embedded development environment!
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.
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.
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.
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?)
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
for realworld examples/exploration
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.
Are core dumps per se, really bad? I think, that the feature is useful. What is bad is frequency of it happening. For example: are Python's tracebacks better? Maybe I had a bad luck, but in my experience they happen with similar frequency. Core dumps allow you to go to debugger and see what has happened. You can easily send the file. If the crashed software goes without source you can't do a thing, but that's what was the intention. With obfuscated Python one would also be left with nothing.
I speculate the parent comment was referring to the frequency of core dumps: that he/she experiences more of them compared to the Python tracebacks you mentioned.
Disclaimer, I'm speculating that's what they meant, because I feel the same way. It's more common(for me) for Python to refuse to run than to run anyway and later crash, compared to C++. That said, Python isn't a good analogy there...Rust or Golang are more likely to refuse to run for bad code instead of running anyway and crashing later.
Core dumps aren't bad themselves. But the ease and frequency by which other developers (and myself) can cause a core is just insane. It makes C++ more of a headache than anything.
I know; I prefer the ITS/Lispm environment in which you were always running in the debugger. But I think most users wouldn't like that. Bill Gates laughed at me when I once suggested it in passing.
> 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!)
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.
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.
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.
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.
2 replies →
> 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.
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.
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.
5 replies →
I would say that the primary driver for growing the niche Objective-C community was iOS, not CocoaPods. And Objective-C is dying again with the introduction of Swift.
Also, I see cool C++ open-source projects being released fairly frequently.
1 reply →
Alternatively, releasing new features every 3 years to an already-bloated language could cause even worse damage.
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.
54 replies →
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.
> 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.
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/ and 11 times smaller according to http://pypl.github.io/PYPL.html.
3 replies →
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?
Many of my personal projects have only existed because of deadlines.
If you go to shows or conferences, showing or talking about something is the best way to have something, and the deadline focuses you like nothing else.
(that said, sometimes I wonder if I would have something much more polished with a last-minute magical 2-week reprieve)
> If you go to shows or conferences, showing or talking about something is the best way to have something, and the deadline focuses you like nothing else.
The same applies for a personal project that's delivered as a gift to a family or friend. I guess I should write sometime about the Raspberry Pi-based Christmas present I gave my father in 2014, even though he stopped using it scarcely a year later. For this thread, the point is that the deadline made this the only personal coding side project that I've completed in several years.
OpenBSD does (2 releases every year, approximately 6 months apart).
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.
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.
> 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?
3 replies →
I actually hate it when software teams adopt the "we will release it when it is ready" stance, because it makes it practically impossible to plan and prepare for the new version.
I am also a strong believer that it is a sign of gross lack of internal discipline, or at least severe lack of confidence. It means you still suffer from "unknown unknowns" and therefore can't come up with and stick to a proper estimate (even if it is something broad, like Q2 2019). This doesn't say good things about a software team, in my opinion.
I know very well that estimates are difficult. But, again in my opinion, going with "we will release the next version on February 20th, now let's discuss what features we can implement during that timeframe" as opposed to "here is a list of features we want in the next version, now let's discuss when we can finish them by... actually never mind, we will just tell people 'when it is ready'".
Chrome and Firefox teams have, for years now.
Java moved to this approach a few years ago. They release every six months, which IMHO is too frequently.
This is scrum.
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?
I'll second Scott Meyers and add that Essential C++ covers the most fundamental parts of the language. Books beyond that tend to cover much more specific and optional tools.
Reading Essential C++ cover-to-cover was very worthwhile in my job as a programmer in AAA games. Books beyond that have mostly involved thumbing around different items to see which I might find useful at some point. Games in particular tend to be very performance sensitive, but also compile-time and debug-performance-sensitive. A lot of the STL is not as respectful of those latter two, meaning a lot of game code uses little or even none of the STL. (Working with UE4 will involve using none, for example.) I'd definitely focus more attention on understanding core language features that the huge amount of content that exists in the STL.
By far the best element of C++ that a lot of other languages lack is const and const-correctness. The second best would be the robust features templates have in comparison to generics of other languages (though the applications allowed by that robustness can be mildly horrifying at times).
Const correctness in C++ is a nice feature, but to say it is missing in many other languages is a bit exaggeration. Many other languages offer a much superior tool - immutable data types. Immutability is stronger than C++ const correctness and easier to use at the same time.
Templates are nowhere near capabilities and ease of use of languages with proper (read: not accidental) macro/metaprogramming systems (e.g. Lisps) or languages with modern generic type systems designed from the ground up (Haskell, Scala/Dotty, Idris, etc). Templates are IMHO a powerful hack, but hack is still a hack with all the consequences - terrible error messages, slow compile times, difficult debugging, late error detection, a lot of accidental complexity caused by templates not being first-class citizens etc.
16 replies →
> By far the best element of C++ that a lot of other languages lack is const and const-correctness.
Add to that volatile-correctness... which most people aren't even aware of. http://www.drdobbs.com/cpp/volatile-the-multithreaded-progra...
39 replies →
“A tour of C++” (second edition) by Stroustrup is a great starting point.
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-...
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...)
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
I recommend going through some recent CppCon presentations, especially these by committee members and people who implemented features/libraries -- Bjarne Stroustrup, Herb Sutter, Howard Hinnant, Chandler Carruth, etc.
Also have a look at Mike Acton's DOD videos -- he'll tell you that modern c++ (and even oop) is garbage, and he'll be right for his own particular case :)
It's hard to name just a single resource and some HN mates have already listed excellent resources. I'd like to add a little bit that perhaps someone will find useful: - Books by B. Stroustrup are excellent if you already know programming. I wish for a new edition of "The C++ Programming Language" to be honest. I learnt a lot of useful "tips" from many books but only by reading his books was I able to see why C++ made certain choices. That really helped me "level up".
Stroustrup -> Meyers -> Alexandrescu (optional but lots of very clever ideas)
Tour of C++, 2nd edition, from Bjarne Stroustroup is quite good to get to know all major updates how to write good C++20 code (the book goes through all relevant updates since C++11).
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.
The final review process (for ISO standards) is most probably the bottleneck there.
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).
I’m a huge fan of this strategy; we use it with Rust, for virtually identical reasons. Ruby also ships each Christmas.
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?
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.
5 replies →
You’re missing one of the major points in the post: making release cycles take a long time means that small features aren’t finalized for that long period either.
You seem to be thinking that the compiler devs wait until a release is done to start implementing a release, which is not what happens. Part of the big benefit of releasing every three years is that it makes continuous development actually possible: compiler devs have a better idea of how stable things are, and so which things aren’t going to need to be completely reimplement in another 3 years.
I do not understand where you get a “catch their breath” mentality - none of the modern c++ compilers have a three year cadence, most run with approximately annual major releases.
5 replies →
So maybe choose not to use the very newest features? That's what I've always done and it's worked quite well.
1 reply →
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.
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??
Isn't nim garbage collected? The better alternative is probably Zig.
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.
I'm giving a talk [1] at PyCon AU in a few weeks on a similar topic. Though you're suggesting Python/C++ and I'm covering MicroPython/C.
The concept is to use MicroPython on embedded devices but, if performance is lacking, drop into C to create a module that can be easily accessed from MicroPython.
I've found this to be an exceptionally productive embedded development environment!
[1] https://2019.pycon-au.org/talks/extending-micropython-using-...
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/i...
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.
What stops you from doing this now? This is pretty much how Python works currently when you need performance.
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.
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.
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?)
What's wrong with alignment?
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 for realworld examples/exploration
1 reply →
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.
Are core dumps per se, really bad? I think, that the feature is useful. What is bad is frequency of it happening. For example: are Python's tracebacks better? Maybe I had a bad luck, but in my experience they happen with similar frequency. Core dumps allow you to go to debugger and see what has happened. You can easily send the file. If the crashed software goes without source you can't do a thing, but that's what was the intention. With obfuscated Python one would also be left with nothing.
I speculate the parent comment was referring to the frequency of core dumps: that he/she experiences more of them compared to the Python tracebacks you mentioned.
Disclaimer, I'm speculating that's what they meant, because I feel the same way. It's more common(for me) for Python to refuse to run than to run anyway and later crash, compared to C++. That said, Python isn't a good analogy there...Rust or Golang are more likely to refuse to run for bad code instead of running anyway and crashing later.
Core dumps aren't bad themselves. But the ease and frequency by which other developers (and myself) can cause a core is just insane. It makes C++ more of a headache than anything.
I know; I prefer the ITS/Lispm environment in which you were always running in the debugger. But I think most users wouldn't like that. Bill Gates laughed at me when I once suggested it in passing.
> 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!)
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.
30 replies →