Is there Garbage Collection in C and C++? 

Technically C++ versions from C++11 up to and including C++20 have reachability-based garbage collection and leak detection specified in the standard, but no compilers have ever implemented it. It is going to be removed in C++23.

CPP does call an objects destructor once it goes out of scope, so you can write memory freeing logic in the destructor.

C an C++ are low level languages where you have (almost) total control. Once you add a memeory garbage collector to a language you lose a bit of control because the garbage collector decides when memory is freed. This opens the door for many other problems concerning performance, predictability, etc.

I never had to worry about memory leaks anymore since I started using std::unique_ptr and std::shared_ptr. These two classes release the burden on the programmer about managing the heap allocated memory.

smart pointers in cpp do this job quite efficient and fast. I haven't seen any performance bottleneck.

Your videos are consistently among the absolute best tutorials on C/C++ that I've ever seen on RU-vid. I have a lot of experience in garbage-collected languages (e.g. C# and Java) but not any in unmanaged languages, so I'm slowly teaching myself C (and C++, later), in large part through your videos. Thank you for sharing your knowledge.

Great video as always Jacob.

In C++ smart pointers are close enough to garbage collecting but they need to be opted in to manually and have some friction involved with them. In C try making memory pools. Bottom line is if you're using either C++ or C you probably care about performance and in most cases manually freeing memory helps you think about the memory layout of your program which is what you want anyways.

What was being described here was reference counting GC, and it is in widespread and common use in C++. Not least on Windows, where it forms the core of the object lifecycle management of COM. But smart pointers are also a form of garbage collection. What C++ tends not to have is mark/sweep garbage collection. But there are libraries that do mark and sweep garbage collection in C/C++: en.wikipedia.org/wiki/Boehm_garbage_collector

I've started to learn C language focused on development of softwares for embedded systems. I've have already some experience in programming for scientific computing and machine learning algorithms purposes. So, this content has helped me a lot. Thank you, I wish success for you.

You are a superb teacher.

I've created one library for this. It had a wrapper class to encapsulate pointer, it never exposes pointer to outer world, it just allows to interact with the object referred by the pointer. It can reference count and garbage collect automatically. It has one problem though, with circular references.

you could use `__attribute__((cleanup(cleanup_function)))` in front of the declaration of your variables to call `cleanup_function` on it when the variable gets out of scope, but you have to initialize that variable or else it's undefined behavior, and you can also use `__attribute__((destructor))` on a function for it to be automatically called after main

You just blew my mind! 🤯

you are the rockstar programmer, learned lot things from you. thanks again!.

Great video as usual, thank you!

What about the Boehm-Demers-Weiser garbage collector? I read through some of the documentation some time ago, mostly out of curiosity. I've kept it in the back of my mind, just in case I ever felt the need for garbage collection with something, but I've never used it or needed it for anything. Still, it sounded promising, from what I remember reading of it. It basically works by replacing the call to malloc. I believe it's been around for a while and is the most noteworthy gc for C, though I have no idea how well of a job it actually does.

std::unique_ptr and std::shared_ptr in C++ are solving the garbage collection problem

I am interested in memory management, but appreciate that there is a performance cost. To paraphrase Scott Meyer, "there are many applications where you simply cannot run fast enough". Such as game graphics, numerical simulation, stock trading, ....am I sure there are many others. I think this is why native languages such as C & C++ will never lose popularity. That is why I always want to become proficient in an managed language and a native language with no memory management. Thank you for the insightful video.

As C++ has destructors, you can implement smart pointers, and it was already done (std::shared_ptr and family). The real problem with C is that there is not a destructor (or drop function).

Garbage collection (or in general not leaking memory) is like cleaning up your room. Sure, you should keep your room clean all the time, but what's the point of spending effort cleaning if you know your house is going to be demolished tomorrow?

For those looking for a garbage collection implementation for c++ take a look at Microsoft c++CLR (Common Language Runtime) it comes with the benefit that much of the .NET Framework(know from languages like c#, f# visual basic...) is already compatible with the garbage collection system implemented in c++CLR

Wow, a lot to clarify IMO from this video! 1. C and C++ are so different it’s difficult to address both in these topics simultaneously 2. C++ DOES have managed pointers available (std::shared_ptr etc.) and a whole complex system with ref counters and move semantics… it’s not really garbage collection in sense of C# and other languages (e.g. you’ll need to take care to avoid circular references yourself!) and no reachability (mark and sweep) mechanism is running “collection” passes. But it does provide some ability to allow programmers to implement code without carefully keeping track of everything. 3. Of course you can write your own garbage collection in C++/C . You have power and flexibility in these languages and that is a feature of the language. With power comes responsibility. For example, Casting scenarios mentioned in this video are common in the lower levels of game engines as well as use of pointer arithmetic to move a pointer to the next address of a contiguous memory array of objects (though a hard coded +68 would be strange to see in code, but not clear how that slide in this video is relevant) 4. Many C++ Game Engines implement garbage collection. Check out Unreal Engine for example. The spirit of comments in the video indicate that people have “tried” , but not succeeded. These game engine implementations have shipped hundreds if not thousand so of games. Bottom line, C/C++ do not have garbage collection systems built into the language like C# , Java, etc. But C++ does have ref counted smart pointers. If you want a full garbage collection system of course you can build it yourself.

Nice to hear what you said around 2:30. I see that question often in various forums, so it must be a very common misunderstanding. Why it isn't obvious to some people that the OS will reclaim all memory at program termination really puzzles me. Back in my CP/M days, the way to exit could simply be a jump to address 0, which would result in a reboot of the system. I often think that the use of C++ with it's destructors, that 'must' be called, is causing anmoying problems, especially with large interactive graphical interface programs, in short: web browsers. I like to have my browser open at all times, I use many windows, and many tabs in each, I don't reboot my machime for months, and don't quit the browser unless the machine gets bogged down, which seems to happen more often over time. I use Firefox, because although Chrome may be a great browser, it doesn't seem to handle my usage pattern well. Firefox isn't perfect either, but at least it's better. Except when I decide it is leaking too much and needs a restart. I work on Linux, eith 8GiB RAM and just as much swap. But when it begins to use a good amount of swap, and I decide it's time, it takes an eternity for all the processes to quit. I guess it is because all parts of memory need to be swapped in for access just to run the destructors. This takes more than 10-15 minutes sometimes! If I just kill it, I suppose I run a little risk of having the persistent data messed up. I just wish someone would teach programmers to persist any data (sessions, state etc) whenever possible and respond to a quit command by just calling exit right there and then, instead of returning all the way back to main, wasting _my_ time running futile destructors on gigabytes of objects along the way. If the program also did a check in the event loop that no more memory is being used than before (except for new tabs and windows), and that inactive windows are paused and have their state persisted and flushed until reactivated, I think things would work a _lot_ smoother, using just a fraction of the memory. Maybe programmers should just be forced to program on machines with less memory for some time...

Much obliged.

in systems programming your memory is normally freed by the battery running out or the mains cable being unplugged

for c, you can use the dlsym trick and make a malloc tracker. In c++ put a delete statement in destructor and you should be ok.

7:17 Well techincly in modercn c++ compilers there are smart pointers with(while not garbage collected in literal sense) act as if there were garbage collected.

I remember Walter Bright (the creator of the "D" language, as well as the Digital Mars C++ compiler) posted something awhile ago about how they got rid of all the "cleanup" code in their compilers for one basic reason: compilers are short-lived, and typically don't take a lot of memory anyway, so why not just malloc to your hearts content and let the kernel worry about cleanup afterwards? His argument is that Linux/Windows/MacOS is going to clean all the memory once you're done with the process anyway, so there was really no reason to bother writing "free" anywhere. He claimed that the code actually went substantially faster after that, and I'm inclined to believe him.

The other reason is that garbage collectors run whenever they decide it's time to do so, this is a dealbreaker in real-time applications because you can't have the garbage collector run when a function needs to run at most for X milliseconds otherwise you break the contract. In C and C++ you know exactly when memory will be released. After C++11 and the introduction of smart pointers you can really avoid a lot of manual work and you feel that you are writing with a garbage collector on standby.

Do you have a list of C books you like? Thank you for the great content!!!

So... it's worth noting that several implementations of Python (including the canonical) are in C. Java is self-hosted (Java is written in java). C is self-hosted (C is written in C). But Python is not written in Python. The canonical Python is even called C-Python to distinguish it from (say) Iron Python or JPython. So... that means that Python is an example of a Garbage collection written in C. It uses (as you did touch on) conventions to enforce Garbage Collection, but if you like Python and C, one of the contracts you will take (assuming to follow the directions) is the life-cycle of Python objects w.r.t. C code you link in. I believe there is also guidance on the life cycle of resources your C code manages. Sometimes I lament that the first thing covered in learning languages is not the "isomorphism" concept --- the idea that languages map one domain to another. This is as true for "English" and "French" (mapping between human thought and a representation that can be communicated to different humans) as it is for C and Python ... which map between an expression between our ideas and intentions (as best we can express and manage them) and what a computer can be encouraged to understand and/or translate. As such, a Python program _is_ a C program ... in this case ... in a way that a Java program is not... (unless a suitable and conformant implementation of java in C exists ... in which case, my bad)... I do recall programming on the Amiga where one needed to allocate "chip" memory with the OS allocation. The C library did clean up things malloc() and friends allocated, but you would leak memory if you didn't clean up your OS allocations. I would assume that arduino's and whatnot ... you'd either have the "long running" problem ... or the small OS problem ... so there may be modern common environments where cleaning up is still important.

You can get some semblance of "garbage collection" with smart pointers. They are builtin in C++11. In C you have to use a library eg gtk/glib.

Hey Jacob I've been watching/listening to your vids for a while now and I can't seem to understand what kind of microphone setup you're using that makes you sound so distant and not uniformly leveled at all? It's a really weird audio experience tbh lol.

I'm shocked you did not mention smart pointers and the huge problem they solve. I'm still a raw pointers fan though

I feel like C++ RAII is needed to accomplish this

Hi Jacob! On this topic I've been thinking about how C compilers and language standards still doesn't have the option to treat `dataptr.field` as `(*dataptr).field` automatically where the type of dataptr is known to be a pointer to a struct. Tsoding Daily recently made a proof-of-concept patch to tinycc implementing this (in the video "Hacking C compiler", patch shown at 1:50:00), and I think the question he is asking is reasonable: How much legacy code would *actually* be be rendered unusable by such an addition to the C syntax? It would be interesting to hear your take on it, OR even see you implement a similar patch in GCC, exploring the topic of backward compatibility through practical examples along the way (or, if everything just builds fine, talk about how the C language standard is developed and how a change can be "proposed" by introducing a change like this as an extension to the GNU-C flavour for example?). Hugs!

SerenityOS uses reference couting in a lot of places but now decided to switch to a memory safe language in the future.

Here is what 55 years of programming taught me: People who learn to code in assembly first, then C, would NEVER ask such a question in the first place. Further, if you learn to "program" in a "safe" language, you will NEVER write an operating system. Languages that "protect" you also keep you so very ignorant of HOW THINGS WORK!

Hey Jacob, Can you make a video on creating device drivers for linux? Thanks :)

Sir, What about cpp? Like there's std::shared_ptr and unique_ptr. How do they work? Can you make a video about that?

6:19 actually language does not allow this... You can do pointers arithmetic until the resulting pointer points to the same object in memory, else it is UB. UB does mean that the language allows it....

RAII + smart pointers take care of garbage collection for you so you don't really need GC in C++ Edit: I expected it to at least be mentioned in this video... Come on.

But than how does "free" know how many bytes it has to free if we are just giving it a single pointer?

As student started with c it felt weird to have Garbage collection at first.

Speaking of memory... Is there a way to integrate the concepts of ownership and borrowing into c (like in rust)? If not then... why not?

Just started video, but I'll say this is about the stack and }

Basically good info, but several sins of omission. First, reference counting is only one kind of GC. There's mark and sweep and copying GC for a couple of other examples. Second, long-running apps are not the only ones that need GC. Many kinds of programs can't afford to allocate willy nilly and count on OS unmapping. Programs with complex memory use patterns sometimes implement GC themselves because explicit free()ing ends up consuming way too much time marching through big data structures. I've used both. The Boehm collector (easy to search) is mark and sweep with conservative pointer detection. It's implemented as a malloc library where free() does nothing. Available since the early 90's, for a long time Boehm was used as the underlying gc in web browser Javascript interpreters and many other systems. Finally, this doesn't mention that precise GC requires an internal representation of struct types so the collector knows how to find pointers within. C/C++ doesn't give you any type representation for free, so any kind of app that implements its own GC needs to fill that gap.

Have you tried golang, it is like modern C?

C++ does have deterministic garbage collection, ever heard of std::unique_ptr and std::shared_ptr? I hope nobody is writing deletes in 2022.

Why did you not mention smart pointers for C++?

welcome back 👋

C++ doesn't have native garbage collection and, due to the extra powerful pointer type, its almost impossible to implement Java like garbage collection. But, nowadays, almost all real world program is done within some kind of frame-work, and most of the frame-works out there have it specialized smart pointer classes that allow for some level of garbage collection within the framework native objects. We still have to do the heavy lifting when using raw native types.

Garbage collection goes against the idea of C being a low level language, like C++.

I remember Microsoft has managed C++ in there .Net Framework

There is a simpler and shorter answer to this. All those other languages are written with C or C++ to create their compilers. That being the case yes you could make tools or a library or another compiler so that it works in C or C++. I much rather have C and C++ as it is. I'm not lazy. I can handle my own garbage collection and so I can do it in the manor I need for the type of program I am writing. If you need garbage collection then use a program that has it don't try changing C and C++.

You really should talk about runtime predictability with respect to GC. Using a GC, you can have the program taking long and unpredictable times to rearrange the heap and track references. This is death to subjects like embedded real time programming.

eh, I typically just create a gc using IDs and a small "class" object that describes the object being pointed to and what to call to terminate it before de-allocating the object itself, something like this: typedef pawd (*pawInit_cb)( void *ud, void const *cfg ); typedef void (*pawIdIs_cb)( void *ud, pawu id ); typedef void (*pawTerm_cb)( void *ud ); typedef PAW* (*pawFrom_cb)( void *ud ); struct _PAWCLS { pawzd size; paws name; /* Example "PAWMEM/PAWBUF", the / indicates that PAWBUF* can be * cast to PAWMEM* without issue (not recommended but you do you) */ paws path; pawInit_cb initUD; pawIdIs_cb udIdIs; pawTerm_cb termUD; pawFrom_cb fromUD; }; I allocate & deallocate via pawTakeID( &CLS, UD ); instead of calling my alloc function directly, this enables the gc to make a record of the pointers and what "class" it uses, in my exit function I just let the gc iterate through it's list of pointers and release everything that hasn't already been released through pawFreeID( ID ), the UD parameter is just for passing along a pointer to an object holding data needed for initialisation, if the initialisation succeeds then the id is returned, if it doesn't then cleanup is peformed before 0 is returned, 0 being treated as root ID which is an invalid value to pass pawSeekUD( ID ) which returns the object that was allocated & initialised, in other words anything allocated via the gc is easy to clean up at exit of program (which SHOULD be done since not all variants of the C runtime cleanup everything at exit)

Whip me! Beat me! Force me to use C++!

Would it be fair to say: "With great power comes great responsibility"? :)

When you say "modern OS's" when do you mean? Win 7. Dos 2.

Of course C does not have "garbage collection"! Otherwise the following would "poof" out of existence before it reached the compiler. char *gimme5( void ) { char buf[ 4 ]; strcpy( buf, "Five" ); return buf; } 🤣🤣 Too many inept "programmers" putting "garbage in", and with predictable consequences...

I think RAII in C++ does something similar to a garbage collector in some special cases. And what I'm speaking of is NOT what others referred to before in that smart pointers can give you similarish comfort. Though it is connected I guess. I have to say that I'm not terribly informed in that context, it doesn't seem to be very well documented at all, and what little I do know is mostly based on what I heard in Rust. Rust also has RAII, it's equivalent to Destructor is called Drop. And, while in most cases Rust can just stick the destructor call in the function where it is supposed to be called, I did learn that there is something called drop tracking, which is part of the very slim runtime of Rust (probably slimmer than at least C++ with coroutines), and has to be used in some very dynamic situations. I'm not certain what precisely these situations are, one that MIGHT apply is when you're reassigning a RAII value in some indirect way to itself, though I'm not sure. But I do imagine that 1) this tracking will be done in a similar manner to SOME garbage collectors 2) that if Rust has that then C++ compilers probably also do.

Video starts at 1:21 those who came to this video for an answer

bro just use Rust

C/C++ can accommodate garbage collection. It's unusual but there is a solution to that with Boehm conservative garbage collector that can be used with existing sources (see en.wikipedia.org/wiki/Boehm_garbage_collector).

How do you program graphics in modern day C? Only reference I can find is 1992 Turbo C with 😳