Do you have some good advice or know any useful resources to learn in a proper way how to code in C++? For the context, I know some C, but C++ seems a different kind of beast, and it's easy to get lost in the huge variety of features and libraries it offers.
I would also like to add that it helps to read "The Design and Evolution of C++".
I found that I plateaued early in my C++ journey. However, I was always reading from the experts and it really helped to read material from Dr. Stroustrup. Once I began to see the common thread behind what he was saying and understood why some things were the way they were, it helped understand when it's a good time to use/not-use certain things. This helped break past that barrier and to improve my skill further.
Also, it helped to write a _lot_ of c++ code and think about how that could be better.
I'm afraid I didn't read a tonne of good C++ code in that period but somehow, I managed to keep growing and at some point, it became my "go to" language and I really started to like it.
Long story, short: Read books from the experts, esp. Dr. Stroustrup.
> I would also like to add that it helps to read "The Design and Evolution of C++".
I think that book is worth reading even to people who have no intention of going anywhere near C++, as long as they are interested in programming language design and evolution. I wish there were more books like this one to explain the kind of thinking that went into the design of a language and to tell its history.
"I found that book very interesting in many regards. I had bought and read it several years ago (out of interest, though I have not worked on C++ professionally).
Stroustrup goes into a lot of details about the reasons for many design decisions in the language."
That's one of the reasons that make the book interesting. He even goes into human and cultural aspects of programming.
I would love a book similar to C# In Depth but for C++. The book takes you on an evolutionary tour of C#s features, version-by-version. One of my favorite programming books of all time and a good read even for someone who doesn't program in C#.
As for "Stop Teaching C" video one should also consider this book https://www.amazon.com/Accelerated-C-Practical-Programming-E...
Alas, it is c++03. On the other hand it's relatively thin and it begins with the standard library (std::vectors, std::sort, std::string) from the first chapters. So I guess it was the first good book that didn't begin with C language from the start.
It is not an inferiority complex, rather to stop people learning about writing bad code, open to security exploits by default, something that C is pretty good at.
I think it's a great introduction to Programming, but if you already know some other language, it tends to be verbose - but Stroustrup always tends to be verbose. I, for one, really like his style.
I used to like Bjarne's style when I was just starting, but nowadays it seems way too verbose. Even talks, you can "compress" his 1+ hour talks to 15 minutes, lossless :)
One of the trickier things about C++ for me (in terms of “getting lost”) when I first started was that there’s no standard C++ project structure. It varies based on the build system you use, whether what you’re building is just an API or something else, and personal preference. I recommend looking at some open source C++ projects like Tensorflow (Google), LevelDB (also Google), folly (Facebook), MongoDB, and Thrill (a Spark clone in C++, https://github.com/thrill/thrill). Also pick your own projects you’re interested in. Take a look at basic tutorials for build systems like make, CMake, and Bazel. Hopefully that’ll give you an idea of what a modern C++ project actually looks like, and will help you start your own.
For books I’d like to add to the current top comment (may go away) API Design for C++. It’s a great reference on exactly what it sounds like.
If you want fun miniproject may I suggest Peter Shirley's excellent mini-raytracing bookseries: Ray Tracing In One Weekend, Ray tracing the next week, and Ray Tracing, the Rest of Your Life:
https://www.amazon.com/Ray-Tracing-Weekend-Minibooks-Book-eb...
I would like to point out that yosefk fqa is a bit old now, and while some problems mentioned are still relevant, tools and conformity across up to date compilers are magnitudes better now.
Also in case anyone is going to suggest something project-like please something in the direction of HFT/OS/Systems related as opposed to game programming? There are loads of stuff out there for C++ related to game programming.
Not being a smart@$$ here. Any language you want to learn will only become natural when you've used it for a significant project or set of exercises. Either clone or port something non trivial, or use it for your latest pet project, or get permission to use it at work.
That's a pretty useless answer. It's easy to use C++, but in a non-idiomatic or C-style way. I think the OP is aware of this problem and is looking for concrete examples of modern C++.
I think reading best practices and most other forms of technical training work best after some experience is gained, even poor experience doing it the wrong way.
It's similar to why university lectures work best if the audience has already done its assigned reading. The people in the audience have better questions in mind while listening, so they can better intuit when a gap is filled in or if some part of the explanation doesn't make sense.
Sure. I gathered that, but until you've done stuff the wrong way the learning isn't going to stick the same. I'm not saying _don't_ use resources, I'm saying do stuff, when it feels wrong read up on it to learn the right modern practice
From experience I can tell you this: just 'use it' is not enough for some. I have seen truly, truly horrible code written by people who have been using C++ for decades. Let that sink in a bit, then realize that while 'use it' isn't bad advice, it is too general and too limited of a statement :P. You need to learn the right usage as well.
I'd still argue that there's a lot of value in some form of teaching (via book or video or whatever). If left to their own devices, novices will often come up with messy, non-idiomatic ways to do things.
I find using both in combination is usually the best way to go. If you're just reading a book and doing exercises in it, you wont learn as well. Making something you want to make and using books as reference while developing makes you learn a lot quicker.
Also, the answer to this question depends a lot on your previous experience with other languages. If you're well-versed in another C-like language, jumping right in and starting to make something will probably teach you a lot, really quickly. If you're more of a beginner in programming generally, you need a book or a teacher.
Not learning from books/teaching can make it hard to improve. I love reading other peoples code and thought processes because it often reveals how I'm missing something in my toolbox.
Studies have shown that one of the best ways to remember is to take a stab at a problem before learning the solution. So even quizzes on using libraries has helped me learn methods and concepts I would have not learned on my own if left to my own way of coding. I try a simple problem on my own before learning that there is a cleaner, more efficient solution. It's easier and more approachable to do that with small problems than trying to revise an entire document of code.
Lastly, I think a lot of experts underestimate the gap between novice and intermediate, where it's really hard and frustrating to attempt things that are a bit more complicated, requiring more background knowledge than just whats shown on the surface.
Ya, I think a balanced approach is the best, begin by reaing or watching videos, but not too much, just to get an overall idea, then get hands on but don't stop there, read more code and watch more videos and continue the process for your life time!
I sometimes get carried away and stop reading more after I cross some threshold which prevented me from noticing lot of nice things like best practices that were happening in the industry/or better design patterns etc..
Yeah, the trick in my opinion is to find a good enough book or guide on new features with which you can skim and familiarize yourself. If you don't understand when you might apply something, go figure that part out. Then work on a project and when it seems like you might need that concept, go read about it in more detail. In terms of real world work, having a very broad, surface level knowledge of many concepts and when you might apply them often comes in more useful than a very in depth knowledge of a few specific concepts.
IMO, the classic C++ book/author is still the best: Effective C++. Don't forget about the sequels, including the mostly overlooked Effective STL (which I happen to like better than the first two books). And to address the modern part of this question, I'll add that Scott Meyers has written Effective Modern C++ as well, but I'd read that last after getting the hang of C++03. No matter what people say, I tend to believe C++11 and on is not really a different language as much as it is syntactic sugar to cover up the ugliest parts of C++.
As someone who programmed in "classic C++" for decades, I feel like modern C++ is pretty different, and that it's not just syntactic sugar to make some ugly things easier. The biggest example is that my natural inclination to use raw pointers everywhere and manage all memory myself, while idiomatic modern C++ is full of unique_ptrs and shared_ptrs everywhere, and raw pointers seem to be regarded as a code smell. Converting to this style is not an automatic process.
For people who are coming from a classic C++ background, I find Bancila's Modern C++ Programming Cookbook to be a good first stop for discovering modern C++ idioms.
OK from that perspective I can relate. Even before using C++11 I was using a lot of the new STL through Boost. If you use Boost, the only fundamental differences are syntax like auto, variadic macros, constexpr, noexcept, and lambdas all of which are familiar enough to get by. The only practical differences that have no equivalent in C++03 is move operations and maybe the threading/chrono stuff. Effective Modern C++ covers that so that's all I needed to "upgrade."
I remember being placed on a C++ project for a few months after having been away from the language for almost 10 years. The lack of raw pointers was an immediate slap in the face and had me going "WTF am I looking at?"
IMO, Effective C++ is just a collection of warnings about pitfalls, something that is unfortunately needed for C++ programming, so do read it. But it is neither an introduction nor a collection of big picture advice.
That is arguably true for the first two books, but Effective STL is very opiniated. Scott Meyers argues not to use for loops when possible and to use the algorithm library everywhere instead. I tried convincing my team to do this but we were using C++03 and writing a struct functor is no fun... I think in C++11 a for loop and even a for each loop should be modernized with a good lambda instead.
It's a pity that one of the most recommended books is about the pitfalls of C++ and is by someone on his own admission has never written production C++ code.
Of course it's a very good book though.
My recommendation is for "Accelerated C++" by Koenig and Moo.
It's rooted in actual teaching experience and compared to most C++ books is pretty slim.
The only negatives these days is that it is a bit old and (still) expensive.
If you know C, C++ Common Knowledge (https://www.amazon.com/Common-Knowledge-Essential-Intermedia...) will give you a quick run of the gotchas you're to avoid. From there, move to Scott Meyer's books, which will give you some good foundational knowledge on how features of the language work together. In particular I like that each concept is presented in a bite-sized chapter that you can read in a couple of hours and think about for the rest of the day. Even though the first two are about "classic C++" I wouldn't skip them.
For a glimpse of the true power of modern C++, check the Boost Hana library docs, hopefully this will serve you as motivation to keep on going.
Above all, don't do this alone. The compiler errors that you get once you start applying modern (template) techniques can be a bit of a rabbit hole and takes a bit to get an eye for deciphering them. Lean on coworkers, local user groups and/or the C++ slack group which is pretty supportive.
Best of luck.
As others mentioned, Effective Modern C++ by Scott Meyers is a solid modern C++ book with nice tips and tricks. Other than that, check out the official C++ Guidelines by Bjarne and co. http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
I’m on my phone so I don’t have links, but the last few CPPCons have had talks by very prominent C++ luminaries talking about how to properly teach C++. They may be of interest.
The biggest message seems to be “don’t treat C++ as C with extra stuff, it’s its own language.”
Don’t forget SFINAE. It’s what most of the modern type traits rely on and something you’d have to understand, at least conceptually, to fully understand how to effectively use things like std::enable_if.
For those unfamiliar with C++, SFINAE is "Substitution Failure Is Not An Error". The short of it is how the language deals with overload selection with templates. If you want a more detailed explanation and example, see [1].
Others have talked about how to learn the language but many people often find that hardest thing to do is to even compile their first C++ file. This is the "build system escalation policy" that I personally use, depending on what I need:
1: Experimental, throw-away code: online IDEs or Godbolt if I care about compiler output. You would be surprised how much mileage you can get out of a simple online IDE when you are just learning or exploring a new thing and don't care about preserving your work.
2: Single-file code or small multi-file projects with no dependencies (like exercises or code samples from a book): direct calls to clang++/g++ in the command prompt or a simple build.sh shell script when I have to build multiple files. Make is a fantastic tool for this so you can learn and use that instead. I would actually encourage beginners to play directly with the compiler and learn the basic flags though, but this is personal preference.
3a: Personal projects that pull in other dependencies (either system wide or libraries from github or other sources): Make or cmake would probably work here equally well. I actually prefer cmake for its find_package and external project functionality. Notice the jump in complexity from 2 to 3, this is something you have to deal with and eventually you will have to pick a build tool and learn it.
3b: After learning to use Bazel I have mostly migrated to it for all my personal projects, but there was an initial learning curve for sure (not worse than cmake though).
4: At work: Whatever your company/team/group uses, you will most likely have little input on this if the codebase is old and established.
If you are in Windows you can use vanilla Visual Studio C++ (Community edition is free and has all the bells and whistles) for 1-3, or use Visual Studio + cmake (you can generate VS solution files from cmake).
I found "C++ Primer" by Lippman et al very well written and comprehensive. It includes C++11 features and every chapter has exercises to make sure you understand the content.
What would you say are important features missing in C++11 that are in the current standard? I ask because I'm trying to get back into C++ development after many years and even C++11 seems like a new language to me.
I have a question on this topic which is - is it possible or practical to only learn "modern" C++?
Isn't it necessary to be able to understand pre-modern C++ in legacy code bases or to work alongside a co-worker who might code using an older style? Or even to be able to understand documentation and texts about C++ from an earlier era?
I share your concern. Even if one isn't (knowingly) dealing with older C++ code, all of the language rules apply to every line of C++ being compiled.
Just one typo, or misguided use of syntax, and a person might be using some "older" revision of the language without knowing it. And I'm not aware of any tool that will warn the programmer that he/she has done that.
So I'm concerned that programmers schooled only in "modern" C++ will fail to understand that this has occurred, and will either (a) get error messages that don't understand, or (b) get program behavior that they don't anticipate.
I'm curious if people have found this to be a problem in practice.
>"I'm curious if people have found this to be a problem in practice."
Same. And I think you articulated the specific concerns I have about just learning the "modern" version.
It would certainly lower the barrier to entry in learning C++ if this was an unfounded concern.
C++ has some 35 year of history and changes at this point. This point alone adds(for me anyway) to the perceived cognitive load of learning it. C also has a similar length of history but it is a much smaller language.
> It would certainly lower the barrier to entry in learning C++ if this was an unfounded concern.
If the Javascript community, which is as fragmented as C++, if not more, could introduce "strict" mode and enforce it basically everywhere, then maybe C++ could do the same thing.
Have C++20 recommend a certain subset of C++, have C++24 warn as deprecated features not in this subset, have C++30 error out on everything outside this subset, unless the compiler is set to compatibility mode and finally have C++40 refuse to compile the old code.
Piggybacking of this post, if anyone has any similar resources for best practices in modern C I'd be interested. There don't seem to be any moocs that go beyond introductory material and K&R obviously doesn't cover modern tools and methods.
“C Interfaces and Implementations” by David R. Hanson is what I used when I had a similar concern a few years ago. It’s from 1997, so no, it doesn’t cover the newest C standards, which I understand is your main concern. Though C11 didn’t add too much semantically, for what it’s worth. That said, the book provides great design patterns for writing C in an object-oriented sort of manner, more idiomatic to OOP.
Peter Hintjens was writing “Scalable C” a couple years ago, but recently died, and never got very far unfortunately.
There's the "Modern C" book from http://icube-icps.unistra.fr/index.php/Jens_Gustedt. Very opinionated, but it covers a lot of ground and if you disagree, it gives you a framework for figuring out your own preferences.
My biggest question would be what modern means to you? Does it mean the style of the newest popular C project? The newest standard (C11)? And what devices are you using C for? I'd assume a standard POSIX environment, but you can't be sure with C.
For even more stuff - if you do the same search for C, especially 'modern C', you'll find those threads often also contain a parallel set of recommendation for C++ resources.
Sizing the softare to fit your schedule: i.e., if you want to be at the level of BJS, write a C++ compiler; if you want to be as good as Google employee, uses the common Google c++ libraries Protobuf ABSL etc. to write a simple webserver with a few APIs. The list goes on and on.
I know that doesn't answer your question and to be honest, I am curious about the resources which come up here too, but C++ can be so painful to learn that I wanted to know what drives you into that direction. I mean, there are alternatives like Rust. Do you have a specific project in mind, need it to fulfill some résumé requirements or something completely different?
Depending on the direction you want to go in your career, it's still a major need.
Any complex or high-performance computing relies on C/C++ pretty heavily still.
It's also a good tool to have in your box for building well-performing cross-platform native apps with Qt.
I say this as one who's probably at the same stage as OP. Know some C, and reasonably comfortable with the basics. Application of C++ is a little more widespread outside of strict embedded environments, however. (Another space I personally want to immerse myself in)
I find Rust is a much better language, but there are very few mature libraries right now if you do something outside the scope of what Mozilla is doing. Also very few companies that are working in Rust (AFAIK, if you know some let me know) looking for devs.
If you want to work in a company that is doing any kind of low level code you will either need C or C++ as a foundation. At least to understand existing code. Most companies won't just rewrite everything in Rust, no matter how good the language is.
I really hope Rust replaces C++ for new projects, but it's just too new to tell whether that will happen. I find there's a bit more momentum (and good ideas) than in D, but nobody can predict the future from 2-3 years of language history.
“This Week in Rust” lists explicit job postings. One of the latest companies looking for Rust programmers is a little company you may have heard of: Facebook.
That said, many places are hiring good programmers and putting them on Rust projects, rather than hiring Rust programmers explicitly. There aren’t many pure Rust shops yet, so they need a broader skill set.
I still haven't grasped Rust as much as I'd like, but I have to admit that at least it feels like every part of the language fits nicely together with the others, as opposed to the "messy spaghetti" feel I get from C++ (though this is of course my subjective impression).
There are things I'd like they do, like removing the Python 2 dependency for building from source, or actually writing a spec. But I guess that'll come with time.
I never built from source, so Python 2 dependency for that didn't bother me. I kind of like the documentation as spec as long as the language is still evolving so quickly. Maintaining separate documents would be more difficult here.
I find this comment a bit odd... Not everyone works at a startup and 90% of development work is improving existing codebases, not starting new projects. There's just SO MANY existing C++ codebases out there that people are paid to work on. I had to (re)learn C++ for a project at work recently.
I'd like to learn OpenGL programming, and C seems too painfully low level for that, although I won't argue that it is a lot easier to wrap your head around it. However, this days I've been toying with C++14, and the experience (apart from the dependencies, Makefiles, et al. mess, has been pretty smooth with regards to syntax.
Apart from OpenGL (which seems like a neat way to learn some interesting maths and physics), learning C++ helps delve into many big and important existing codebases, especially databases, and other complex systems. Rust may be designed for that but it isn't used so much in the wild.
Moreover, I want to feel badass in a hardcore low-level hacker way after programming so much in high-level dynamically-typed languages, and contribute my one stone to the future grave of JS/Node (let's hope Atwood's law won't work :P).
Why C++ over Rust? Rust is still in very early stages. The compiler, tools, ide and library support is world's away from where rust is at the moment. Language design is one part of many that helps with software creation.
The question assumes that there is a single "proper" way to code in C++ that everyone agrees on. But that's just not the case. For example, Google bans exceptions, operator overloading, and most uses of Boost in their C++ code. Facebook embraces all those things. QT re-invents most of the standard library.
A lot of the C++ language is sort of experimental. Sometimes features get thrown in and then deprecated and/or taken out, like the "export" keyword for templates, or throw specifications. Most programmers have strong opinions about which C++ features are bad. But that's all they are-- opinions. The C++ standard supports pretty much any way of doing things you could imagine-- async, sync, multiple inheritance, functional, you name it.
If you're a novice, my advice is to learn C really well. Then choose a C++ style guide and follow its recommendations closely.
If you haven't already I'd suggest learning a functional language first, then coming back to modern C++, because much of the new features are borrowed from other languages.
Personally I started doing this then never went back. Seems most of the jobs out there for C++ really aren't that interesting.
Absolutely unnecessary. Modern C++ borrowed some paradigms of functional programming, but learning a functional language isn’t remotely close to being a prerequisite to learning those features.
In terms of jobs, C++ is used heavily, if not the majority of the time in: AAA game development, high performance computing, high frequency trading and quantitative finance, embedded software, image processing and computer vision... honestly, I focused on C++ out of school years ago BECAUSE of how interesting many of the jobs are. They’re also generally more stable and thus competitive over time compared to e.g. web dev, enterprise software, and so on, because the domain knowledge required means you’re a lot more valuable than knowing X and Y design pattern or framework Z.
As others noted best way to learn is to use it. Pick any open source you like, compile and test it, learn it's code, try to fix some bugs or implement features, ask questions from other developers, get feedback on your code. That way you'll learn all caveats of practical C++ development and tools.
Additionally while traditional and more detailed books already posted here I'll just add one I personally liked: Discovering Modern C++ by Peter Gottschling. It's had exactly information I would expect be needed for person who already have reasonable experience in programming, but want short introduction into C++.
Disclaimer: I'm certainly not someone you can call experienced C++ programmer since I just developing and manage open source project for 3+ years. So take my opinion with a grain of salt.
Best way to learn anything new, is just pick a pet project you've been thinking about, and implement it in that language/database/system/whatever. That's how I've always done it over the years. You end up constantly building upon the last projects knowledge.
I would recommend the book C++ Primer, by Stanley Lippman. Also http://www.learncpp.com/. Both are great resources IMHO. You might have to skim over certain topics as you already know C.
Build simple command line programs with it and use first a simple editor like Code::Blocks. Best thing to stop you learning C++ is using one of this beasts like VisualStudio and start with Windows programming ;)
Take a look at how the standard library does things, and particularly anything for which it is not clear to you how one might implement it, or the use of anything whose purpose you don't really understand.
People who spent many years developing C++ already understand what the standard library offers, regardless on whether they studied that deliberately.
People coming to the language lack the expertise to tell well-designed code from bad-designed. It’s tempting to treat the whole standard library as an example of the former.
Maybe that’s a personal thing but I remember doing that when I just started my career back in 2000. STL wasn’t quite there but MFC was already in wide use. Because I lacked the experience I considered whatever’s there is good, and ended up using not so good parts such as C++ exceptions and macro-driven dynamic serialization.
> People who spent many years developing C++ already understand what the standard library offers
That statement isn't true for (at least) me. The main reason is that I'm usually working on code that must be compile-able as C++11, and/or may require an old-ish version of gcc's standard C++ library.
So in my daily work I usually have little/no reason to interact with the newer parts of the standard library.
Before diving into smart pointers, move semantics and other (mostly) recent additions, I would recommend getting well acquainted with the basics: RAII and common patterns such as passing by constant reference. Effective C++ by Scott Meyers, as others have noted, is an excellent entry point.
For this, I can't point to any one source, but I highly suggest looking at the implementations of the C++11 type_traits header. Building off of that would be a great second step.
I usually get bogged down by the syntax of very many complex things that gets me lose the focus on the motive of the code. I wish we had an efficient way to learn what a declaration means. (On the lines of cdecl)
Probably the most comprehensive open-source creative coding framework. Maybe most helpful for familiarity with graphics programming / OpenGL, but it really extends to all types of possible interactions. Maintained by an awesome group of people.
OpenFrameworks has nothing to do with _modern_ C++. It’s a framework for laymen artists that happens to be written in C++. It won’t teach you about move semantics, lambdas, unique_ptr, for-in loops, etc.
I wonder if at some point it will be possible to discuss C++ on HN without the majority of the conversation becoming side tracked into discussing Rust.
You should check out Rust, it aims to replace C++ and do a better job in memory management, and developer experience in general (cross-platform compatibility, package management, etc)
Regardless, yes, that’s the whole point. What’s been accepted is https://doc.rust-lang.org/nightly/core/arch/index.html , that is, intrinsics that map 1-1 to the vendor APIs. (I belive this is the same in C++ but not my area of specialty so I may be wrong)
On top of that, you have stuff like https://crates.io/crates/faster , which is very high level. Looks like they need to fix up the README... but you get the idea.
Also, autovectorization has existed this entire time. This stuff is for when that falls down.
OK. (The one time I encountered SIMD in C++ was a decade ago; we had to use assembly then. And even then, we weren't playing with an up-to-the-minute compiler. (In my experience, your comments elsewhere on this article about embedded toolchains were accurate.)
Are the intrinsics standard? If so, what version of the standard were they in? How good is compiler support for them?
In certain industries, specially where human lives are at stake you can only use certified compilers, where the kind of code they generate is validated against specific safety standards.
I never used IAR, given my focus on writing safe software I try to be up to date to these areas, and ways to somehow write secure software in C and C++. like MISRA and Frama-C.
Maybe someone else can jump in.
However, I can tell you that in general proprietary compilers for embedded devices make Visual C++ feel state of the art, let alone when compared with gcc or clang.
Many of them are stuck in partial support for C99 or C++98 (e.g. TI), with no clear roadmap of future improvements.
Yup. D had a shot, but they screwed it up with (effectively) mandatory garbage collection.
Ada also had a shot, I think, but they screwed it up with no C compatibility and expensive SDKs - or something. For some reason, Ada is just not perceived as "cool". It actually seems like a pretty good language!
The issue with D is not mandatory garbage collection, rather its quality and anti-GC religion.
Joe Duffy mentioned on his Rustconf talk that Windows devs even with Midori running in front of them, it was still a very hard sell for them to psychology accept it as doable.
The problem with Ada was basically expensive SDK, Pascal-like syntax and not being part of OS SDKs.
Only systems programming languages that are bundled with OS SDKs survive on the market, others either get a niche (Ada - high integrity systems) or fade into oblivion/maintenance (Modula-2, Delphi, ...).
The main reason being, companies already payed for OS SDK or gotten it for free with the OS.
Any other language must add a very worthwhile set of benefits for them to look beyond the SDK and possible toolchain integration issues.
> Windows devs even with Midori running in front of them,
There were GC'ed operating systems in the 80s. The point is not this. It's writing applications where you can maximize your CPU usage.
If it's a game, it means that you want to write your code so that the highest number of objects are visible on screen and are being updated on each tick.
If its's a multimedia software, you want to be able to run most sounds / videos in parallel at the same time.
If it's an interpreter, you want to have the highest instructions-per-second count.
etc etc... the point is not to have "good enough" performance, it never has been as soon as you use non-trivial apps. It's always "how fast can it be" / "how far can I push it", and an implicit language-level GC puts limits to this.
Having a GC enabled OS doesn't mean the GC runs all the time or it is the only way of allocating memory.
The last generations of Oberon OS had support for video editing applications as an example.
There are real time GC applications in production being used to control weapons systems, including live targeting and soft real time factory automation systems.
Regarding D, using @nogc or -vgc allows the developer to control when the GC works, it at all. What the language lacks is a GC that can match real-time GCs used in soft real time systems.
At very least, there needs to exist painless interoperability with the SDK toolchain, debugging tools, IDE, platform libraries.
Every piece of the puzzle that doesn't quite work like the SDK tools, means additional development/debugging effort.
Naturally the big question is always if the added benefit of using language X outside the expected workflow outweighs the extra development costs.
Just look at C++, it was on the path of being widely adopted by desktop OSes, every C compiler vendor was adding support for it.
Then BSD and Linux large scale adoption happened with GNU manifesto favouring C as the language to write portable software, Java and .NET came into the scene.
Microsoft was probably the only major OS vendor still caring about it, until LLVM happened and the wind started blowing again with C++11.
The embedded space is still an area where C++ is hardly seen, with a few conference talks last year discussing on how to advocate for it.
Now all major C compilers are written in C++, but had Microsoft focused only on .NET or LLVM never happened, and history would probably followed another path.
Only in a very strict interpretation that everything that is still used somewhere didn't get replaced. Perl was more or less replaced, for example, and I like that. The only kind of originality that is good in programming is "surprisingly simple". "Surprisingly weird" is terrible.
You're going to get at least 1 angry Perl programmer explaining that Perl is actually thriving and it's never been better to be a Perl programmer :p
Which is actually partially true... the long tail of programming languages today is very, very big. There's probably 10-50x more programmers now than there were back in 1995. The programming world can probably sustain 10-20 mainstream languages these days, if not more.
>>Perl is actually thriving and it's never been better to be a Perl programmer :p
Don't know about that. But only yesterday afternoon I spent like 2 hours writing a Perl script to heavy lift some Unix file work, Which I factored would take a week at-least to do in any other language.
Perl is still largely a very useful language without any replacements. So are awk and sed.
Web development world seems to have moved on to something else now.
> But only yesterday afternoon I spent like 2 hours writing a Perl script to heavy lift some Unix file work, which I factored would take a week at-least to do in any other language.
I'm guessing you're more familiar with Perl, because I personally find it hard to believe that Perl by itself is an order of magnitude more efficient to write than Python or Ruby.
You haven't addressed my (implied) question,though. I don't think that the average Perl programmer is an order of magnitude more productive than the average Python programmer.
I'm not the OP, but I'm tempted to learn more C++ so that I can directly use Qt without relying on language bindings for it. I like the idea of Rust, and maybe some day I'll tinker with it, but it looks like it has quite the steep learning curve.
First of all, I should say that I feel like bringing up Rust in this thread is inappropriate, and I’m glad the OP was downvoted.
To comment briefly on the learning curve, the trade off is basically, C++ is easier to get started, but harder on the high end. Rust is a bit harder for C people to get started, but then the high end is much easier. Rust’s curve is flatter, in a sense.
Oh and also: learning one will certainly help you learn the other in many cases. I advocate learning many languages :)
This week I’m visiting a ~700 person company in London that’s moving away from C and towards Rust. They’re not doing a Big Rewrite, obviously, so they still have quite a bit of C too. They chose Rust over C++ though. It always depends!
>Oh and also: learning one will certainly help you learn the other in many cases. I advocate learning many languages :)
Especially the Rust borrow checker will make you mad in the first place, and then teach you something about memory management you will be able to use in C++. It really improves your mental model in places you didn't expect.
if you aren't already very familiar with c, i would say the learning curves for c++ and rust are pretty similar. it will take you longer to get stuff to compile in rust, but correcting instances of undefined behavior in c++ can also take a long time in c++.
I know enough of the basics of C and C++, and their standard libraries to shoot myself in the foot with, and I'm sure invoke undefined behavior in the process (I do realize they are separate but related languages). Rust on the other hand appears to be a completely different paradigm from my primary experience which is in managed languages (e.g., Python, Java, etc.). In particular the borrow checker, while a marvelous idea, I think would pose a quite the challenge to get accustomed to.
it's really not that bad. for a beginning programmer, the places where you would struggle with the borrow checker in rust have a lot of overlap with cases in c/c++ where you would struggle to fix all the errors reported by valgrind.
C++ is just C with extra notation for easy modeling of Classes and Objects. While C still remains valuable, C++ is in my opinion questionable and there are many excellent alternatives like Java or C# for doing similar things and much more.
I have programmed in C++ for many years and honestly would not suggest it to any one but anyway here are some excellent resources.
ftp://bitsavers.informatik.uni-stuttgart.de/pdf/borland/borland_C++/Borland_C++_Version_2.0_Getting_Started_1991.pdf
(Read chapter 4 C++Primer. The hole folder is a rare jewel)
"Object Oriented Programming puts the Nouns first and foremost. Why would you go to such lengths to put one part of speech on a pedestal? Why should one kind of concept take precedence over another? It's not as if OOP has suddenly made verbs less important in the way we actually think. It's a strangely skewed perspective." from https://en.wikipedia.org/wiki/Object-oriented_programming criticisms says a lot.
- Principles and Practice Using C++ (http://www.stroustrup.com/programming.html)
- From Mathematics to Generic Programming (http://www.fm2gp.com/)
- The Scott Meyers books
Some of the Bjarne Stroustrup videos,
"Learning and Teaching Modern C++" - https://www.youtube.com/watch?v=fX2W3nNjJIo
Some of the Herb Sutter videos,
"Writing Good C++14... By Default" - https://www.youtube.com/watch?v=hEx5DNLWGgA
"Back to the Basics! Essentials of Modern C++ Style" - https://www.youtube.com/watch?v=xnqTKD8uD64
Some of the Kate Gregory videos,
"Stop Teaching C" - https://www.youtube.com/watch?v=YnWhqhNdYyk
"10 Core Guidelines You Need to Start Using Now" - https://www.youtube.com/watch?v=XkDEzfpdcSg
"It's Complicated" - https://www.youtube.com/watch?v=tTexD26jIN4