I am always grateful that people spent their time to create resources like this. This looks good and I would recommend it to someone who isn't a total newbie.
I also find it very interesting to look at the pedagogy of these sites. In the case of this site, it starts with a lot of history and computing. This is common for books, but asking a new user to wade through so much preamble before any 'meat' is asking a lot. In the first part where code is shown/explained:
is a lot of upfront jargon for a newbie to process. ('pre-processor directive')
It does do a good job of showing how to set up visual studio. However these days, a htttp://repl.it is surely a MUCH easier way to get up and running.
I wrote a very small ultra-beginner guide for a young relative to learn C. It gets right into what C code looks like, makes connections to the math they have seen in school, and tries to hold back terms until they are really needed (omitting details where needed)
It isn't polished designed for widespread use, but I think for the truest beginners its better than other guides I found on the web.
At one point in time I thought C++ was too complicated since I was only familiar with Java, Javascript, Python. I feel I didn't understand the reason for the complexity.
Then I began to study algorithms and then code generation at the assembly level. I've written very little assembly. But I want to generate assembly. This puts me in a difficult position.
Today I think C++ is fascinating as a language because it has wide implementer support (cppfront, MSVC, GCC, clang) and it is well defined as a language.
Someone can read the C++ standard documentation and implement a compiler for generating assembly for that AST. That's fascinating. Especially for a language as advanced as C++.
I am also fascinated by metaprogramming and C++ templates. I needed to learn how to use C++ templates to use coroutines with threadpools in C++. Can't say I understand them completely but I understand how we need to provide specializations to the compiler so it knows how to generate code for different cases.
I feel there's a missing orthogonal specification of computation that is cleanly compilable. As with Rust, with C++ there is many programs that are wrong by arrangement of tokens. It would be better if most arrangement of tokens are valid programs, due to semantics of the language not being subtle.
I feel there's an omitted abstractions when it comes to code generation. The languages we use to represent computation in and relationships between things are rather low level. Mutable state is very difficult to reason about.
You should absolutely not use or recommend that site. It's stuck on incomplete C++14 at best and also contains some pretty bad code. learncpp.com is a much better tutorial and cppreference.com is a much better reference. The only thing cplusplus.com is good at is polluting search results.
Back when I was a software engineer, I used to constantly hear how bad cplusplus was. Yet, in spite of this, I'd fairly often find myself using it because the results were just so much easier to parse.
Just as an example, cppreference doesn't have a page dedicated to std::string (when you search for it on Google, it tkes you to std::basic_string) whereas cplusplus does.
Even comparing the two pages, cplusplus immediately gets to the point that std::string is just a std::basic_string<char>, whereas cppreference has three paragraphs of technical minutiae before it finally points out what std::string is.
Even though cplusplus is out of date and incomplete, it's still often more useful than cppreference when you're trying to get your head around STL for the first time.
cppreference has a steep learning curve with how information dense it looks, but once you’re up to speed you can move a lot faster with the standard library. I find it’s the site I always have a tab open on.
I haven't done any C++ since 2015ish but your link seems incredibly outdated.
Sure you'll learn some C++ syntax, but you'll learn the C++ from 20 years ago, not the modern C++ with smart pointers and all that stuff which is basically turning it into a new language.
as someone that has done a lot of commercial C++ teaching in his time, i would say that this is one to avoid for a beginning programmer. stroustrup is not, imho, one of the worlds great teachers, and i would not recommend C++ as a first programming language. more experienced programmers should go with TC++PL.
Interesting. I'm sort-of experienced (never pro, but lots of little projects in JS & Python. I got Principles to try and fill in gaps in my basic knowledge & so far it seems like it has been helping. I'm a little over halfway through. What else would you reccommend?
This is essentially why C++ is here to stay. I've wasted a lot of time fiddling with bindings despite knowing C++, and ultimately the best answer is to just do most of your work in C++, and write application-specific bindings for Python/Lua/whatever if you really need to.
As a C++-head with little experience in Python - I would ask you to elaborate a little. What were trying to achieve with Numba, that gave you headaches?
I still wish it had better navigation design, like a side bar for easy access to the ToC, or a drop-down menu for the same thing. I have to use the back|forward to do that.
cplusplus.com is out of date, but it has the simplest and easiest web interface to me comparing to either learncpp.com or cppreference.com, super easy and simple to navigate: https://cplusplus.com/doc/tutorial/
Is this website any good? It's heavily pushed by some C++ subreddits.
I don't even know what I would recommend to a newbie. I learned C 25 years ago, and dabbled in C++ 2 or 3 times since then.
Bjarne's books might be great, but they aren't for anyone new to C++ and especially not anyone new to programming in general. C++ For Dummies/21 Days style books are just bad. And there are more bad websites than I can count.
Although I find the order of topics questionable, at least they talk about undefined behavior instead of saying blatantly wrong outdated stuff like "a read out of array range will just result in some garbage value being read". I've read some random pages and nothing stood out as blatantly wrong, which is already a high bar for a C++ course.
C++ is awful for beginners exactly because of undefined behavior, no good book can fix that, IMHO.
As for topics covered, talking in details about linkage, functions, constexpr, bit manipulation before if/for statements is, uhm, questionable, if this is aimed at beginners. Then the site talks about type conversions, function overloading, structs, and arrays only appear somewhere in the middle. Moreover, much simpler std::vector is introduced _after_ C-style arrays. Wild ride for a reader, but one can argue such order is more "academic", whatever that means.
One example is that he uses a header file called "std_lib_facilities". So right out of the gate it confuses people, it's not actually shown until a little later in the book, there's tons of questions on C++ forums and StackOverflow where people get stuck on it.
I used to be a C++ dev before moving to Java/Python. I'd like to go back but there seems to be few roles for people that aren't up to date experts. Is this the case? I'm not sure if the C++ shortage is like the COBOL shortage or a genuine active community that is growing.
I regularly see ads searching for C++ developers. I'm in an automotive-heavy region in Northern Europe. C++ is widely used in HMIs, AD/ADAS, and general service development (diagnostic services, middleware). I also see the need of C++ developers in medtech and automation companies around here.
The ads request some experience, but in practice they are happy to recruit what they can find.
Some technologies change, so does C++, but not so long ago I landed a C++ gig for €80+/hr, although being more of a ANSI C90 expert, only used C++ occassionally (for test environments mostly), and being completely out of synch with the "latest" concepts of modern C++ and its tooling (as a reference, std::move was new to me; CMake was an annoying bigger sibling of Make). Customer was happy until that Chinese virus became a fad.
C++ is huge and growing every 3? years (C++17, 20, 23...) is it really possible to master or can you only ever get to the point of being good enough to be dangerous?
You end up mastering a subset of the language. Typically whatever you use at work or in your free time. Whether that subset is 10% or 90% is kind of up to you.
There was an old joke about everyone using a different subset of C++ but like most jokes it's mostly an over exaggeration.
C++ (and C) have amazing backwards compatibility and there is a strong chance that code written 30 years ago will still compile, link, and run as long as the dependencies haven't also changed too much (I'm looking at you Win32, X11, Motif). That gives you the time to migrate code bases over time without the fear of being left behind and unsupported.
Even if, for some reason, you were writing C++98 for the last 30 years, it shouldn't be too difficult to make the jump to newer standards. The biggest change, in my opinion, is lambdas and move semantics, and it's not to difficult to apply those to an old code base (if you want to) and start modernizing it. Some people say C++20/23 is a new language but the fundamentals of C++ haven't changed too much and I'd say it's easier to learn C++23 coming from C++98 than it is to learn Rust coming from C++98.
>Some people say C++20/23 is a new language but the fundamentals of C++ haven't changed too much and I'd say it's easier to learn C++23 coming from C++98
I generally advise people wishing to learn C++ to read Bjarne Stroustup's 2nd Edition of The C++ Programming Language (TC++PL) first. All the Basic language features are there and it is manageable (i.e. C++98). Once they have an idea of this subset they can then move on to later standards eg. TC++PL 4th edition for C++11 and A Tour of C++ 3rd edition for upto C++20. This demonstrates the evolution of the language and brings home the point that there are orders of magnitude more C++98 code then C++11 and later.
You don't have to learn it all at once and a lot of that new functionality is useful (I've used features from both C++17 and C++20 recently). I agree that learning C++ is hard though and there aren't good resources for new developers. Largely I think this is because C++ excels in domains where performance is important or where working directly with the OS/hardware is required and people working in these areas generally already have a pretty good programming background and so don't require as polished learning materials. I learned C++ by working on a big project (millions of lines of code) and being forced to figure it out as I went to be productive. I already knew C well at the time but that's not as big a help as you'd think since modern C++ is very far from C unless you are making lots of syscalls.
a lot of c++ is there to support library writers worried about efficiency, rather than application programmers concerned with good-enough, maintainable code if. like most people, you are in the latter category, you can write pretty good code without worrying about all the bells & whistles of the later releases.
This tutorial does not include modules, the best feature in C++ in a while. Is there a modern c++ intro or tutorial that includes CMake, modules, concepts, etc?
The constructor used here will not be the copy constructor. There will be just a single construction, of a1, and it will be the "int ctor", i.e. `A(int x_)`.
Copy initialization does not mean that the copy constructor is called. It is the correct term for an expression `T a = ...;`, which can often result in the copy constructor being called but does not have to. In this case it's mandatory copy elision from a prvalue, which leads to only one constructor being called.
You are absolutely correct. It turns out "copy initialization is the formal term used. It's kind of stupid IMHO, since it may not be initialization by copying or using a copy of anything, but:
The problem with it being many many moons ago is that C++ has evolved so much since then that that course is now so outdated it's pretty much irrelevant.
> I think a lot of “modern” languages get this right by including these things from the start. The experience is so much better.
I don't know how others did it, but I learned with MS Visual C++ in 1996.
File -> New Project -> press F7 to compile, F5 to debug. That's it. ~30 years ago they got it right. I even remember my Windows CE experience ~15 years ago that allowed to build and debug the entire OS from an IDE.
Now you have to open your command line and write like it's 1985.
Today VS is free (Visual Studio Express?), with analyzers, tests, vcpkg, etc. There is also Qt and other similar tools that I use for embedded like Keil, IAR, Eclipse derivates, etc.
C++ != Makefiles. I don't write Makefiles or fiddle with the build system since... ever?. Except for some AOSP stuff that still uses them or perhaps editing some linker script for embedded.
PS: that said, "experience" is relative. Having to use the command line in general but mostly for learning is terrible.
But at least I can see the commands being ran by `make` and work backwards from there. In VisualStudio you have to click around in a bunch of “Properties” menus (which may or may not have search boxes…) and eventually you may find what you’re looking for.
I've always thought it was a little bit pathological that we require application developers to also be experts in build and deployment. The parts that can't be automated away should be handled by (highly paid) specialists so when your dev is deciding whether to make a change they don't have to factor in how it gets from their box to production.
In addition to building, it will show how to add cppcheck and clang-tidy to your cmake files. That part is pretty easy. Just don't turn on every check in clang-tidy. Many of them are for specific code bases. Modernization checks are my favorite ones. Keeps you doing stuff the modern way.
My link has you doing dependency management with git submodules. That is a method still in use and even advocated for, but conan is often touted as the more modern way to do it. I've used it on some teams, and I'm undecided. I also have no good resources for it.
It's been quite a few years since I've really written any C++ and I'm surprised the landscape hasn't evolved at all. People are making the same mistakes...
Modern CMake should be using toolchain files to specify the toolchain/flags. That should be included in ever CMake intro. (Hacking those into your CMakeLists.txt is not okay)
gitsubmodules are also a hack
1: Many dependencies are not setup to be used as a CMake subdirectory. Variables such as the project-version-number get overwritten by the parent project and more dangerously the submodule can start to change variables in the overall project.
2: Dependencies will often reuse target names. For instance, libraries often have a target called `uninstall`. Because redeclaring a target in a different subdirectory is a no-no - CMake crashes
Proper dependency management can be done directly through CMake without repeating yourself by using Hunter: https://hunter.readthedocs.io/
This solved the diamond problem, gives you proper namespaces in CMake and with Polly you can have sane toolchain files (https://github.com/ruslo/polly - but you can also just write them manually). Everything is built on CMake and Git (and git hashes). You get nice dependency build caches and forking dependencies is also trivial
EDIT: The creator of Hunter has his own CMake Intro. I haven't gone through it while-learning, but it looks comprehensive and informative: https://cgold.readthedocs.io/en/latest/
> Modern CMake should be using toolchain files to specify the toolchain/flags. That should be included in ever CMake intro. (Hacking those into your CMakeLists.txt is not okay)
this so much. I made a toolchain generator to make myself toolchains with common set of flags (asan, lto, etc specified with a single simple word on the command line for each "feature" or at worst a "key=value" pair, e.g. "compiler=gcc", "linker=lld") and really it made my life so much better: https://github.com/jcelerier/cninja
Git submodules are definitely a hack. My experience with conan has been unpleasant for several reasons, but mostly in regards to writing dependencies for code bases that use submodules and aren't interested in my team's suggestion they use conan. Vcpkg doesn't seem better, and probably a bit worse. Does hunter make this any easier?
If the dependency you want to use has no dependencies of its own - then it can be used directly with no changes (as long it's CMakeLists.txt is sane and it can use a passed-in toolchain file)
If the dependency has its own dependencies, then you need to "Hunterize" it - specify library versions, tweak the targets to use namespaces, etc. They're usually small changes. They have a huge list of Hunterized forks:
A minimal CMakelists.txt will look something like:
HunterGate(
URL "https://github.com/cpp-pm/hunter/archive/v0.23.297.tar.gz"
SHA1 "3319fe6a3b08090df7df98dee75134d68e2ef5a3"
)
project(Foo)
hunter_add_package(Boost COMPONENTS regex system filesystem)
find_package(Boost CONFIG REQUIRED regex system filesystem)
add_executable(foo foo.cpp)
target_link_libraries(foo PUBLIC Boost::regex Boost::system Boost::filesystem)
The first block specifies the available package list (you can fork and host your own). If you disable Hunter this isn't used
The line that reads `hunter_add_package` is the Hunter part that downloads and build the dependency (using the current toolchain file). But if you disable Hunter then that line would simply get skipped.
In the third line `find_package` will run.. and if you had Hunter build the dependency then it'd use that as the target - otherwise it just runs like "normal CMake" and it tries to find the package elsewhere (like from your system package manager or whatever)
If your dependency has its own dependencies as git submodules.. then I'm not super sure you have a very clean migration path b/c they will not be using `find_package` and will instead be using `add_subdirectory`. Maybe you could patch their CMakeLists.txt to use Hunter when explicitely enabled, and then drop down to `add_subdirectory` otherwise. It'd be a bit ugly but they would keep their workflow I guess. You'd need to check that their targets end up with the same namespaced names (with the :: notation) when seen from your project... I don't know off the top of my head how Hunter handles a subdirectory with a project name of it's own
Sorry I wasn't clear. I was responsible for the dependency that another team was using as a plugin. They weren't going to switch to conan, and our code was already using Conan for itself and its dependencies. They wanted to bring us in as a submodule, and that was just never going to work. I think what I'm pulling out of this thread is that c++ package management is so fragmented, there isn't really a safe choice to ensure you can use or be used by people who made other choices.
Oh okay - I think in that case it's possible Hunter would solve your problems. If you rewrite your library to use Hunter, then when it gets pulled in with add_subdirectory(), it should just build and get it's dependencies with Hunter - all from within CMake itself. No external tool necessary (the Hunter functions are defined in the project root `.cmake` file)
I don't see any reason that wouldn't work - but.. you'd have to test it. I've never tried running a Hunterless top-level project with a Hunter-ized subdirectory. The top level project would still get some benefits like the namespaced targets (so you won't clobber anything in top-level)
The only small catch is that Hunter inevitably does build a cache of build artifacts/targets for your dependencies. As long as you keep using the same toolchain files these keep getting reused each time you rebuild your project. That does however mean you will get some user folder like ~/.hunter with those build artifacts (look at the Hunter config options.. maybe this can be somehow hidden in the build directory?). I dunno if that would irritate the project users. If it's company internal that's probably an okay ask. If it's random devs on github then that's a bit not-nice :)
Thanks! That looks like it might be fine. The conan cache works the same way but all our builds and deployments are containerized so the ~/.conan wasn't the issue, it was that conan was in control, not cmake.
Honestly, I find the usage of the adjective "modern" deceptive and insincere in the marketing term "Modern CMake". The "modern" scripting language doesn't even support return values and the variables lack basic type-safety. It breaks for anything beyond a simple Hello World.
I would recommend any other C++ build tools that use a proper programming language for scripting, be it Meson or Bazel.
I dislike cmake, so when a sibling post mentioned meson I went looking. It doesn't seem to have good support for cuda, and neither does bazel, to the point I don't immediately find anyone getting it to work. These days the only reason I start a project at work in c++ instead of rust is to use cuda, so that would be a strong consideration. Is this easier than my brief glance would indicate?
I have yet to encounter problems with Cuda in our Bazel environment, but I don't have to maintain the Bazel rules, since our build infra team does that.
I would think that rules like https://github.com/liuliu/rules_cuda should work for you in Bazel. (Tensorflow also uses Bazel, so I don't think that this should be a problem.)
This is a good idea. Most modern languages have their own build tool which handle most of these things, so this requires some separate learning with C++.
Some ideas for a curriculum:
Context
- C++ as a standard, compilers as implementations
- a build tool's role in handling compilation and linking
- compilers having limited abilities, having limited warnings and analysis by default
Build tools
- evolution: e.g. make -> autotools, cmake, meson
- focus on meson as the build tool of choice (personally I'd avoid CMake since it has a lot of legacy baggage)
Testing
- gtest/gmock
- catch
- designing for testing
Analysis tools
- why you should care: security, catching bugs
- cranking up built-in compiler warnings to reasonable standards
- external tools like clang-tidy, cppcheck
- sanitizers: address sanitizer, leak, thread, etc.
- fuzzing
Dependency management (probably the toughest, since it's still a mess)
- history: usually just relying on system packages, or installing libraries globally from source
- Conan (probably the best option for simple dependencies that's actually catching on)
In a C++ course we teach at the Technical University of Munich (for students coming from a non-CS background), this is pretty much the direction we have recently steered the curriculum. It is amazing how we were always expected to "just figure out" all these very important practical aspects by ourselves as students, while these are so complicated for C++. In combination with a lot of outdated material out there, students end up feeling lost and giving up, or going through a lot of pain to develop even simple projects.
> It is amazing how we were always expected to "just figure out" all these very important practical aspects by ourselves as students, while these are so complicated for C++.
In france when I started engineering school (early 2010s) we had classes about:
- using the shell, emacs, being at least basically proficient unix tools
- using make, cmake, configuring compilers etc
wild that it isn't more common, this explains a lot!
I always thought the pain was the point. They wanted you to struggle to figure it out, it’s how you learned how to learn. If everything is spoon-fed you end up unable to solve your problems when they arise. You expect someone else to have solved the problem and you start looking for them instead of attempting to solve it yourself. Kinda like the main plot point of Enders game.
I understand your point, and I had to argue on it a lot when introducing such changes. I think the answer is struggling for the right task, but again with some guidance. If the learning outcome is to learn to program, then I don't see why you should waste half a semester trying to figure out by yourself the technicalities that could help you go beyond a hello world. Similarly, I don't believe we should (nowadays) force people to write everything in the terminal using Vim. The additional cognitive load is too distracting that it prevents you from digging deeper.
One can say "but that's how I learned, and I am fine and shine today". This is probably true, but then I believe that such a person had the right background to anyway learn by themselves. I see our mission as teachers to help the students that actually need the help, rather than letting them give up too early, in favor of some kind of excellence evolution. And I believe that if we prepare the right groundwork (explaining all the ropes before we start pulling them), then even the more advanced students will be able to learn even more that they would by themselves in a more struggling environment.
I feel the same way. I remember in one of my failed attempts to learn C++ I had been at it for a few weeks, and was excited to start my own little project in it. I needed to use a piece of software on GitHub and I just could not figure out how to get everything to build. It was a terrible experience that put me off the language.
Pulling in dependencies in C++ when you come from something like Python or Ruby is the absolute worst. I just recently fought through a big mess of this, the gist of it is ExternalProject[1]
Conversely, systematically starting a tutorial by listing and briefly explaining the important sections that will not be covered in order to avoid confusions during reading really help newcomers and make them confident.
I agree and that would be great. I'd also love a place to learn design with feedback. Should I use a friend function? Free function? Separate class? Abstract class? Should I create a separate folder and start a module?
It would be great to have something where you try an implementation, get feedback, and try again maybe a few times and then are presented with a few ideal options that you might not have tried.
Build systems and dependency management are not a part of the language, they're a part of the OS you're developing on (and sometimes for). Or maybe one of several alternatives available for that OS.
As a Java dev who learned C++ at university the hate towards C++ is misplaced.
C++ is a no thrills language which lets you have freedom but freedom to also shoot yourself in the foot 100+n ways, but this gives you a good foundation as a developer IMHO.
Every time I think about garbage collection in Java, I can appreciate that I am not having to write code to destruct an object or worry about passing references incorrectly.
I've been getting back into C++ after an extremely long hiatus and I've been impressed by how thoroughly modern it is. The worst crime you're likely to commit these days is accidentally invoking a copy constructor more often than you want to, and even then, not actually creating leaks.
In fact, the most striking thing coming from a language like Java or C# isn't memory management at all, is how utterly non-OO C++ actually is, especially the standard library. I understand how key the zero-cost tenet is in C++, but it's very alien to be picturing an interface and thinking you'd like an Iterable<char> or IEnumerable<char> there, but having to learn about iterators and traits and concepts etc. To be honest, there are equally many functional affordances in C++ as OO ones at this point, but the native core is generic programming, which is very idiosyncratic.
Even when C++ was created, object-orientation was not a goal, but rather a means to an end. Yes, that was a significant feature, and the original name was "C with objects", but even then it was only part of the bigger picture, and that part got smaller over time. The next big step away from an OO-orientation of the language (no, that's not a typo) was when the STL was adopted into the standard library - with its iterators and templated mini-algorithms. At that point it could certainly be said already that C++ is a multi-paradigmatic language, and that's become even more true over time.
You could definitely (?) implement a Java-like container framework, with class like Iterable<char> or IEnumerable<char> and almsot every OO bell and whistle - if you wanted to. But it would not be very useful.
> The worst crime you're likely to commit these days is accidentally invoking a copy constructor more often than you want to, and even then, not actually creating leaks.
As much as I like modern C++, use after free is still way too easy to commit. But if you stick to value types and mostly don't store references/non-owning raw pointers, then it's OK.
I switched from C++ to Java too. Still, every time I type `new MyObject()` without a corresponding `delete` I feel like I got away with some sort of crime ;)
no, it really isn't. mostly you don't need to manage objects dynamically at all (make them automatic) but if you do, use something like std::make_unique(...)
I haven't used Java since school so I'm curious about modern Java. Do you need to worry about circular references preventing garbage collection or are there easy tools to detect such cases?
As a newbie into programming, I get pulled all the time by people to learn my first compiled language either in C++ or Rust. Every time I ask even the most innocent question in any forum it becomes a shitshow, and I can see, I'm late to the party here in HN.
Please do not start with either C++ or C. They are horrible, horrible languages to learn as a beginner. Not because of bad tooling, incompatible compilers, tons of features, or even manual memory management and pointers, no.
Two words: undefined behavior. In other languages, if you do a mistake, something fails around the place where you did it, or at least afterwards, or at least you can reason why the failure is exactly where it is. In C++, you cannot. Accidental array bounds overflow? Too bad, now your program crashes in a completely unrelated closing bracket (not even a statement) five minutes later.
In other languages, if your program does not crash and produces a correct answer until point X, you can be more or less sure that everything afterwards at least gets corrects inputs. Not in C or C++: if there was an UB before point X, the program may look like it does random things: some stuff is printing, some stuff is shown in the debugger, random lines are executed, arithmetic operations make no sense, perfectly valid functions crash: https://stackoverflow.com/questions/54120862/does-the-c-stan...
People grow by challenging themselves and this certainly applies to programming. One can’t use training wheels and expect to become skilled at system programming.
I learned C++ as an absolute beginner in school back when most memory debugging tools didn’t even exist. Undefined behavior was just another bug that one learned to fix and most of the time it was nothing more exciting than a crash. Being disciplined avoided the problem in the first place…
People really have a tendency to dramatize C++. Yes, memory errors are a significant problem for people writing operating systems or browsers that get attacked all the time. For a beginner C++ can be much more fun and instructive than any so-called safe alternative.
Absolutely, but it's much easier to understand arrays, strings, functions, loops and structs as high-level concepts first, and continue to manual memory management and UB only afterwards, rather than trying to do everything at the same time.
C++ is fun for sure, it was (and is) fun for me, but it's a very specific kind of fun.
Tooling did help this situation somewhat, but it is not very discoverable.
If a beginner started off with a clang or gcc toolchain, then I would immediately suggest the following command line options for the compiler (the exact standard version does not matter, just stick to one):
If you're really new, I'd say either python or c# (unless you have a goal in mind). C++ and rust are both a lot more difficult to learn if you don't have any background imo. The scoping and memory management rules will distract you from learning the basics. Something like python with jupyter notebooks is pretty much perfect for learning or putting together quick projects, and c# to me feels like a more forgiving c++ with a less crufty stdlib.
Plus rusts strict memory management rules don't really translate to other languages, and c++ has a habit of changing wildly. The c++ of 10 years ago barely looks the same whereas python and c# feel less like the goalposts are moving.
I'm already fairly deep into python, kinda knowledgeable in JS to make some minor stuff and currently I'm practicing a lot with git. After than it comes Java (i'm following a self-paced bootcamp path).
Java seems interesting from an employment perspective, but the small stuff I've touched seems extremely verbose. I feel like I have to write and think way more to do simple stuff. But I just had a brief introduction, I guess I can get used to it.
I wanted a compiled language that allows me to tackle some interests I have, and I feel It will be c/c++ wether I like or not, because one of my interests is fiddling with hardware. Nim can compile down do C apparently but it isn't widely adopted.
The reason I mentioned c# is because it feels like "if Java adopted new features at a decent rate" and these days pretty much all of it is MIT licensed. Coming from Java to c#, I found it much more ergonomic and productive mostly due to less boilerplate and more concise syntax sugar. There are several ways to compile it to native if you need to and it has great c/c++ ffi support, although if you're doing a lot with microcontrollers you'll end up writing c/c++ eventually. Luckily a lot of big langs (c/c++/c#/Java) have similar syntax and concepts since they all sort of started from c.
I'd suggest waiting until you learn some java/c# before starting on c/c++, or instead starting at old school c (k&r c) or arduino c++. Modern c++ is a beast to learn.
Learn whatever you really want to. They are just 2 tools, and either of them will teach you something. You can't make any mistake, if your plan is to learn and maybe build something simple. If you want career advice, that's where things might get a little bit religious...
I'm just a little further down the road than you are and the best course seems to be to learn a little C++ first because it will help inform why Rust works as it does. Then when you try Rust, if you hate it, you've still got C++.
I used to agree with this, but I would actually now suggest doing the inverse.
Rust will beat you over the head with a way of thinking that carries nicely back to C++, and the tooling (Cargo, etc) is more comparable to what someone coming from another language ecosystem would know. Smaller things like Rust's decent support for functional programming seems to click with everyone I know who's dabbling from the JS world.
Another way to put it is: Rust is world's best c/c++ teacher. Once you understand and surpass borrow checker, your c++ code will be much less error prone.
I like zig, the simplicity, and explicitness especially, the meta programming is really cool, but having now experienced the borrow-checker, I don't think I'd ever want to program without one. Rust isn't simple, and on occasion, it isn't sufficiently explicit for me, but it has a borrow-checker.
For those reasons I'm very excited about Austral. The borrows, linear types, and the notion that anything that isn't explicit is wrong, all appeal to me.
Nothing wrong with that, besides I think the people that only stick with one language are rare these days. It was more humor than anything, and I agree with you. I spent the last year or year and a half or so using Rust quite a bit more than I'd originally anticipated, and it's been cool in a sudoku way that tests my chin scratching abilities from time to time..
Personally I'd say that unless you're going into game dev where C++ is still widely used (or you want to work on legacy codebases that are in C++), learn Rust instead. Or even learn C rather than C++. C++ has a huge gap between the modern and proper way to do things and the old footgun-riddled way of doing things, and it's just a mess.
Statements like these only serve to polarize people, not encourage them to write safer code / use safer languages.
There are many places where C/C++ (and many other non-Rust languages) are still used, and where it would not be feasible at this time to fully rewrite them in rust.
Modern resources like the OP posted should be encouraged, as they actively teach about proper use of the language, and foot-guns to avoid (e.g. don't use c-style strings + strcpy, use smart pointers, etc).
I have been writing in C++ for most of my professional career, I wrote company-wide guidelines, I still teach and consult. I absolutely agree that C++ is not going anywhere anytime soon. That being said, so is smoking. We can't just tell people not to smoke anymore, we live in a free society. But we really shouldn't drag more people in.
Similarly, sorry, but C++ is doomed to be forever solely used for (a) maintaining codebases that noone wants to maintain but doesn't have a choice, and (b) organising cpp conferences to maintain self-confidence of a crowd of programmers whose skill set is becoming more and more outdated.
Rust is essentially C++ done right. It isn't as aggravating as C++ but it is the same technology essentially. It doesn't bring anything new to the table. It's yet another LLVM frontend.
We need to look into something far more fascinating like http://www.spiral.net/ Something that creates value a mere compiler, which is a technology from the 50s, can not.
Because we live in a free society and smoking is a proper right. It is unhealthy and largely outdated habit but if you want to light a cigarette, you can.
Programming in C++ is also an outdated habit. There are better languages, better technologies, and there are generally better ways to create software than writing code, compiling the code, replacing std::abs with abs (real issue, these are different functions) and recompiling the code again. But writing in a horrible language is a proper right as well. People write in Brainfuck for fun and good for them!
I also find it very interesting to look at the pedagogy of these sites. In the case of this site, it starts with a lot of history and computing. This is common for books, but asking a new user to wade through so much preamble before any 'meat' is asking a lot. In the first part where code is shown/explained:
https://www.learncpp.com/cpp-tutorial/statements-and-the-str...
is a lot of upfront jargon for a newbie to process. ('pre-processor directive')
It does do a good job of showing how to set up visual studio. However these days, a htttp://repl.it is surely a MUCH easier way to get up and running.
I wrote a very small ultra-beginner guide for a young relative to learn C. It gets right into what C code looks like, makes connections to the math they have seen in school, and tries to hold back terms until they are really needed (omitting details where needed)
It isn't polished designed for widespread use, but I think for the truest beginners its better than other guides I found on the web.
https://avsteele.com/C_Programming/