More c++ please!! Incredible video as always

@mCoding

Жыл бұрын

Thank you very much and I'll get right on it!

@rasputunga

Жыл бұрын

Agreee!!!

@nickmorton5595

Жыл бұрын

^ Ditto

@lawrencedoliveiro9104

Жыл бұрын

How about Google’s “Carbon” project? That is trying to simplify C++.

@clarkjantorres

Жыл бұрын

0:22

C++ devs: you can use std::unique_ptr to reduce the number of bugs from the the most common manual memory management mistakes C devs: just don't make mistakes

@lawrencedoliveiro9104

Жыл бұрын

C devs: We write the Linux kernel. C++ devs: What’s a kernel?

@anon1963

Жыл бұрын

@@lawrencedoliveiro9104 you could write an os in c++, no problem

@ccgarciab

Жыл бұрын

Haiku OS and the Zircon kernel use C++

@lawrencedoliveiro9104

Жыл бұрын

@@ccgarciab Neither of which are known for high performance.

@hanabimock5193

Жыл бұрын

rewrite it in rost

Teaching a C++ std feature by implementing it ourselves is exactly how I was taught std::vector at university. This reminded of that professor. Great video as always!

@soniablanche5672

3 ай бұрын

my data structure classes was literally the professor implementing every single data structure you can imagine in python even if most of them already exist in the standard python library.

Super engaging video as always, the twist in the middle is exactly what I love about your style! You don't just take the standard library for granted as a blackbox. I love that you take us with you into the scary dark depths of standard libraries (be it Python or C++) while still not overwhelming us, thanks and looking forward to more C++ videos ☺

@mCoding

Жыл бұрын

Thanks very much for your kind words!

@0LoneTech

9 ай бұрын

At 5:44 is precisely where I am uncomfortable with C++ as a language. In Haskell, I've explained my mental model of how things would work, and then found out that's *exactly* what they were in the standard library. C++ is a developing language, and here people are actively maintaining it to be unmanageable. There are corner cases in the compiler and language that the library writers have to work around, making the source more complex, slowing the compilation further. It is counter to the purpose of communicating an algorithm between programmers, readers and computers.

I'd love a full video dedicated to your comment "standard library implementers have to write it like this for... reasons" @ 5:45. I know that it might be a little different from what you usually post, but I've actually often wondered about this

@illyias

Жыл бұрын

Given the look on his face, I think he was implying that he doesn't know the reasons himself, he just knows there's a reason for it.

@JamesThunes

Жыл бұрын

@@illyias as he implies in the video, it's because the standard library implementers need to worry about the general solution so that the object will work for whatever random thing a programmer tries to throw at it. A simple implementation can ignore all the fiddly bits and simplify it to store nicely behaved objects. How it works is (more than) a bit complicated, but the why is fairly easy to understand.

@cristian-si1gb

Жыл бұрын

There are a couple of reason why STL implementations are generally considered "unreadable": - they must use the reserved naming scheme with two leading underscores (__foo) or a leading underscore and a capital letter (_Foo) in order to avoid naming collisions. You're not allowed to use these yourself btw, it's considered undefined behavior - most C++XY specific features and parts of the code in the headers are guarded by ugly macros. - a lot of SFINAE and template tricks are used in the implementation (see std::enable_if and tag dispatching) - micro-optimizations that are not always trivial to understand and that are usually guarded by static checks (see previous point). - conditional noexcept(...), explicit(...) specifiers which turn function definitions into an ugly mess.

@bunniesarecute3135

Жыл бұрын

@@cristian-si1gb thank you!

@illyias

Жыл бұрын

@@cristian-si1gb God damn, this dude knows his shit

Laughs in rust 🦀. Jokes aside. Really interesting video. Love it ❤

@mCoding

Жыл бұрын

unsafe { laughs in C++; } Appreciate it!

@anthonysteinerv

Жыл бұрын

C++>>>>>>>>

Me looking at the standard template library: "Seems.... to be made of.... code"

"Let's write unique pointer." Fuck. Yes. Fantastic teaching method

Very nice explanation! I've not done much C++ so a lot of stuff like this just feels alien to me; walking through the behind the scenes is a great way to show how it works.

this is definitely the best unique pointer video on youtube.

@mCoding

Ай бұрын

Thanks! I appreciate it!

I liked the additional information where you created the unique_ptr yourself.

This is very clear and thanks for the implementation details. It help a lot to understand what is going on

C++ is always a welcome topic. Would love some shader languages as well

Thanks! Very, very helpful!!

Good call doing the exercise of writing the diy unique_ptr class. It shows that you remember what it was like to not understand. The best teachers never forget what it was like to struggle as a n00b.

The only small thing I'd like to note that not many people know about is that delete already has a built-in check for nullptr, so the repeated checks there are redundant. Other than that 10/10 implementation

@mCoding

Жыл бұрын

Thanks for pointing this out! This is what I was trying to say but maybe I wasn't clear enough. I used an if check even though it is not needed in anticipation of custom deleters, which may not allow deleting nullptr.

More modern / post-modern C++ please!♥

GREAT video! Thanks a lot sir

Ah i remember converting code to C++11 and needing to convert auto_ptr code to unique_ptr code. But unique_ptr is very useful when inheritance is involved, or for weird pointers like pointers o functions, which you cannot just replace with a member variable... (Can be used as nullable member variable)

Great video as always! How long have you been coding?

I would try and be funny and come up with some reference in the comments, but maybe I'm not smart enough, oh well ;) Def. looking forward to a possible shared_ptr video though!

unique_ptr is so simple, yet so useful! However my professor still uses "new" and probably does not even know about smart pointers... I personally think that using "new" should become the new "goto".

@anon1963

Жыл бұрын

because as a decent programmer you need to know how to manage memory yourself, and know what new, delete are

@mattiaslaserskold137

Жыл бұрын

@@anon1963 Common misconception, why should you start learning way that is not recommended? I know most of us learned new first (because smart pointers did not exist), but there is no good reason. What if memory management is not always the *first* thing you should learn?

@anon1963

Жыл бұрын

@@mattiaslaserskold137 memory management is never the first thing you learn because you should avoid using pointers as much as possible, regardless if it's raw or smart pointer. if you don't need to learn about pointers go use Rust/Python/Java. because if pointers or memory management are not your second nature, you're not getting a job in C/C++ dev.

@mattiaslaserskold137

Жыл бұрын

Yes you already expressed your opinion in the first comment. Now you just repeat yourself. Of course you don't know c++ before you know pointers. In my experience many people think you should first learn c before you start learning c++ and then never get to learn the stuff you should use in production. But why is that? It's only because it's how many old people learn c++, and in Academia, most people use c instead of c++ anyway so that explains why professors think you should use only c features. And if you are a noob c++ developer landing a c++ job in a new code-base, you should not be using new or delete anyway, so why start using it the first thing when learning the new language?

@anon1963

Жыл бұрын

@@mattiaslaserskold137 because you know how smart pointers actually work, but i guess not many of you think critically and remembering that new returns a pointer takes too much space in brain. i understand. i will repeat myself once more then: you wont get a job in c++ without knowing what pointers are and how to use them without smart pointers, ever.

I would love to see a follow-up video on custom deleters.

I remember my first contact with unique poiters. I always had problem with this that it never wanted to work properly. And i had copy error despite i couldnt get where copy could be made. Then i was also afraid of memory leaks. Because i learned to analize code line by line, what makes easy to read even messy code, but it triggers alerts automaticly when you don't see something. And i remember when i shouted on some people when i saw make_unique or unique ptr and then i couldn't find any functions or methods deleating it. I was always like "You want to make memory leak?! There is no relese of memory in this code!". And "THERE" was key word. Despite i know how destructors works, I was afraid something can go wrong, just destructor wont be made properly f.e. When i saw source code and i spend few hours moving across this mess i could see that using unique ptr will be safe. It sounds kinda wreid, but sometimes getting knowledge from scratch is better than getting everything as it is said, cause someone can lie.

@anon_y_mousse

Жыл бұрын

I know what you mean, it's part of what gave me the negative guttural reaction to first seeing Java code, new everywhere, no delete.

Suggestion. Rvalue Lvalue and move operations from scratch without STL.

@staswisniewski4101

Жыл бұрын

All move does is casting to rvalue

What about multi-threading? For one of my old projects I was using unique_ptrs with one thread handling the creation and deletions and another looping though. I ended up using mutexs but I really didn't like that.

More C++ please 🙏

What happens to the moved pointer if the variable holding it gets dropped if its in a smaller scope? Does the vector size change when moving it? What happens if you try to access it from the vector?

@mCoding

Жыл бұрын

Move constructing a unique_ptr results in leaving the old unique_ptr in a valid-but-unspecified state. I believe all major implementations make that valid-but-unspecified state holding a nullptr, so your vector would end up holding a unique_ptr to nullptr. It does not remove the moved-from unique_ptr from the vector. Accessing the unique_ptr would be fine, you could e.g. reset it to own a new thing if you wanted, but dereferencing it would be dereferencing a nullptr if you didn't reset it first.

@orbital1337

Жыл бұрын

@@mCoding Actually slightly incorrect. Move constructing *in general* leaves the old object in a valid-but-unspecified state. However, for unique_ptr *in particular*, the state is specified! The standard requires a moved from unique_ptr to contain nullptr.

In the code seen at ~4:10, what if use_widget was a function expecting to take ownership of the raw pointer being passed in (i.e. it deletes it before it returns)? I understand that passing in get() would be a bug since the underlying raw pointer would become unusable (since it's deleted) and would be double-deleted whenever the smart pointer is destructed. As suggested later in the video, the correct thing to do is to instead pass release() but you still need to know/remember/respect the contract of the function (which is not implied by a signature with Widget* as a parameter) that it deletes the pointer it's passed. I've heard advice (I think Jason Turner?) that you absolutely _should_ refactor functions to take a unique_ptr parameter when they take ownership in this way. Saying your parameter is a unique_ptr (and therefore forcing your caller to std::move it in) very explicitly states that the function claims (unique) ownership of that argument.

@mCoding

Жыл бұрын

Yes absolutely! Code involving ownership of the pointer, such as code that previously deleted or newed objects would need to be refactored to use unique_ptr. It's just the code in the middle (between new and delete) that just uses the pointer that shouldn't need refactoring.

@anon_y_mousse

Жыл бұрын

And as always, good documentation is key. Which I would count your last sentence of having the parameter specifically be a unique_ptr to be the documentation.

Great video as always! I'd love a video on CPython vs PyPy (and any other alternative python implementations). Thanks!

Hi, great video and style, but I don't get the argument behind vector of pointers instead of vector of actual objects - due to class inheritance hierarchy. What do you mean by that? How is inheritance related to pointers decision? Thanks!

@mCoding

Жыл бұрын

Thank you! A subclass may not have the same size as its parent, so you can't store them in the same vector, but you can store pointers to those objects. You could use a vector of variants/unions instead, but a vector of pointers tends to be more commonly used, though both approaches fit different situations.

Wouldn't it be a good habit to default initialize m_ptr to nullptr like `T *m_ptr { nullptr };'?

I feel like every coding channel should have an anonymous bulletin board where people can post code and ask questions. Like a godbolt page or something, that way we wouldn't have to be hindered by KZread's dislike of external URL's. Although, I suppose it could get out of hand when a channel has over 100k subs. Not everyone asks a question, but if it were easier to do so anonymously, I'd wager you'd get 10 times as many.

rip auto_ptr

@mCoding

Жыл бұрын

He who shall not be named

@init_yeah

Жыл бұрын

@@mCoding hahhahah

yeah modern c++ is the shit. good video 👍 ive implemented my own array type using smart pointers and it was nice to see a video on something ive recently wanted to learn about

In reset method(8:14) why didn't you delete m_ptr first before assigning ptr(no need for std::exchange)? At first I thought it was in case delete threw, ptr would be deleted but if that happened then: 1. it would result in undefined behavior 2. reset is noexcept so std::terminate would be called which doesn't call any destructors(I'm not sure)? So either it's for future Deleter or I'm just too focused on 'optimizing'. After checking GCC with -O2 flag makes almost identical assembly code.

@anon_y_mousse

Жыл бұрын

It's basically just a shorthand for "using" std::move twice. I used quotes to point it out and say that I don't mean the keyword using, but rather the English verb.

@mCoding

Жыл бұрын

See stackoverflow.com/questions/69006612/stdunique-ptr-reset-order-of-operations for discussion. It has to do with (admittedly questionable) cases where an object holds the unique pointer that owns the object. You could perfectly well not support this kind of situation if you wanted and that would be a fine design decision.

7:20 i use lots of this sort of thing for my opengl project where i have a glGen*(1, &...); call followed by a glDelete*(1, &...); in the destructor

Shouldn't reset() have code to guard against setting the same pointer that was already set?

@mCoding

Жыл бұрын

It's up to you but the real std::unique_ptr does not guard against this.

You could create a series where you re-implement the STL in a way that's easier to understand. It would be a valuable reference for better comprehension. You could name it KISS, which stands for "Keep It Simple, Stupid".

@anon_y_mousse

Жыл бұрын

SSTL, Simple Standard Template Library.

5:11 meanwhile me doing my C assignment in assembly and then using `asm()` for everything

Hi, James. Can you make a video about using C/C++ with Python?

@mCoding

Жыл бұрын

Perhaps, what did you have in mind?

@user-gt2th3wz9c

Жыл бұрын

@@mCoding Actually, I write either in Python or C++ and don't understand when I can use both languages. You are always showing great examples, so I thought you know when it is useful. Also, it is interesting how to write extensions that release GIL.

Does Python have something similar to smart pointers?

@mCoding

Жыл бұрын

All Python objects are effectively shared_ptr's (although literally CPython is written in C, not C++). They have pointer semantics and use reference counting to determine when to free the pointers under the hood, which is exactly what shared_ptr does.

@SkyFly19853

Жыл бұрын

@@mCoding Similar to Cython.

le discord gang as usual

3:20 constructing one yourself vs using std::make_unique are the same, but std::make_unique does have the advantage of being less verbose

04:24 - "...all the code in the middle ... should not changed" - isn't better to add `use_widget(std::shared_prt widged)` instead `use_widget` with "raw" pointer?

@mCoding

Жыл бұрын

This is a common misconception. Keep in mind that shared_ptr incurs a significant runtime cost due to atomic reference counting. It is the best choice in some situations, especially when multiple unrelated parts of the code need to keep an object alive. But if you can determine a unique owner whose lifetime encapsulates the lifetime of the pointed to object, then you should not need to change code to take shared_ptr or even unique_ptr except for code that deals with managing the lifetime. Code that simply needs a Widget should continue using raw pointers and references.

@CAMOBAP795

Жыл бұрын

@@mCoding Thanks for explanation. Just to be on the same page "some situation" it's mostly multithreaded environment, right?

Oh gosh, the opening sentence. Thus should be the first sentence in all cpp materials out there. Every time the language comes up everybody talk it down like it is 2003 again.

Make more C++ videos please thank you.

8:56 is the guard even needed here? nothing bad would even happen if the guard is omitted

How can i upvote this twice

1:49 Doesn’t C++ have the equivalent of try/finally?

@failgun

Жыл бұрын

Yes of course, but the point he's making is that you still have to _remember_ to write that try/catch block and properly handle the case where the vector elements are only partially constucted.

@mCoding

Жыл бұрын

C++ has try/catch, but it does not have try/finally. The purpose of try/finally is to ensure resources are cleaned up, but in C++ this is the purpose of destructors, so C++ does not include try/finally, forcing you to use a destructor instead. The design decision is widely criticized but unlikely to change.

@lawrencedoliveiro9104

Жыл бұрын

Actually, there is a way to write code to gracefully handle partial construction and proper cleanup: aHR0cHM6Ly9naXRodWIuY29tL2xkby9hX3N0cnVjdHVyZWRfZGlzY2lwbGluZV9vZl9wcm9ncmFtbWluZy8=

@anon_y_mousse

Жыл бұрын

@@lawrencedoliveiro9104 Interesting example, but what about say an array of objects with each needing instantiation and all previous objects needing cleanup in case one fails at some point in the middle of instantiation of the array? Obviously PyObjects will be fine, since IIRC it uses GC, but what about objects not managed by Python? Also, while I understand the desire to eliminate goto, I don't really agree with it. For each allocation action I use inside a function I add a label at the end to handle that case then merely goto that label in an incrementing manner. I find it easier to read than a series of nested do/while(false) loops, but that may just be me.

@lawrencedoliveiro9104

Жыл бұрын

@@anon_y_mousse My examples did not rely on Python’s garbage collection to clean things up: the point of the code structure is to manage all this explicitly, yet in an easy-to-manage, easy-to-understand way. And yes, avoiding gotos falls naturally out of this control discipline.

modern c++ gives me a "Hey rust, can I copy your homework" vibes

@mCoding

Жыл бұрын

unique_ptr was introduced in C++11 (around 2011), whereas Rust first appeared in 2015. So who really copied whom? 🤔

Makes me realize how out of practice I am with C++, and I think how outdated my C++ was even when I was using it.

@mCoding

Жыл бұрын

Today is always the best day to get started practicing!

any plans on teaching us Rust?

@mCoding

Жыл бұрын

Not at the moment

@isaacchen3857

Жыл бұрын

@@mCoding I'd love to see some Rust content as well

@dmitriidemenev5258

Жыл бұрын

​@@mCoding I'd love to see you teach some Rust as well

How about more algorithms and how to solve them in Python or C++? It would be useful, especially for those with no background in CS.

I've never come across a use for pointers of any kind in c++. I tend to allocate everything on the stack & pass variables by reference.

@Djellowman

Жыл бұрын

Need some data that is allocated higher up the stack? Just pass it back down by returning

@mCoding

Жыл бұрын

This is a reasonable thing to do, sometimes even necessary for certain applications e.g. where dynamic allocations are forbidden.

@Djellowman

Жыл бұрын

@@mCoding also avoids the need to check for mem leaks ;-) although i guess that's also true when using unique_ptr

@TechSY730

Жыл бұрын

Good idea. Generally, the more you can avoid the heap or dynamic allocation, the better. However for beeg objects/arrays, you will start brushing up against stack size limits. Or sometimes there are cases where the API you are using demands that the object you make survives past the return of the function that currently owns it, but not by a return value. (Such an API I would question the design of, but you don't always get a choice) In these cases, yea, you gotta get your hands dirty with pointer-ish stuff. Though as shown, smart pointer objects help a lot with this.

@anon_y_mousse

Жыл бұрын

@@TechSY730 Sure, but the internal implementation can still heap allocate. What you put on the stack in an instance like this is merely a wrapper around the meat of the object. Say an array class of some kind would store a pointer to the data, so what's on the heap is just a couple of unsigned integers and a pointer to whatever type you're storing in that array class.

0:01 just like with Javascript…

Also unique ptr doesnt support polymorphism though. I tried using it but only sharedptr can

@mCoding

5 ай бұрын

I'm not sure what you mean by unique ptr does not support polymorphism. If you have a unique ptr to a derived object and call a virtual function, it will call the derived version of the function. It exhibits the same behavior as a raw pointer does with respect to polymorphism. Perhaps you forgot to mark your destructor or other function virtual?

This is why Rust is the way

Call this C++arcinization because every change that improves C++ makes the Dev evolve into something more like a Rustacean...

@anon_y_mousse

Жыл бұрын

Which is better, more syntax or more code? Consider that if syntax is added to the language that it can't be changed as easily as mere code and provides a barrier to entry for new programmers because now they have to look up a symbol to determine what it means instead of looking up a whole word. Also consider that these concepts were thought up long before Rust existed and it's just copying a good concept from better programmers, albeit with horrible syntax additions.

Hi

@mCoding

Жыл бұрын

Hello!

Bruh... use rust.

@cristian-si1gb

Жыл бұрын

Doesn't Rust also have the exact same concept? It's just called Box