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.
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.
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)
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.
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).
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 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.
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?
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.
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?)
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 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!)
[+] [-] Rexxar|6 years ago|reply
[+] [-] asveikau|6 years ago|reply
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.
[+] [-] gurkendoktor|6 years ago|reply
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.
[+] [-] bogwog|6 years ago|reply
[+] [-] 0815test|6 years ago|reply
Not really... Rust 1.0 is from mid-2015, well past 2011.
[+] [-] cousin_it|6 years ago|reply
[+] [-] m463|6 years ago|reply
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)
[+] [-] aninteger|6 years ago|reply
[+] [-] skummetmaelk|6 years ago|reply
[+] [-] enraged_camel|6 years ago|reply
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'".
[+] [-] Sharlin|6 years ago|reply
[+] [-] ternaryoperator|6 years ago|reply
[+] [-] mempko|6 years ago|reply
[+] [-] freyr|6 years ago|reply
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?
[+] [-] Bekwnn|6 years ago|reply
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).
[+] [-] umanwizard|6 years ago|reply
[+] [-] bvod|6 years ago|reply
This SO post is a great guide for where to look: https://stackoverflow.com/questions/388242/the-definitive-c-...
[+] [-] colmvp|6 years ago|reply
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...)
[+] [-] tdsamardzhiev|6 years ago|reply
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 :)
[+] [-] bloodorange|6 years ago|reply
[+] [-] mhh__|6 years ago|reply
[+] [-] pjmlp|6 years ago|reply
[+] [-] corysama|6 years ago|reply
[+] [-] dwaite|6 years ago|reply
[+] [-] steveklabnik|6 years ago|reply
[+] [-] mehrdadn|6 years ago|reply
[+] [-] nayuki|6 years ago|reply
[+] [-] hellofunk|6 years ago|reply
[+] [-] vips7L|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] carlsborg|6 years ago|reply
[+] [-] matt_trentini|6 years ago|reply
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-...
[+] [-] AdieuToLogic|6 years ago|reply
0 - https://www.boost.org/doc/libs/1_70_0/libs/python/doc/html/i...
[+] [-] keerthiko|6 years ago|reply
[+] [-] readams|6 years ago|reply
[+] [-] fredophile|6 years ago|reply
[+] [-] abductee_hg|6 years ago|reply
[+] [-] edflsafoiewq|6 years ago|reply
[+] [-] NTDF9|6 years ago|reply
[+] [-] hawski|6 years ago|reply
[+] [-] gumby|6 years ago|reply
[+] [-] 0815test|6 years ago|reply
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!)