Search

C.1 — The end?

Congratulations! You made it all the way through the tutorials! Take a moment and give yourself a well-deserved (insert something you enjoy here).

Now, after breathing a long sigh of relief, you’re probably asking the question, “What next?”.

What next?

By this point, you should have a solid understanding of the core C++ language. This sets you up well to continue your learning journey into other adjacent areas. So if there’s something you’re really interested in learning about, now’s a good time to see whether you have enough knowledge to jump into that.

However, for most users, I think there are a few natural next steps.

Data structures and algorithms

If you haven’t already learned about these, this is my strongest recommendation.

A data structure is a collection of data and a well defined set of methods to access or manipulate that data. The most common data structure used in programming is the array, which holds a number of elements of the same type in sequential memory. You can manipulate the data inside an array by using array indexing to directly access (or modify) the elements inside the array. In the lessons, we also covered the stack data structure, which provide push, pop, and top functions to access the data on the stack.

An algorithm is a self-contained set of operations that typically manipulate or calculate outputs from the data in a data structure. For example, when you look through an array to find the median value, you’re executing an algorithm. Binary search is an algorithm to determine if a given value exists in a sorted array. Sorting routines (such as selection sort and bubble sort) are algorithms that sort data sets.

Over the years, mathematicians and computer scientists have come up with a fairly standard set of reusable data structures and algorithms that are useful for constructing more complex programs. These all have various tradeoffs. For example, arrays are fast to access data and sort, but slow to add or remove elements. Linked lists, on the other hand, are slow to access data and sort, but very fast to add or remove elements (if you already know where those elements are).

Why does it matter? Let’s use an analogy. If you were going to build a house, you could build all of your tools from scratch if you wanted. But it would take a long time, and you’d probably mess quite a few things up and have to start over (ever created a hammer? Me neither). Also, if you use the wrong tool for the job, your quality would suffer (try nailing in nails with a wrench).

More likely, you’d go to the local hardware store and buy a few tools: a hammer, a level, a carpenter’s square, etc… and then read some internet tutorials on how to use them properly. These would vastly accelerate your house construction efforts.

Data structures and algorithms serve the same purpose in programming: they are tools that, if you know how to use them, can vastly accelerate how quickly you can get things done at quality.

The good news is that many of these data structures and algorithms have already been implemented in the standard library. You’ve already encountered some of these in the preceding tutorials: std::array, std::vector, std::stack, std::string, and std::sort, to name a few. Learning to use these effectively and appropriately is a great use of your time.

If you’re short on time (or patience), learning how to use the most common data structures and algorithms is the minimum you should do. But if you have the inclination, try recreating those data structures yourself, from scratch. It’s really good practice on writing reusable code, and will help you down the road when something you need isn’t in the standard library. But then throw them out, and use the ones in the standard library. :)

The C++ standard library

The bulk of the C++ standard library is data structures and algorithms. However, the standard library contains other things too, and another next step could be to explore those. Among other things, there are numerics (math) libraries, input/output routines, functions to handle localization and regionalization, regular expressions, threading, and file access. Every new release of C++ (which has been happening about every 3 years now) adds a batch of new functionality into the standard library. It isn’t critical that you know how everything in there works, but it’s worth at least being aware of what exists, so that if you happen upon the need for it, you can go learn more as needed. https://cppreference.com/w/cpp is my go-to reference for discovering what exists.

Graphical applications

In our tutorial series, we developed console applications, because they’re easy, cross-platform, and don’t require installing additional software. Unlike many modern programming languages, C++ does not come with functionality to create application windows, or to populate those windows with graphical elements or graphical user interface widgets (checkboxes, sliders, etc…). To do those things in C++, you’ll need to enlist the help of a 3rd party library.

Getting a graphical application up and running requires a few additional steps. First, you’ll need to actually install the 3rd party library and connect it to your IDE, so you can compile it into your program. Most graphical libraries should come with instructions on how to do this for the most popular IDEs. Next, you need to instantiate an OS window, which requires calling certain function from the toolkit. Most, if not all, of the libraries should have sample programs that you can compile and dissect if you’re not sure how to do something basic.

There are a lot of libraries out there, and which one you should use depends on your requirements (you’ll have to do your own research to determine which one is right for you). Popular choices include Qt, WxWidgets, SDL, and SFML. If you want to do 3d graphics, all of these frameworks support OpenGL, and there are great OpenGL tutorials on the internet.

Graphical applications typically run differently than console applications. With a console application, the program starts executing at the top of main() and then runs sequentially, usually stopping only for user input. Graphical applications also start executing at the top of main(), typically spawn a window, populate it with graphics or widgets, and then go into an infinite loop waiting for the user to interact with the window (via mouse click or keyboard). This infinite loop is called an event loop, and when a click or keypress happens, that event is routed to the function(s) that handle that type of event. This is called event handling. Once the event is handled, the event loop continues to run, waiting for the next bit of user input.

TCP/IP / Network programming (aka. the internets)

These days, it’s pretty rare to find programs that don’t connect to the internet, a back-end server/service, or leverage the cloud in some way. Any program that requires you to have an account and log in is connecting to a server and authenticating a user. Many programs connect to some service to check whether an update is available. Social applications maintain a persistent connection to a social infrastructure, to allow users to communicate with each other on demand. These are examples of networking.

Networking (broadly) is the concept of having your program connect to other programs, either on your machine, or on network-connected machines, to exchange information. Networking is a powerful tool -- in the past, if you wanted to change the behavior of your application, you had to release an application update. Now, with some good program design, you can simply update information on a server somewhere, and all instances of the program can leverage that change.

As with many things C++, there are libraries out there to help make your C++ programs network capable. The Asio C++ library is a commonly used one (there are two variants -- a standalone version, and a version that integrates with Boost, which is a library that provides a lot of different functions, much like the standard library).

Multithreading

All of the programs we’ve seen in this tutorial series run sequentially. One task is completed, then the next one starts. If a task gets stuck (e.g. you’re asking the user for input and they haven’t entered any yet), the whole program pauses. This is fine for simple academic programs, but not so great for actual applications. Imagine if your program couldn’t handle the user clicking on something because it was busy drawing something on the screen, or if the whole program paused/froze when a network call was happening. The program would feel unresponsive.

Fortunately, a method exists to allow programs to execute multiple tasks at the same time. This is called threading. Much like how (most of) you can walk and chew bubble gum at the same time, threading allows a program to “split” its attention and do multiple things in parallel.

For example, some graphical applications (such as web browsers) put the rendering (drawing graphics) portions of the applications on a separate thread, so that updating the screen doesn’t block other things (like accepting user input) while the drawing is happening. Network calls are often done on separate threads, so that if the network call takes a while to resolve, the application doesn’t grind to a halt while its waiting.

Threading is powerful, but it introduces additional complexity, and a lot of room for additional errors. Therefore, I wouldn’t recommend starting here -- but it is a good area to learn about eventually, especially if you want to do complex graphical applications or network programming.

Improve your fundamentals

Another option is to spend time improving your understanding of best practices. For this, I highly recommend having a read-through of the CPP Core Guidelines, with an optional delving into the GSL library.

A good bye!

At this point, I’d like to take a moment to thank you for stopping by and reading this tutorial series. I hope you enjoyed your time here and have found this site useful. Special thanks to those of you who have helped keep this website a free resource available to everyone by viewing ads that interest you. Please drop by again!

Good luck (and skill) in your future endeavors, and happy programming! And remember, old programmers never die -- they just go out of scope.

-Alex

PS: If you have any feedback or other suggestions for things to explore next, please mention them in the comment section below.


No next lesson
Index
B.3 -- Introduction to C++17

285 comments to C.1 — The end?

  • choofe

    Hi
    Just want to thank you that made my 15 years dream came true.
    This was incredibly fun and comprehensive tutorial I ever face.
    Thank you
    Thank you
    Thank you
    Good luck and keep up.

  • robinchaz

    hey great tutorial thanks alot guys!! But i want to take my c++ game to the next level such as going low latency aspect/low level(my aim is to be a quant developer).I have browsed through many online resources such as what books should i read and practicing DS and algorithms.So i have a few questions:
    1.Do you think best practice books such as "Effective c++, tour of c++" are still reading and going through them before i start on more advance/modern c++ books?
    2.Do i have to study some computer architecture to understand multi threading all these effectively?

    Do you have any other suggestions to go down this route efficiently!I am willing to be consistent for a few years but i just need a rather specific guide direction. Thankyou for your time!

  • David Lund

    Hi Alex,
    I just wanted to say thanks for this amazing tutorial! It's been a great resource to learn the basics of the language in detail.
    You have a great way of explaining things at the appropriate level, with very descriptive examples that help make the point!

    Perhaps one thing that could be added to this "C.1 — The end?" section would be an additional resource list, for further reading about various C++ topics?
    You've for example mentioned "The C++ Standard Library", by Nicolai M. Josuttis. And an excellent book I've read is "Effective Modern C++", by Scott Meyers.

    Thanks again, to you and to Nas!

  • P. Lam

    Hey, thank you for these lessons!
    I appreciate the time you guys took to put all this together.
    Cheers!

  • Tushar

    Greetings,
    Finally completed all the lessons!
    I wanted to say a proper Thank You to Alex and Nascar driver for the whole Site/Project. This site has helped me so much learning c++ from scratch but at last, completing it.

    Thank you for all the replies you gave in the comment section they couldn't have been more explanatory. :)

    Just a suggestion it would be better if there was some kind of newsletter that could keep people updated about the changes and the new lessons updated. [Lambda -- Looking forward to learning this].

    Thank You again.

  • Nsikan Ikpoh

    Thanks Alex and nascardriver. This tutorials have been so helpful in sharpening my c++ skills.
    I'll recommend it to friends. May God bless you!

  • Paprika

    Thank you Alex and nascardriver!
    I have make lots progress of my cpp programming skill.
    It took my about 2 months to go over all the topics of the website.
    Appreciate and i will recommend these courses to my friends.^^

  • Erik

    Thanks a lot for all of this <3

  • zakaria

    Hi Alex and nascardriver!
    I would really like to thank both of you for this amazing tutorial, it was really a blast to read it all.
    I usually find it hard to get into anything programming related since Im not really good at math, but this tutorial really just doesnt need any rquirements before reading it other than a brain and a computer, and I love that!

  • Rejemy

    Hello Alex and Nascardriver!

    Thank you very much for this amazing website, you both have great educational talent. Even though I took some C++ classes back at school, I always felt like my knowledge remained shaky. I feel way more confident now after reading your tutorials. :)

    I'll definitely check out tutorials on OpenGL as a next step, I've always wanted to learn what graphical applications are made of.

    Keep up the excellent work!

  • ERF4N

    Thank you man!
    It was very perfect.
    I hope you are more successful.
    Only help that I can do, is introduction the Islam. Investigate it, Maybe you liked it :)
    And thank you very much again ...

  • HurricaneHarry

    Greetings!

    Finally wanted to say a proper Thank You to especially Alex and Nascardriver for the whole Site/Project, but also all the other people that asked questions and brought up topics that helped understanding!
    The last couple of weeks I've been digging through github repos looking at projects while stepping into SDL.
    As Unity, because of COVID19, made their "premium learning" tutorials available for free  I thought it would be a nice additional insight for program structuring and C#, as I wanted to have a look at the differences to C++ anyway.
    And well, I can just say I'm missing the "premium" for most of the courses there in structuring, depth... everything. At least of what I've seen so far. So even bigger h/t to Alex and ND!

    kinda more @Nascardriver
    When looking through github almost all of the more serious projects with visuals also made "quite a bit" use of threading. So I'm doubtful about starting an (even slightly) bigger project without it. Reading the comments on learncpp I saw you were discussing that topic, so I wanted to ask if there are ressources you'd recommend?

    So, thanks again and gl!
    Though I can't promise I won't be pestering you again from time to time. ;)

    • nascardriver

      Hey!

      Glad you enjoyed it :)

      I can't recommend a resource for threading, and there won't be a lesson about it any time soon. The fundamentals, namely threads and mutexes/locks are pretty easy to understand. Using them properly requires practice. Write you own multi-threaded renderer, eg. with opengl, to get a hang of it.
      There's a big update in C++20 for asynchronous operations. I don't yet know if it will make some of the current threading features obsolete.

      • HurricaneHarry

        Greetings!
        My own renderer? Quite far away from that, I fear. ^^

        Right now I'm trying to set some more of the fundamentals for a (somewhat) bigger project. Been pondering about, well, storage structure layout or whatever it would be properly called. I just call it "proper polymorphic/generic object storage" for now and stress the omnipresent animal analogy once more.
        My idea so far was to set up a kind of manager singleton responsible for the creation and management of an "animalDB" that's supposed to keep track of all created animals on a map or whatever the final use may be.
        But as there are no virtual typedefs (afaik) creating one DB holding different derived types isn't easily possible ofc. Generics are no solution here, as a templated animal<dog> is distinct from animal<cat>. So CRTP can't help here either as it causes the same problem.
        Of all the more or less awful feeling "solutions" I could come up with, the least awful ones would imho be:

        #1: create a special storage struct that
        - contains a pointer member field to every possible child class
        - contains an enum reflecting the slots
        - a field to store the enum of the actual stored object
        - a get() function (and maybe some others for convenience)
        #2: a separate DB for every child class
        - plus a "parent" DB to coordinate them
        - but that seems like a maintenance nightmare, even more error prone than updating the struct of #1.
        #3 scrap parts of the inheritance and cram everything also in the base animal class
        - in the end kinda similar to #1, just on a different layer

        The downside of the first would be the wasted space, but in case of pointers it would at least be minimal compared to the data stored behind the pointer, and the mechanically unconnected but dependant code snippets. (container class fields etc.)
        So far I tend to either #1 or #3. With 3 probably being the easiest but most limited or most bloated approach. What would be considered good or at least acceptable practice in such a situation? I can't help but all feel some kind of wrong.
        So far I haven't found a source that shed a satisfying bit of light on this topic.

        • nascardriver

          Either you're thinking too hard or I don't understand your situation. As long as your animals have a common base class, you can store them in a single container

          If your `Animal` is a template class itself, add a non-template parent to `Animal`. If you want to solve this without virtual inheritance, use `std::variant` and `std::visit`.
          If I misunderstood your situation or you need help with something, please let me know.

          • HurricaneHarry

            Maybe I overcomplicate it. The problem is the moment I provide information about the derived class to the base class for example with CRTP:

            the basic animal class is no longer universal and can't be again itself. AnimalGrip would solve this but be pointless by prohibiting access to the pointer cast.
            My intent was to provide information in the base class instance about the level of derivation of the actual object, to keep the base class as minimalistic as possible and solve extended access via casting.
            But ofc that's at least as much a structural design aspect. For example it makes sense to have a virtual printAnimal() function in any animal instance, less so a getToxinInfo(). But that could ofc be included in a printAnimal() override for the related child classes.
            And if the need arises to handle it separately sticking to the basics and using a simple premade switch to determine the proper cast is probably the most sensible thing to do in the end.

            • nascardriver

              First time I see a CRTP implementation, I can't guarantee the correctness of my reply.

              To make `convert_to_original_pointer_type` work, you need to know the type (`T`). If you want to store mixed Animals in a container, they can't have different types, so you don't know the type for `convert_to_original_pointer_type`. You could create a `std::variant` for all Animal types, but that could get large (Long type and many includes), and you wouldn't need `convert_to_original_pointer_type` anymore, because the `std::variant` gives you the correct type already.

              I'd drop CRTP and use dynamic polymorphism. That way, no class has to implement more than it needs or makes sense on that level. You can access the shared functions through an Animal pointer and if you need a specific type, you can safely get with via a `dynamic_cast`.

              • HurricaneHarry

                Greetings.
                Oh my... more than 3 month already. Sry, didn't want to be impolite. Thanks for your comment. For that specific example I went with a uniform component design so to say. So every aspect of the class was represented by the same struct und thus could be accessed easily. So every class was actually the same. Probably quite unperformant because the content of the fields was often checked, but worked for that small test program.
                For the last 2 month roughly I'm getting my nose bloody on a slightly bigger project (feels actually a lot bigger to me...), and that's a small game. Imho the best for having something somewhat graspable and also different aspects tackled. Getting some informations on that matter is quite fast, telling trash from treasure... less so. Decided to go for SDL, and so far I have a tilemap that gets parsed and rendered, a very basic physics system with circle/rect rect/rect and circ/circ collision check and a bit more, and a couple placeholder objects with input. Plus some simple state-management systems. Trying to puzzle together a menu- and GUI-system right now. Also asking myself if I should have used SFML instead as a first go, as there at least are textboxes and such available.
                Btw, I'm not really satisfied with my rendering managers render function. For debugging and ease of use purposes I want the function to render some standard, always present, texture if for some reason the proper one isn't loaded, as well as rendering the whole texture instead of only a part if no width/height of the source snippet is given. The latter sounds like the perfect situation for function overloading, sadly because of the used parameters automatic resolution fails.
                Right now my code looks like this:

                What's your opinion on this? Is there an apparent more elegant solution? Also the std::map as the texture container... one of the things I read quite often was to use a map for this.
                But so far I can't really make up why to use one for this. Vector or arrays have a constant access time while it increases for maps, unless I'm mistaken. And so far it's small, but with game objects going it'll probably be crowded quite easily, even with all the sprite-sheets I'm planning to use.

                edit:
                sry for the formatting problem, but it's for whatever reason misbehaving horribly.

                • nascardriver

                  Your map/vector/default texture questions can all be solved by using an access function to get the texture rather than accessing the container directly. If you want to switch out the container later, it's only a couple of lines to update. If a texture can't be found, return a default.

                  Whether or not you can use a vector depends on your use-case. If all textures are always loaded, you can use a vector. If this isn't the case, you'll have to fill the vector with empty textures, nullptrs or similar, which is wasteful. If you use a map it doesn't matter if all textures are loaded, because only the ones that are loaded will take up any space. Imagine launching a large game and it tries to load all textures of all maps. You probably don't have enough memory to run such a game.

                  Seeing that you use a string as a key, you can't use a vector at all (without additional work).

                  Line 10-14 and 18-22 are very similar. They don't need to be conditional if you update `width` and `height` in case either is 0.

                  Large amounts of parameters are bad, you won't have fun calling this function.

                  Putting it all together (Doesn't compile)

                  • HurricaneHarry

                    Thanks again for your reply!

                    The parameter combination was something I already thought about, but put it back so far.
                    Was a bit shy of using another function call in such a frequent function, but indeed the maintainance plus seems to be worth it.

                    Also the width/height reset, ofc returning by value so that's no problem... "doh!".

                    But... string_view... I remember... there was something...
                    Problem is, I can't use it in this context because, for whatever reason using any newer g++ version with SDL2, SDL_image and SDL_ttf results in "Procedure entry point not found" errors when running the compiled program. Compiling something else without SDL works fine. And SDL with older g++ works too. I'm not ruling out errors on my side, but I read online that this kind of thing can be a problem related to compiler/version conflicts in libraries.
                    But maybe you have an idea where else such errors could come from. I'm clueless so far.

                    best regards

                    • HurricaneHarry

                      Finally found the culprit...
                      Seems for whatever reason the dll files in the minGW-W64 bin directory were not fitting the executables. Instead of loading with the installer as advised I loaded them manually, and voila, it works!
                      Didn't expect that tbh. Now I'm just wondering why I could compile and run programs without SDL included, even with those "unfitting" dlls, before...

  • Nsikan Ikpoh

    I started the journey on October 2019 and I finish on 23 March 2020. Couple with Office Work. I have learn a lot here. Thanks so much for having such a rich resource free for learners. Before now I only work with Ruby and JavaScript Extensively, I use to shy away from C++ because its much harder to understand. This tutorial guided me all through. Now I am diving in to Data Structures and Algorithm in C++ to be more equipped.

  • Sapinder

    I dropped out in the mid of my 1st year in BCA just a month ago. I was quite frustrated at first, but then I decided to spend the next few months in learning the things I wanted to. I knew only a few concepts of C at that moment, and on 13th Feb. 2020, I joined these tutorials to get familiar with C++. And now I'm done on 18th March. It's really been an excellent resource for me to start off!
    It's a heartfelt thanks!!!

    • nascardriver

      That's pretty quick for making it though all the lessons, congrats!
      Check the index every now and then to see if any new lessons were added :)

  • Deepak Budha

    Alex and Nascardriver, thank you very much for the tutorials. This is my first programming language. I have gone through the lessons on this website twice. Is it normal for me to still not be able to recall all syntax and concepts even though I feel like I now know the language?

  • Hassan Magaji

    Hurray!!!! Mission accomplished!!!
    Thank u very much Alex for this awesome FREE tutorials.even with the rapid changes to the language u still manage to catch up to cpp11/14 and some of cpp17.Cheers for the man!!!
    As a side note, you helped me pass the first and most crucial step towards my goal(game dev). The map looks like this though: learn cpp -> learn graphics(opengl) -> game development.
    With this in my toolkit, i'll carry your banners whereever i go(wont forget Nascardriver too!!).
    BTW: as i look forward to learn openGL as my what's next in building my carrier towards game development, i would like to know what you suggest!!(as they say teacher is the best advisor).
    Thousand thanks again to you Alex, Nas, and all dear my fellow colleagues in learncpp.

  • Evan

    Thank you so much for this amazing tutorial. This was a great starting point and I'm so excited to use c++ with confidence, and continue learning along the way. My only regret is that I didn't go through it sooner.

    Thank you!!!

  • vai

    Thank you so much for making the best C++ tutorial ever.
    Can you make a tutorial on "Data structures and algorithms" :). Or please suggest me some good books to learn algorithms and data structures.

  • hellmet

    Daannnggg. I made it!

    Now what? (insert meme https://i.imgflip.com/28this.jpg)

    I must say, it's been fun and I learnt a lot here, from the lessons and from the comments! Thank you very much for clarifying all my doubts and helping me understand Alex and Nascardriver! Hopefully, someday I'll be good enough to come back and contribute to these lessons.

    I'm still unsure how I can come up to the level of Nascardriver and Alex though. To gain that much understanding, to be so knowledgeable of the language! Some insight would be helpful, as I still feel I'm not good at programming.

    I've come across some criticism from professionals, but not so much form a beginner, so I thought I'd add some of my views here.

    C++ can work as both a 'low-level' and 'high-level' language, which makes it such an amazing language to have in one's toolset. I saw a video which argues that C-isms shouldn't be taught, as C is a different beast when compared to C++. That is true to some extent. To completely understand 'new', I had to understand stack and heap well. This is the reason some of the pointer stuff needs to be back on the table. References are, under the hood, pointers anyway! I don't see a nice way to explain references without having understood pointers. Going step by step, from the low-level stuff to the high level stuff neatly establishes the hierarchy of abstractions that grant C++ this wide '*-levels', and helped me understand every aspect of it. But the argument can be made the other way too, introduce the high-level stuff, then explain the low level ones. Some people actually prefer this, working only with the high level abstractions. I'm not sure both can be satisfied at the same time, since they are effectively mutually exclusive. Either way, only a few 'c-like' concepts are needed (for example, pointers), and hey, they are a core part of the language anyway!

    But man, was it fun learning some of C++. Need to learn more, especially the so called 'Unified memory model', Threads and its bels and whistles, toolchains, libraries.

    Thank you Alex and Nascardriver! I'll keep bugging you with more doubts!

    • nascardriver

      Congratulations on making it to the end!

      You read a lot, now it's time to write a lot. You'll learn from running into problems. As long as you have a project that interests you, you'll continue to learn.

      I prefer introducing the high-level side of C++ first. The low-level side is hard to understand and error-prone, which is not what beginners should be dealing with.
      It's definitely possible the other way around, I learned it that way myself. For someone who's looking to use C++ for low-level programs, this direction is probably more interesting than the other way around. However, I think most people who come here don't know what is possible with C++, and for them, the high-level side is easier and safer.

      • hellmet

        Your intuition was correct! I am interested in the low-level stuff, so this progression made perfect sense to me! I was biased without knowing it! I wanted to show my appreciation, but have little experience in teaching and actually writing code, so I'll leave the tutorials part to you and Alex (Great job again, god I _cannot_ thank you guys enough!).

        Thank you for the kind words! I'll try writing myself a CLI download manager! I really wanted to get into threads and performance oriented design, so maybe this is the most effective goal! I'll try my best to use all the features without going overboard :)

        I'll be back when the C++20 update is in! Perhaps I can help with proofreading too!

        Could you add the snippet again with which I can browse my comments? I seem to have lost it, sorry!

        Have a great time, I sure did!

  • Brian

    First of all, thank you for all of your hard work putting this site together and actively engaging with the users in the comments section (including nascarDriver). Reading each section, following the examples, doing the quizzes, and reading the comments has given me a much better understanding and appreciation of C++.

    It may be outside the scope of these tutorials to address specifically, but I would love to see some applications of C++ for scientific computing. I know it isn't necessarily common to use C++ for physics models, but it offers advantages over other languages that are sometimes glossed over. Like, strongly typed functions, scoping variables, re-usability, maintainability, computational efficiency, etc. It seems like everyone is shifting to Python and Matlab because of their simplicity, but their shortcomings are exacerbated when writing a simple 2D flow-solver. Simply put, it would be a shame if the scientific community keeps pushing languages that do things behind the scenes for you, limiting the programmer's overall control and understanding of variables and computational workflow.

    Thank you again and keep up the amazing work!

  • Yi

    It would be great if the site had a section where we could submit improvements and more lessons that can be finalised and reviewed by the site owner. I was reading about the open source idea below.

    • Alex

      You can do so in the comment section for this lesson. I also updated the "report an issue" page to be a place where general feedback can be left, for those that don't quite make it to the end of the series.

  • Boris

    Hey mate, that's a great tutorial, since it's kinda like a book, i think of adding it at goodreads( I've spend a lot of time reading it so i think it should count to my yearly number of books read ;) ), what do you think about that?

    • Alex

      As I'm not familiar with goodreads, I can't advise on whether that's appropriate for that site or not. A quick glance shows that they are recommending physical books. Are there places where they recommend websites?

  • Parsa

    Thank you very much Alex and nascardriver.

  • Mrio

    Awesome guide to a quick but fundamental introduction to C++!! Everything is written in detail but in an understandable way.

    If something, I would only add an explanation about the difference expression types: lvalues, xvalues and prvalues, I think that it makes "std::move", "rvalue references", "move semantic implementations", etc... more coherent and obvious. Also maybe expand the appendix about external libraries, putting the concepts explained in chapter 2 altogether through a common library example.

    Anyways, I loved it. Thanks a lot for it, Alex.

    Also thanks Nascardriver for his rapid answer to our questions.

    Cheers!

  • Hi Alex!

    I watched Bjarne Stroustrup's "C++20: C++ at 40" talk ( https://youtu.be/u_ij0YNkFUs ) yesterday and it inspired me to tell you about some ideas and concerns I've had for some time now. I'm quoting Bjarne, as I have gotten the impression that you like him and it might help to convince you to apply certain changes.

    Judging by the amount of comments I see in the more advanced chapters as compared to the start, not a lot of people make it to the end. This is to be expected, C++ isn't easy. But those numbers can be increased. I'm afraid people get scared away by the use of legacy code. By legacy code I mean language features that have been made easier by abstractions to a point that they no longer take a prevalent role in C++.

    1:07:46, while talking about raw pointers and dynamic memory allocation: "Don't go to that level unless you have to".

    This affects the majority of Chapter 6. A chapter that comes before standard containers and classes. Trying to teach the innards of abstractions before showing what can be done with them doesn't work well. I don't want you to remove the lessons about close-to-memory language features, as they are an important part of C++ and they are the very thing that got me into the language. But for the most part, C++ is used as a high-level language. When there is a layer of abstraction above a feature, introduce that abstraction first. At the end of the chapter, or at the end of all lessons, talk about how those abstractions are implemented or why one might need to move down a layer. This includes, but is not limited to, smart pointers before `new`; `vector`, `array`, `span` before C-style arrays; `std::string` before C-style strings. For the majority of people that come here, C++ is the first programming language they learn, don't scare them away by using legacy code.

    1:11:20: "When you try to explain what C++ is, don't start with C, and then say, 'and then in C++98 we got, and then in C++11 we got' and so on."

    This backs my point above. Standard updates make small changes to the language, but make big changes to the standard library. At least that's what happened in C++11 to C++17. C++20 will change the language. The std library updates can't go unnoticed, they make C++ a lot easier, requiring less boilerplate from new people, which is something that I myself didn't like when I learned C++. The std implementations are easier to use, more readable, safer, and most likely perform better than custom implementations. Sorting, iterating, and parallelizing aren't things that need to be written by hand. I look at them as good practices in a quiz after showing the according std functions. Many of the questions I answer would be unnecessary if newer code was used, especially talking about everything involving pointers.

    1:17:19: "Legacy code is a major problem." (Note that "legacy code" refers to code older than my definition here).

    I wouldn't go as far as calling the code on learncpp a major problem, but it will become one if you don't keep up. Learncpp is a great source, but it will be useless if it doesn't incorporate modern language features. I said this several times already, there's barely even content of C++11. You haven't been able to keep up with the past 8, almost 9 years. You're not to blame, you don't appear to have a lot of time and even if you had, it's still a lot of work to update and maintain learncpp. C++ is a big language after all. I don't see things getting better with C++20, pretty much everything needs an overhaul.
    As recommended by a user before, please consider making learncpp an open source project. Even if it's just to fix issues in existing lessons, it will save you time you can invest in adding new content or rewrite the old. Your writing style has been praised by many people, I understand if you don't want entire lessons to be contributed.

    • noobmaster

      "...not a lot of people make it to the end". I think the reason behind it is this tutorial looks more complex and detailed compared to some other c++ online tutorials. It's pretty hard to keep motivated when learning some chapters that seems too long and complex. It took me 6 months to finish the whole tutorial (not fully understand/remember it though). This tutorial could teach someone with no prior programming experience but not really "beginner-friendly" in my opinion. Maybe it's a good idea to move some chapters to advanced topics section

      I agreed for the legacy code things, but even my teachers at university and many other online tutorials still using the older version. Maybe because of habits idk. So I totally understand if Alex still using the old style too

      Open source for learncpp?
      I think it's a good idea, or maybe Alex just need you (nascardriver) too make this whole tutorial even better :)

      Anyway, big thanks to Alex for this great tutorial

    • Alex

      As always, thanks for the lengthy and well-written feedback, Nas.

      re: Pointers, I agree wholeheartedly -- the chapter on pointers is where people currently go to die. As part of my ongoing update, I'm intending to spend more time covering some of the useful container classes and algorithms, and de-emphasizing pointers and C-style arrays and do-it-yourself code (trying to see if it's viable to put it after the chapter on classes). These things were more relevant pre-C++11, and are becoming increasingly less so over time.

      re: Language versions, we can assume C++11 is a reasonable minimum version for professionals to be using at this point in time. Please feel free to point out any pre-C++11 references as you run across them, and those can be deprecated.

      The modules changes in C++20 is going to be a fun update, as it will affect literally every example on the site, and we're going to end up with a bifurcation between those who are/aren't using C++20. Still not sure how to handle that one.

      Given my time limitations, perhaps it is time to considering bringing on a trusted editor (as a first-step towards migrating the site to more of an open source model). Are you volunteering? :)

      • > C++11 is a reasonable minimum version for professionals
        That's true. But learncpp isn't supposed to produce professionals, is it? It's goal is to teach the core language to anyone who wants to learn C++. When I learn a language, I'm expecting to learn the latest stable version, which right now is C++17 with notes about what will change in C++20. It's easier to forget about new features than it is to learn about new ones. If someone is limited in their choice of the standard version, they'll quickly figure out how to do something without using newer standards. On the other hand, everyone who finishes learncpp with C++11 and wants to learn modern C++ has to go over everything they just learned and learn a whole lot of new things that could've been taught right from the beginning.
        People who learn C++ mostly aren't limited in their choice of a compiler or settings. There are niche chases where people want to learn C++ on an old raspberry pi or so, but they shouldn't be the reason that's holding everyone else back.

        > The modules changes in C++20 is going to be a fun update
        I sure hope so. I'm honestly not expecting to get widespread compiler support (gcc, clang, msvc) for modules anytime soon though. Late 2020 maybe.
        Old `#include`s will continue to work, there's no pressure.
        I haven't used modules yet, so I can't tell how difficult it would be for a beginner to use includes or modules when the other thing is taught. Showing modules but not using them in the other lessons will have the same effect on the learners as brace initialization had. They'll use whatever is used in the lessons and forget about what was taught.
        Since the majority of lessons use single-file examples, I'd update them few multi-file lessons to modules and keep (and update) the introductory lesson about headers.

        > Are you volunteering?
        I most certainly am. Let me know what you want me to do and what you don't want me to do.

        • Alex

          Learncpp is meant to support all C++ learners, from hobbyists who just want to tinker to professionals who want to brush up on a topic, and those who are creating new programs from scratch or are contributing to existing closed/open source projects.

          Hobbyists and those creating new programs very likely will want to use the latest and greatest standards. Professionals and those contributing to existing projects often have other constraints -- either in terms of what capability sets they're allowed to use (e.g. the software project I help manage professionally is limited to C++14 capabilities) or in terms of legacy methods that have been previously used (how many projects have you seen that still use macros? Ugh! No modern project should ever use those, but they're still worth knowing about simply because they still exist in an awful lot of existing C++ software).

          For those reasons, I feel it's useful to talk about older methods that have since been replaced by modern methods. It's less efficient for the hobbyist/new software creator, but makes the site applicable to a larger cross-section of users with different constraints or motivations. Over time, those legacy methods can be increasingly de-emphasized. Tradeoffs, right?

          • > I feel it's useful to talk about older methods
            Talk about them for sure, but they shouldn't be used in lessons that aren't dedicated to them. Here's a very rough overview of an introduction to `std::ranges`.

            ---
            This is what ranges are, bla bla
            Before C++20 you did it like this

            that was because bla bla but ranges are better because bla bla
            maybe a link to rangesv3
            here are more examples and rules of ranges
            ---

            And all other lessons use ranges rather than iterators. That way the highest standard can be taught and used without ignoring people with restrictions.

            • George

              This site is currently one of the very best for helping C++ developers like myself to fully understand the language so please don't go changing the format too much. I've only started to use C++14 as a project standard but day to day coding is still very much C++11. There is also a lot of legacy code out here so a site like this can also help provide context as to how things used to be done, why it was changed and the way to do it now. The section on smart pointers is a good example of this approach.

              You guys have did a great job with this site and are helping me to do a better job and to also get more enjoyment doing it - many thanks !!

  • SighFactory

    I'm actually just getting started here. I wanted to swing by the comments on this page and see how other folks fared. I'm a beginner, just past the first few lessons and judging by the range of results I've read so far... I'll see you here again in a few months to say thanks. ^_^ Looks like an awesome resource.

  • Ivan Amirov

    Thank you for everything! I've read almost the entire chapters and I can explicitly say that you guys helped me a lot! Everything is written in understandable way. I appreciate your work so much!

  • Carl

    First of all, thank you so much for your effort. This is a very valuable resource online, indeed. Thank you. Regarding topics that I dare to recommend for the future, I've come across with the boost library often and it is so tough. Even the syntax, it almost looks like a different language with a very peculiar way of declaring variables, functions, weird data types which I presume are included in this library... It seems that boost is quite popular, so a short introduction to start working with it would be a nice complementary material.

    • Alex

      Just my opinion, but I'm less likely to recommend Boost now that I would have been pre-C++11 -- for the simple reason that many of Boost's features have been integrated into the standard library over time. I suspect this will continue to be true into the future, and that Boost will increasingly take on the role of "experimental feature incubator".

  • I would also like to thank you for learncpp! There are a lot of tutorials, books, ... but at the beginning of LearnCPP I read that the proposal was to explain in more detail and not tiring, and I can say that you really achieved that goal. Most stayed around because they found a different way to explain.

    Congratulations to Alex who knows how to write well and in a very enlightening way and also to nascardriver who has great patience in answering as many questions and comments as possible! Even the ads that appeared were more interesting, I clicked on several and even bought a product I was looking for =)

    I also wanted to thank everyone who commented, as I also learned a LOT from the comments and questions from many people who made LearnCPP stay alive!

    My tips: It would be interesting to see GTK + and WxWidgets tutorials, Qt I would not indicate because there is already enough on the internet and is easier to implement, in my opinion. And if possible also tutorials linked to the OpenCV library which is growing a lot for use of AI resources.

    Hugs and thanks to all!

    • Alex

      Thanks for the feedback! Although I'd love to do a graphical/forms tutorial, as soon as I pick one I'm sure I'll get a hundred requests to do the other ones too. :) At least for now, I'm intending to stick to platform & library agnostic material.

Leave a Comment

Put all code inside code tags: [code]your code here[/code]