Well, you seem to be precisely the target audience for the course linked in this very post:
> This open-access course is directed at those who are already familiar with C
> and object-oriented programming towards a proficiency level of C++
> programming.Maybe, in this context it makes lots of sense, if you know C well there are things which "just work how you expect" in C++ and so they need at most a brief refresher.
I agree with Kate Gregory that this is a bad way to teach C++ from scratch. That is, if you know only say, Python or Java (or nothing) and want to learn C++, you should not begin by learning C. Kate's approach skips many of the things you can do in C++ but you shouldn't, whereas if we try to start with C you're going to see that a lot, because "they were legal in C" is why they're allowed in C++ even though they're a bad idea and then you have to unlearn things. You're maybe expecting some of that if you've years of C programming experience, but there's no need to introduce an idea on Monday only to tell students on Tuesday that it's a bad idea and they must never do that.
The most insidious cases are where something is legal and correct in C but it's wrong in C++ yet it will compile and you maybe have broken software. There are some nasty type punning examples, where the pun was an idiomatic C expression which does exactly what you wanted, but in C++ that's Undefined Behaviour and all bets are off. You'd just never teach those type puns in a pure C++ course, they're never the Right Thing™.
There is a considerable divergence of opinion on that subject. In my view, C++ isn't remotely suitable as a programming language for someone without a healthy understanding of C. Perhaps a dialect of C++ could be developed that was more of a cousin to Rust, but C++ as we know it is a C like programming language with a very large number of features added and all the ways to fail just like a C program does. There are real world advantages of course, but it is not a language for the faint of heart, not even close.
C++ isn't remotely suitable as a programming language for someone without a healthy understanding of C.
I always look askance at folks who say they know C++ but not C. The C++ abstract machine is built over the C abstract machine and it becomes even more clearer when you go down to the binary level.
Depends what you mean by "understand C". As you say, understanding the C abstract machine and memory model is critical for a C++ programmer.
Understanding C idioms, the standard library, best practices, and general C software architecture , is less important if not downright negative early in your formation. You will end up picking a lot up anyway if you stick to C++ long enough.
is less important if not downright negative
"Less important" maybe but not "negative".
You have to have a decent C base (not necessarily expert level with knowledge of dark corners/tricky idioms/etc.) before you start with C++. One example is being comfortable with raw pointers. I often see "Modern C++" proponents say you should never use (and by inference learn) raw pointers which is absolutely counter-productive. It is also easier to learn C++ as a "better C" in the beginning else it becomes overwhelming. I believe this is the main reason most beginning C++ programmers find the language "scary/difficult/huge/overwhelming/confusing". They are trying to learn everything at the same time which is an impossibility with a language as baroque as C++.
The main use of raw pointers in practical standard C++ is that they still don't have an analogue of Option<&T> so raw pointers (which can be null) let you write analogous code albeit in a less friendly way.
But this isn't so much like C, where raw pointers often express ownership.
You aren't going to really learn "everything" in C++ anyway, regardless of how you approach it, the language is a vast sprawling mess, the fact somebody wrote a serious book just about initialization [https://leanpub.com/cppinitbook] in C++ gestures at the problem. Freeing themselves of the need to have a language which is well-defined, or which can be demonstrated to be sound, or really follow any principles whatsoever was doubtless briefly convenient but the result is unmaintainable nonsense.
The use of raw pointers in C++ which you deem analogous to a Rust feature is your view and not that of the vast majority of C++ programmers. Raw pointers in C++ are the same as in C and the usage techniques are up to the programmer.
As a diehard proponent of Rust your views on C++ are well known and there is nothing new here. But the fact of the matter is that the industry runs on C/C++ and the main reason is due to its baroque set of features whatever one may think of them.
By "negative" idioms I'm mostly referring to stdio, string.h (except for memcpy/memmove of course), goto-based cleanup, void* based generics, overuse of macros and a certain fondness for global mutable state in a lot of classic C codebases.
Disagree here. Given the language's limitations, everyone of the idioms you list has its place and uses. They are just a way of structuring code for different abstractions.
Can you maybe share some paid/unpaid resources to learn C++ from scratch for someone coming from Java and JS?
Kate has a PluralSight course which I have watched (not really to learn C++ but to see her approach) and that seemed decent to me, although of course I can't vouch for it having taught what you'd need coming from Java and JS, not least because my background is far more polyglot including Scheme and the Standard ML for example.
I definitely think Bjarne Stroustrup's book about his own language isn't very good, even in later editions (which correspond to a more modern language) and so I would avoid buying that, I'm not sure it's a good defence of the language as an idea and I'm sure it isn't an effective tutorial, even if not for being out-of-date.
That doesn't address the constraints that are typical in embedded systems such as limited memory (RAM) and the expectation that a program will run forever.
There are resources oriented toward embedded C++ that address these (at least memory allocation.)
On a project a couple years ago I was pushing to use C++ instead of C, if only as a "C compiled using the C++ compiler" for better type checking. I could not convince the project lead, who's technical depth far exceeded mine, that the C++ compiler was as likely as the C compiler to produce correct translations.
I wouldn't worry about the compiler producing correct code, I would worry about the heap eventually fragmenting enough that an allocation fails (perhaps thousands of hours after the program launches). I know C++ offers the ability to supply your own allocator, but it's not for the faint of heart.
I will go through the course before Xmas. The thing is that in bare metal development even C standard library is not always being used. Recently I wrote some string processing functions for very specific parsing task. Nobody would need such crap while working with operating system.
It depends on what you target. I do alot of Kernel and really low level C++, and it's a completely different style than even app dev, so you have to be sure you don't go down the completely wrong route.
For my target space, there's a few rules for c++.
Footguns: A. No STL, it causes to much bloat when binary size is critical. B. (almost) No inheritance or virtual functions. Again, it causes some bloat and adds in some instructions and code to support these features that can cause issues in low level environments.
Things to learn (All work in the kernel):
A. Learn templates, especially c++20. Templates add ZERO bloat, they literally just generate the function again with proper types the same way a macro would.
B. Use RAII.
C. Use constructors and overloading.
D. Zero pointers should be exposed to code except where absolutely needed. If you need to pass by reference, use the c++ style.
E. All allocations should be wrapped in a class with RAII. You can overload the operators on the class to make it seem like a pointer so you can still do if(!RAIIPointer).
A good video on kernel c++ is here https://www.youtube.com/watch?v=AsSMKL5vaXw . You can use a surprising amount of C++ language features in the kernel and it makes it extremely smooth and safe if you do it properly.
I think you missed exceptions often being a problem in low level and embedded targets. That knocks out most of STL anyway.
I also think you are a bit harsh on virtual functions - it introduces a single indirection, yes, but sometimes that is fully justified. RTTI on the other hand... of course depends a bit on target characteristics.
Perhaps controversial, I've also found (especially bare) lambdas and even std::function objects useful, although may evolve into something purely static when the dust settled. Highly dependent on target of course.
It will be interesting to see the final form of the new MISRA std, since the active one predates all of this.
If you can't use the STL because of exceptions: https://www.etlcpp.com/
Sure, there are more embedded friendly libraries, but that wasn't the topic.
It’s almost as if this is some sort of discussion board where people can expand on the topic as they see fit :D
You can use quite a lot of STL even with -fno-exceptions. Things that you probably need to ditch are:
std::vector
std::list
std::map
std::unordered_map
std::set
std::unordered_set
std::sort
std::transform
std::merge
std::string
std::regex
std::swap
std::function
std::stable_partition
But there are much more than that in STL.
True: "most" was a stretch.
No STL, it causes to much bloat when binary size is critical
A. Learn templates, especially c++20. Templates add ZERO bloat, they literally just generate the function again with proper types
"Avoid STL due to bloat but embrace templates" doesn't make sense to me. Isn't that exactly what code bloat is? Too much code generation?
Bloat can also refer to the invisible infrastructure code that's compiled into a binary when using certain language features. C has a fairly linear relationship to the size of the compiled assembly, iirc, but C++ will vary wildly based on which features you use.
Indeed, it is a common refrain among C++ programmers to inspect ones binaries, I have found ..
I would add constexpr (I guess it might be included with templates?).
You can do some nifty stuff like generate CRC lookup tables at compile time without hardcoding them.
Yes! 100% Right, can't believe I left that out. One of the big things is to make sure to use ConstEval if you can do a new verson of c++(20), since ConstExpr isn't guaranteed and can leave stuff in the binary that can hurt size or obfuscation. For example one thing I see alot is lookup tables for hashing who use constexpr and hide some key data in there, but it "may" just randomly do it, and can cause alot of issues.
How does the use of ConstEval address this issue?
Do you want to do embedded/low level c++, or are you looking to transition out of that?
I will get out. Application development using C++ and Python. Maybe C#.
1) Real-Time C++ by Christopher Kormanyos. - For using C++ in embedded systems.
2) Software Architecture with C++ by Adrian Ostrowski and Piotr Gaczkowski. - Gives the overall picture of how to use C++ plus relevant modern tools as a complete development system.
3) The C++ Programming Language by Bjarne Stroustrup. - The bible/reference with programming techniques for the language.
Learning C++ is not difficult and don't let the size of the language intimidate you. Survey the different ways of programming in C++ i.e. Imperative/Object-Oriented/Generic/Meta-programming and use them as needed in your project without trying to master everything; that will only happen over time as you gain more experience.
I’d recommend reading Effective C++ books from Scott Meyers and trying to interview for the jobs you’re looking for over taking a course!
If you want to understand the C++ in terms of C code then probably you would need to understand the C++ object model. I mean, how C++ classes are translated into C equivalent code. If you are interested in these you can take a look at a tutorial I wrote long back https://www.avabodh.com/cxxin/cxx.html
If you want to write bare metal C++ then this page from the above tutorial will be useful https://www.avabodh.com/cxxin/nostdlib.html
If you want to transit to higher level jobs you may get better mileage out of broadening to other languages (e.g., python) or skills (e.g., project management) than from a C to C++ transition. My 2c.
This is maybe a very unpopular opinion, but if you go from C to a higher level language, I would advise to steer away from C++, certainly if it's would be your first OO language.
You can definitely start putting C++ into your embedded projects, and get familiar with things in an environment in which you're already operating. A lot of great C++ code can be found with motivated use of, for example, the platformio tooling, such that you can see for yourself some existing C++ In Embedded scenarios.
In general, also, I have found that it is wise to learn C++ socially - i.e. participate in Open Source projects, as you learn/study/contribute/assist other C++ developers, on a semi-regular basis.
I've learned a lot about what I would call "decent C++ code" (i.e. shipping to tens of thousands, if not hundreds of thousands of customers) from such projects. I would suggest finding an open source C++ project, aligned with your interests, and study the codebase - as well as the repo history (i.e. gource) - to get a productive, relatively effortless (if the interests align) boost into the subject.
(My particular favourite project is the JUCE Audio library: https://juce.com/ .. one of many hundreds of great projects out there from which one can also glean modern C++ practices..)
I've been setting up my little docker image that has both llvm/clang/tidy/clangd and gcc inside with boost with an idea I'd run it and from outside use it to code with live checking and compiling without littering my OS. Now, I feel like I'm doing something that already exists but couldn't really find what everyone use, ought of those that would prefer such a setup. Debugger within is probably a pipe dream, but who knows.
Basically I'd prefer to have a docker image with tooling that I can hook into.
I find it absurd that a programming language which compells someone to set up a containerized OS just to manage their build toolchain could be considered "modern".
I install Rust's toolchain and development tools inside of a container, I also do this with Python and will do it with C++ sometime in the future.
I don't do this because I have to, I do this because I prefer to keep non-system -critical software managed by non-root users and separated from the systems rootfs.
On your common desktop Linux distro, I think C and C++ toolchains are the least difficult to setup and use without a container though (for me). On Gentoo I can just emerge gcc or clang and enable whatever USE flags I want, and they are installed and updated automatically with the rest of my system.
I use the Gentoo system package manager to manage my Rust toolchain as well instead of using rustup, so that it behaves like described above, it's updated and managed automatically and with the rest of my system!
I do realize that many distros have issues with software being out of date though, and that is a big problem! With Gentoo I can install multiple versions of most things in parallel and can very easily package anything that doesn't exist yet.
Also to clarify, I use the system package manager to build and manage my containers, this is how I use the system package manager to manage Rust's toolchain but also have it inside of a container. All of my containers are just nested Gentoos that I can install stuff into with the system package manager. I can also install a package manager into the nested Gentoo and build/install stuff while "inside" of it.
On your common desktop Linux distro, I think C and C++ toolchains are the least difficult to setup and use without a container though
In my experience, the hard part is rigorously controlling the libraries a build uses. Using CMake, it's easy enough to add libraries to a build, but harder to stop the thing going off and looking round /usr/lib64 and so on. On my physical workstation, there is all sorts of stuff in there, because i have a desktop environment and a cornucopia of tools installed. I don't want a build using any of it! If a build needs a library which i have not explicitly added, i want it to fail, not use something from the system. But between default paths and rpaths in libraries and so on, that seems hard to do in a watertight way. I've done endless fiddling with sysroot flags, but i'm not sure it's not leaking. A container takes care of all that in a very definite way.
I install Rust's toolchain and development tools inside of a container, I also do this with Python and will do it with C++ sometime in the future.
The thing is, you don't need to do this with Rust as far as I can tell. There may be some benefits, but ultimately your project can easily specify its own compiler version, its own target directory (the default is per-project), etc. There are some shared resources like caches, which you can split if you want to.
I can see why you'd still do this - but, the main reason would be... if you have dependencies on C/C++.
I'd be really interested in a write-up of your setup with more details so I can try it.
It would truly be absurd to claim that C++ is a modern language. A subset of C++ however, is modern. This does not include the toolchain and standard build practices.
Your point stands, but it is/was implied, how I took it at least.
I guess that's why i went into JavaScript instead of java. I use to write HTML back when i was around 10 years old, back then java applets were the only way you could have something interactive and dynamic on your page, so i started to learn it. After a while i learned that you could do a lot of neat stuff with JavaScript. So i stopped using java.
I cannot disagree. Gcc is trivial to compile and set with prefix however you want. Llvm behemoth, not so very much though and I'd like to have both for reasons. There's always some gotcha involved, and when you finally set it all up, you forgot what and how you did it and then you dig through shell history file to reconstruct what you did in order to replicate it on other machines or same if you nuke the OS.. blah. Rustup and cargo and pyenv and nvm even spoiled us.
VS Code is designed to work with these - https://code.visualstudio.com/docs/devcontainers/containers
Interesting, thanks for that. That's kind of the idea, but preferably without the 'extend' part on top of containers. I'm not using VSCode though so I'll shop around or maybe I'll convert, who knows.
Maybe nix (https://github.com/NixOS/nix) is a better tool for what you're looking for if you're on Linux, you can setup nix shells and work in them, what's installed inside the shell won't be accessible from outside.
As is with most people and nix, it's on todo list to check it out. This might be the trigger. Thanks!
"A Little History of C 3/3" says that C was used in the special effects for Star Wars. I do not know what relevance this has, honestly, but independent of that is the strange choice of photo: an image from the Empire Strikes Back which shows stop-motion models with optically-composited, rotoscoped lasers. Excepting that this may be from the digitally recomposited Special Editions, no C code was used in the making of this shot.
Watch Lights & Magic on Disney+ and you will understand why the reference is in there. ILM, Pixar, WETA had huge influx on graphical swe... hell even photoshop was a sideproject of ILM at the time.
Care to enlighten those of us who don’t already know the explanation?
ILM was and is an absolute software engineering power house and they started with motion controlled cameras for star wars at the time all their in house software was c++. A lot of software which is still used today. Pixars Renderman, Photoshop, Maya... was initially engineered at ILM or Lucasarts which were subsidiaries of Lucasfilm.
Thank you. That makes sense
Maya was an Alias|Wavefront product, which was a subsidiary of SGI. It came along way after Pixar had been spun out of ILM. John Knoll, who co-developed Photoshop with his brother Thomas, is still at ILM as the CCO.
Isn't the wireframe death star scene the only part done in C (and therefore by computer) in the first movie?
https://cdm.link/2021/11/watch-larry-cuba-explain-how-he-ani...
Yes, done by Ed Catmull himself.
Heap Memory - new, delete Keywords
Should "modern" C++ even use new/delete? I'm a C++ n00b, but I thought these can be avoided entirely now.
I noted that - IMHO one of the big advantages to "modern" c++ is the focus on the lifetime of objects with smart pointers rather than the mechanics of heap allocation and pointers. Pushing that down to chapter 19 as "Advanced Topics" seems like a mistake. Arguably the same with std::array vs object[] - the first should "probably" be the default now for teaching new programmers, so covered first (or at least highlighted when discussing array[]-style variables)
I also note a number of the possibly-ambiguous c-style casts in examples, despite already having mentioned the explicit versions (static_cast and the like).
Plus there seems to be a fair bit of system & machine dependent stuff mentioned like it's /always/ true - like stack being at a "higher" address space than the heap and code sections, or the stack growing down. It also says that the Data section is "slower" than the stack which... isn't true? If they're spilled out of registers, they're likely functionally identical? Or at least for small microbenchmarks depend on specific implementation details, like how the pointer to the object is calculated and dereferenced.... And object size and cache interactions... And a million other things...
And that's just the first few chapters I looked at :P
Smart pointers should really be like, chapters 2-10.
In my experience, every useful C++ application requires wrangling some historic smart pointers implementation: Boost, Unreal, libwebrtc, Qt.
Even NVIDIA uses its own smart pointers (thrust::device_ptr) though that's understandable. Also there's stuff like this: https://stackoverflow.com/questions/65938991/how-to-use-lamb... for e.g. TensorRT.
Not entirely - you can't generally use std::make_unique with private constructors.
Yes, in new code you should be able to replace almost all new and delete with unique_ptr, vector or, more rarely, shared_ptr. Placement new can still be useful, but delete not really. There are some patterns where you use new without a delete for a global singleton that is intentionally never deleted, as well.
It's still useful to learn about the concept when dealing with old code.
It's explained later in the course
What is the C++ job market like? I do mostly Python / web app developmnt, but I don't like the churn.
If you are strong in C++ you can get pretty good jobs in robotics, trading, game engines. But TBH at that point it might be more interesting to learn Rust that is on the rise across the industry.
Nobody (except hobbyists and maybe an indie or two) is using Rust for game development, and it's unlikely they ever will. The cost of switching far outweighs any benefits in an industry where memory safety is not critical.
C++ is here to stay for a very long time.
Treyarch gave a GDC talk in 2019 that they were using it for tooling, Embark hasn't shipped a game in Rust yet but is larger than an indie. You are absolutely right that it is small right now, but "unlikely they ever will" is a more open question, IMHO.
Memory safety is absolutely important in certain kinds of games. At least, as a player, I want games to not be exploited for cheats, and I don't want progress lost when a game crashes due to memory issues.
All that said, I would agree that if you want a job in games, learning C++ is a better idea than Rust right now.
Having “spent some time in the job market lately”, the salaries seem astronomical if you’re C++ and fintech/HFT. I think some funny business is going on with those listings though…
Kinda average in game development and sadly pretty low in embedded systems.
All way less common than your average Python position, but probably way more interesting.
I'm not sure if you're in this field specifically, but since you mentioned it I'll ask. Is it your impression that fintech and HFT shops would possibly start to transition to Rust?
I've always heard that they're currently mostly using C++ (and sometimes Java). But I'm not sure how dogmatic or change-averse they are on average.
looks good,is there one pdf for all chapters?
I have cloned the repository then combined the chapters using pdftk:
pdftk *.pdf cat output Modern_Cpp_Programming.pdfon airplane with a phone so can't do that,wish it had a download link for the full PDF,will create when I am back to my pc
Termux?
This worked on the Mac. I had to install pdftk (brew install pdftk-java) first. The result is nicely formatted for reading on an iPad after importing into Books.
There are at least a dozen C++ intros that go through every little detail like this and I don't get it. I have a pretty good ability to retain a lot of information presented this way, and I've been programming in various C-like languages for long enough that much of this isn't new to me, but this doesn't seem like a good way to learn the material. I'd much rather work through actual programs and iterate on them. I imagine that a lot of people who would be looking for something this basic aren't even going to retain most of this nor understand why they would need most of these things they are memorizing.
I think C++ and Rust are honestly special beasts. I've heard experienced programmers say that you want to actually pick up a book to learn Rust, and the same is true for C++.
Like you can basically hack your way through learning Python or JS. I didn't learn Python from a book, for sure.
But with C++ and Rust that's not an optimal strategy. You have to do both -- do practical projects, and actually study it a bit.
There's also a huge amount of disagreement about C++, so I think it makes sense to start with a codebase you want to work on, and then ask the people who WROTE that codebase what C++ books and learning materials they like.
e.g. Game C++ is kind of different than Google C++, but both are good (they get work done, and multiple people can work together in that style). There is a lot of really bad C++ out there. The gulf between good and bad C++ is bigger than good and bad Python or JS. You want to learn from experienced people who get things done, not language lawyers
I virtually always read a book to learn a new language. My point is that memorizing every language feature as a starting point is not a great way to learn, but almost every C and C++ book/tutorial/course seems to do this. There is a reason why people love K&R's C book.
I agree with your grievance: Many c++ tutorials are basically like: these are the internal workings of how the graphite in a pencil is structured, now go draw the rest of the owl.
I am not saying that this isn't important, but learning about pointers and references is totally useless unless someone shows you why you would use them, where you would use them etc.
I think Kate Gregory makes similar good points about the structure of C++ learning materials here:
One thing that would have helped me when I started learning C++ was learning the C++ compilation model i.e. translation units.
It is surprising how many people look surprised (that also claim they know the language) when you tell them that code in .cpp does not get inlined into other .cpp files no matter what doing compilation. (yes the linker can (and should) do that with LTO doing linking)
This also helps understanding why template code completely wrecks compiletimes and ram usage since the compiler cant share template instantiations. This becomes very relevant if template metaprogramming is used in bigger projects.
That's not why. Template processing happens during processing of the translation unit, so it would be expensive even if you only had a single TU in your build. It's true that a template has to be reprocessed for each instantiation, however, that's not merely from one TU to the next, but even inside each TU! For every distinct value of T for std::vector<T> in a single TU, the compiler has to process and generate std::vector entirely
Compilation units are mainly about symbol visibility and as you already realized at the end of your comment don't have anything to do with inlining as far as the C++ standard is concerned. Neither does the inline keyword btw.
The linker doesn't inline anything, LTO/LTCG is about running (part of) the compile process at link time. But that's really no concern for the C++ code but an implementation detail of the toolchain - you could just as well not have a separate link step and instead have the compiler process all compilation units in one step.
yes, LTO itself does not inline but from a user point of view it does, and that is exactly my point. If you are a beginner and you do not come from C, then you might not think about these things (maybe you do I did not).
I get that it is just an implementation detail, but so are many things in C++ and you usually care about these things otherwise you would not be using the language in the first place.
Many projects also disable exceptions that is also an 'implementation detail' (or at least something that is definitely not required by the standard I would imagine), but now you are technically not writing C++ anymore.
I guess this is also one important thing when learning C++. The community is very fragmented, and there seems to be disconnect between C++ users and committee.
This course is a bunch of presentation slides. The idea that you can learn anything from slides is rather silly. Learning from slides is almost as bad as learning from random youtube videos.
Slides can be an extremely good medium for learning. Because brevity is required by the format, slides can require a lot more thoughtful attention to emphasize and carefully explain key points than the long-form text format. I think the course looks really nice!
In fact when I read a book I do little cards, like slides, with the most important information condensed. I find a good method.
YouTube videos are fine, at least they have narration. With slides you're kinda left to infer your own story and lessons.
All channels with reputation at some point were random (except the ones from universities maybe)
I picked C++ back after a long break and I have to say in reasonably recent iterations (like C++17) it's good enough, although OOTB Unicode is a PAIN. They should have solved it in C++11 and moved on. It's a disgrace.
Does Carbon or c++next fix the ootb handling?
This is just an idea at this point. Ask again in 30 years.
It's being actively worked on for C++2x. This video is a fairly recent update on how it's progressing: https://www.youtube.com/watch?v=AoLl_ZZqyOk
Note for those who are not used to C++Now talks: they are intented to be a bit more informal with regular interjections from the audience (who at C++Now are also often heavily involved in the development of the C++ standard), so don't think people are being rude by jumping in!
Hopefully it's really good in the near future. https://thephd.dev/cuneicode-and-the-future-of-text-in-c
Is there a good guide on the toolchain? What do people use today to keep sane? Something like meson, ninja or cmake? I have inherited some project in scons that was generating msvc 14.1 project and I can heartily recommend against that
Meson or CMake. Neither one is really all that great, I would say personally that Meson is better in theory but CMake is more widely supported so I prefer Meson but it's pretty even. Either one is better than just an enormous makefile. Ninja is a different level of the stack, you can use meson+ninja or cmake+ninja.
Either way the C++ dependency management situation even makes the Python dependency management situation look good by comparison.
Either way the C++ dependency management situation even makes the Python dependency management situation look good by comparison.
Is there a better way than “script the compilation of all dependencies and share the result” for any big project that has to support Windows? I’m interested in alternatives.
At least on Windows I quite like vcpkg for dependencies.
I think nowadays smart pointers should not be considered an "advanced topic" in C++. Smart pointers are usually the best way to handle memory management.
It's definitely useful to learn about "new" and "delete", because those are the primitives that memory management is built on top of. But it should be followed up with good advice like, rarely use these in practice. You should almost always be using unique_ptr or shared_ptr instead of new'ing up pointers that you intend to explicitly delete later.
You should almost always be using unique_ptr or shared_ptr
I really wish there was a thread unsafe version of shared pointers, without atomics overhead, in the standard. Maybe without weak pointers.
If there's one thing C++ needs, it's more slightly-different varieties of smart pointers in the standard. ;-)
What exactly would you use these for? I find that usually I can get away with unique_ptr for the sort of object that I have many of where pointer performance matters.
Some sort of problems where you throw trees around. Almost interpreter like programs, where trees are arbitrarily stored on different places. And where you for some reason don't want a proper GC ...
How many interesting SE jobs use C++ anymore?
Is anyone using it for new projects?
What's your definition of interesting?
Compilers , OSs, browsers, VMs, Databases, scientific experiments, high performance systems, HPC, video games, complex desktop applications, simulations.
In fact the question should be: what interesting projects don't use C++?
For some very subjective definition of intersecting of course.
This is obviously very subjective, but C++ is used in many interesting fields: robotics, graphics, signal/image processing, physics/game engine, ...
I'm currently doing some backend work, and I really miss it. I don't think I've done anything interesting algorithm-wise since I switched. Alas, the pay is usually much better in SaaS land.
When they say modern, which standard to they mean?
It's described in the course, but canonically this means at least c++11 (and these days, likely 14/17 in practice - there is broad toolchain support)
Literally in the title of the linked page:
Modern C++ Programming Course (C++11/14/17/20)
I like to watch Formula 1 and NASCAR races. As interesting as seeing the cars pushing the limit of materials and mechanics is just as interesting seeing them crash. It shows the flip side of design. I wish this sunny-side tutorials had at the end of their books some black pages with the hall of horrors. Weird compilation messages and pointers getting demoted and random segfaults in real scenarios. We all remember the inverted wings in the F1 cars and vehicles literally taking off when the body loose close contact to the ground. Now in NASCAR the roof flaps come off when the car gets slight bump and the front wheels loose traction. C++ Is not a risk averse language.
I’m quite fond of the C++ frequently Questioned Answers: https://yosefk.com/c++fqa/
"Note: some parts of the FQA are not up to date with C++11/14/17. You can contribute to the FQA on GitHub."
LOL, yeah I think we can stop spending time on this (which was quite funny back in the day).
Anyone went through this and can compare it to https://www.learncpp.com/?
learncpp might be more beginner friendly and more verbose
If you prefer to read a book rather than read slides: http://www.icce.rug.nl/documents/cplusplus/
I get 404d on that page. For others: you can download it (in various formats) through here: https://fbb-git.gitlab.io/cppannotations/
(You might have to jump through some links)
Also, fancy seeing someone else from RuG here :)
I’m curious, if you were going to learn a general purpose lower level language today what would you go with?
perhaps zig... the new cool kid on town
or pascal.
Table of Context
Table of Contents?
It is of type <T>.
FWIW, the creator of this course is a team lead at NVIDIA, and principal software engineer of CUDA cuSPARSE.
Just what I needed to brush up my long forgotten from University C skills, but I would prefer practical coding tasks for each part.
With the context of learning Modern C++, and the author's association with nVidia and CUDA, I share this anecdote: Partially if it helps anyone directly, and partially as an opportunity for someone experienced with C++ to poke holes at it.
I've had great success using ChatGPTv4 to help me write modern C++ that works with CUDA, using prompts like these. (I have not attempted to get it to write parallelized code given loops/serial code as an input):
Please convert this Rust code to modern C++, compatible with the latest version of the nvcc CUDA compiler: ```rust ```
It will output a compilable/working result, and explain each of the language differences in question. It will make sure to use `std::*` instead of the more rigid C-derived equivalents when able, and take advantage of looping over array pointers etc, vice i++ loops. `auto` var types etc.
Do we have a curated list of similar programming courses for other programming languages?
This brings back horrible memories at uni.
Can someone explain how to read the Conversion Rules section in the second chapter? I haven't seen this style of notation before. For example:
Implicit type conversion rules, applied in order, before any operation: ⊗: any operation (*, +, /, -, %, etc.)
(A) Floating point promotion
floating type ⊗ integer type → floating type
(B) Implicit integer promotion
small integral type := any signed/unsigned integral type smaller than int small integral type ⊗ small integral type → int
(C) Size promotion
small type ⊗ large type → large type
(D) Sign promotion
signed type ⊗ unsigned type → unsigned type
C++ was my weapon of choice in college mostly because writing graphics stuff in C required re-inventing the wheel a lot of the time for basic data structures and the STL was pretty slick.
Having spent the better part of the last decade writing go though, I think C++'s syntax is a bit too cluttered.
Just read the first pdf. This is an interesting quote.
"Every second spent trying to understand the language is one not spent understanding the problem"
Did a lot of work in LaTeX the last few years and they make C++ looks like something made in heaven
Looks comprehensive. I’ll take a look.
I did not enjoy the compile-edit-debug cycle when I was using C++. Have there been any advances in the area off a C++ REPL?
Any ideas where to start learning C++ as an embedded developer? I wrote many lines of bare metal C code and want to transit to higher level jobs. I see many expensive or completely free courses, but I am not sure which one is usable in my complicated situation.