Conversion Operators in C++

To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/TheCherno . You’ll also get 20% off an annual premium subscription.
Hazel ► get.hazelengine.com
Patreon ► / thecherno
Instagram ► / thecherno
Twitter ► / thecherno
Discord ► / discord
📚 CHAPTERS
0:00 - What are Conversion Operators in C++
9:40 - Real world BUG
13:54 - Real world example
Hazel ► hazelengine.com
🕹️ Play Dichotomy for FREE (made in Hazel!) ► studiocherno.itch.io/dichotomy
🌏 Need web hosting? ► hostinger.com/cherno
💰 Links to stuff I use:
⌨ Keyboard ► geni.us/T2J7
🐭 Mouse ► geni.us/BuY7
💻 Monitors ► geni.us/wZFSwSK
This video is sponsored by Brilliant.

Пікірлер: 182

  • @TheCherno
    @TheChernoАй бұрын

    What should I cover next in the C++ series? Let me know below 👇 You can try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/TheCherno . You’ll also get 20% off an annual premium subscription.

  • @user-ib3ev5pl2t

    @user-ib3ev5pl2t

    Ай бұрын

    variadic templates would be just perfect theme for next video!!! like how to make tuple with them etc

  • @nortski78

    @nortski78

    Ай бұрын

    Std::move and std:: forward next please 🙂

  • @nortski78

    @nortski78

    Ай бұрын

    ​@@user-ib3ev5pl2tare you following the same game dev course as me? Thats exactly where im stuck lol

  • @abacaabaca8131

    @abacaabaca8131

    Ай бұрын

    Do you mind explain the code """ for(const auto& [name, perFrameData] : prevFrameData) """ @13:08

  • @tomasruzicka9835

    @tomasruzicka9835

    Ай бұрын

    Hi, I agree with the "optional unwrap" being a conversion, but the is ready seems like ... well ... it doesn't seem like a conversion but more like a query. Basically you use the same language to describe to semantically different operations. await vs query. What would happen if he thing you are awaiting (the mesh here) would be convertible to bool as well. Should the compiler pick the longer conversion chain or not? If it's not ambiguous it is something you would never remember as an avarage c++ programmer. (At work we use !!some_var to force the bool conversion, I don't like that either tho 😀)

  • @tiwanndev
    @tiwanndevАй бұрын

    THE C++ SERIES IS BACK

  • @ankitanand3364
    @ankitanand3364Ай бұрын

    Multithreading , threadpool ,All threading concept for interview preparation will be damn helpful

  • @mjthebest7294
    @mjthebest7294Ай бұрын

    Next topic: the missing promised template videos.

  • @callmejobson

    @callmejobson

    Ай бұрын

    lmao I just got to that section in the course!

  • @antagonista8122
    @antagonista8122Ай бұрын

    Pretty much 99% of conversions operators should be marked explicit (even boolean ones) to prevent weird bugs and unexpected conversions from happening and here is not a single word about it, kinda disappointing. The only exceptions are objects intended to emulate/behave like completely different type, such as std::vector::reference proxy.

  • @epiphaeny

    @epiphaeny

    Ай бұрын

    I just wanted to write the same... 👍 I actually do like conversion operators, but they can create many problems. So imo it's better to use them sparingly and when with explicit. Still, in some places they can enable things that weren't possible otherwise.

  • @bsdooby

    @bsdooby

    Ай бұрын

    @@epiphaeny How would explicit help in that case? Conversion ops are there to not have explicits, aren't they?

  • @duckdoom5

    @duckdoom5

    Ай бұрын

    @bsdooby No, not necessarily. Take Color as an example. You might want to be able to convert it into 4 floats (vec4f). In this case you want to have the option to do so, but should really require that operation to be explicit to prevent weird bugs and make the code more readable. You can see that it's converting to vec4. Also the real issue comes form having multiple conversion operators. Say if the vec4 also had one that implicitly converts to 'something else'. Now passing the color could first convert to vec4 implicitly and then from vec4 to 'something else', all in the same place

  • @adam3141

    @adam3141

    3 күн бұрын

    Was just going to mention this myself. Like with single argument constructors, the default should be to add the explicit keyword and only omit if absolutely necessary

  • @GameboySR
    @GameboySRАй бұрын

    I literally spent a day on debugging this at work two days ago. I was doing a rewrite of our logging system, because the old one sufferred from deadlocks and memory errors. In a few instances, there were logs which logged 8 different variables. Most of the variables were custom types, even though they really represented primitive types, such as int8_t, int16_t, etc. And those custom types also had overloaded conversion operators to those original types. They were formatted via fmt::format, but since we are already using C++20, we agreed to migrate all fmt instances to std::format. In the editor, the code behaved like all was well, but when I tried to compile it, I got several pages worth of an error log per call of that 8-variable log. Turns out, I had to manually convert them to their primitive types, because even though by syntax it was all nice and well, the compiler didn't like that std::format didn't know how to handle those custom types.

  • @ChrisCarlos64

    @ChrisCarlos64

    Ай бұрын

    I hope this isn't coming off crude, but I am wondering, why would you change from fmt lib to std::format if you already had it in your code? Was it to create one less dependency? I feel as if I wouldn't have bothered touching that, but also because it creates less a hard reliance on upping the C++ version support, unless that was intentional too.

  • @sledgex9

    @sledgex9

    23 күн бұрын

    Did you get compiler errors? If so, you're golden. Cherno describes a situation where the code compiles fine but during runtime it fails. That's way more difficult to spot and debug.

  • @GameboySR

    @GameboySR

    22 күн бұрын

    @@sledgex9 Yeah, I pray that is not my case, haha

  • @jamesmnguyen
    @jamesmnguyenАй бұрын

    I use conversion operators a lot for my custom math library. Being to cast a 2d vector of ints into a 3d vector of floats is pretty nice.

  • @cyqry

    @cyqry

    Ай бұрын

    I've used conversion operators for something similar to this. Libraries I'm currently using are Raylib, ReactPhysics3D, and Recast Navigation. All three have their own versions of Vector2/3, Matrix and Quaternion. Most of the time they are the exact same, a Vector3 is usually just three floats in a struct for example... but having my own maths library that has conversion operators to all three libraries has helped massively. Before using this approach, I was having to take an RP3D Vector3 for the physics object position and convert it to a Raylib Vector3D to update the object's position (for rendering) and to RecastNav Vector3 for navigation.

  • @sergeikulenkov
    @sergeikulenkovАй бұрын

    Great tutorial-explanation, simple example, real-world example, important issues. (also really like the new mic)

  • @BryceDixonDev
    @BryceDixonDevАй бұрын

    Word of advice to anyone looking at implementing conversion operators for their own types: be *extremely* conservative with them. Mark every one as `explicit` and even then *deeply* question if just using a named function would be better. There are some *extremely rare* cases where a conversion operator makes sense, like a container of `int`s being castable to that same container of `float`s, but in the vast majority of cases having implicit (or even explicit) `bool` conversions from complex types (especially if that conversion is non-trivial) because you think `if (my_thing) {}` just looks cleaner than `if (!my_thing.empty()) {}` will only lead to confusion and headache in the long-run. It's incredibly frustrating that the STL's smart pointers only implement `operator bool` rather than an `bool empty()` member function because it's just another thing you need to memorize the behavior for and potentially without any clear terms to search for.

  • @benhetland576

    @benhetland576

    Ай бұрын

    As for things like containers and other rather complex types I do agree this is a very good advice. I have seen elsewhere people pointing out that the method name "empty()" perhaps was a very poor choice since it is ambiguous. Does it empty the container? Who knows... (Ok, we know the method is actually "clear()" which isn't all that much clearer either.) It should probably have been called something like "isempty()" instead. Anyway, as for the _pointers_ and things that behave like pointers (e.g. smart pointers) I don't think enforcing things like .empty() makes it any clearer at all. (What is an 'empty' pointer btw?) I claim that a pointer type _is_ a boolean type in and of itself; it has the trait that it either "points" (to something) or it doesn't. That's a pointer's two possible states -- boolean in nature. What it points _to_ is not necessarily boolean, but the pointer itself is. Therefore writing things like "if (ptr != NULL)" or "if (ptr == nullptr)" becomes overstating the obvious, just like if you have a "bool is_ready;" and then write "if (is_ready == true)". They all serve nothing but adding verbosity, potentially burying the more significant words. Writing "if (ptr)" or "if (!is_ready)" is both shorter and clearer, as well as following an old and well known idiom in both C and C++. Please don't write Java or Fortran in C++ source files! I somehow expect to see someone writing "if ((is_ready == yes) == true)" any time soon now 'just to be extra clear and unambiguous of the intension' :-)

  • @BryceDixonDev

    @BryceDixonDev

    17 күн бұрын

    @@benhetland576 I disagree, but I also know this is a matter of opinion. I think the problem with implicit conversions is that they can happen without your knowledge and can incur an unseen cost. "Smart pointers" *are not* pointers, they are non-trivial class objects; in me experience, less established treating them like pointers has led to a ton of misunderstanding about how they work and edge-cases in their usage (eg: for a pointer, `&*p` does nothing and may even be removed by the compiler, but for a smart pointer you end up with a completely different type). I agree `is_empty` would be a much better name than `empty`, but since it's basically never going to change I stick with `empty` when talking about hypotheticals as well. std::optional uses `has_value` which might be better for smart pointers. My point is that in order to even know how the implicit boolean conversion will work you need to know the type of the object being converted which sometimes isn't possible (templates, `auto`).

  • @benhetland576

    @benhetland576

    17 күн бұрын

    @@BryceDixonDev Yes, 'auto' can be a nasty beast sometimes. I think most of its motivation was actually to save some typing with the insanely long templated type names, which again may be regarded as a somewhat unfortunate development in C++. So it is mostly a convenience for "lazy" typists, but it does require familiarity with the type inference rules. As for the "&*p" syntax I don't believe a C++ compiler is at liberty to eliminate it (I admit I didn't actually check what the standard says). This is because both operators may be overloaded even for non-class types, so either or both may return something completely non-intuitive. (&*p may also be different from *&p) This is in part what the smart pointers exploit. The two operators may not be the inverse of each other, and this must be at least taken into account by compilers as well as programmers. In C the matter is different, and there it might be permitted to eliminate them without breaking semantics.

  • @skilz8098

    @skilz8098

    16 күн бұрын

    @@benhetland576 I kind of agree with your assessment. Most of us through use know what container.empty() is, yet I one would think that container.is_empty() would be much more clear. One would think that if a type to be returned is a bool where it's typically a question that can be answered with either yes or a no, would have the qualifying transitive verb of "is" to indicate that it's a question of state rather than just "empty" as in a verbal action of something to be done.

  • @mr.anderson5077
    @mr.anderson5077Ай бұрын

    Finally my man is back please keep these coming

  • @Beatsbasteln
    @BeatsbastelnАй бұрын

    nice one! didn't know that yet, but i'm already a big fan of operator overloading and this seems similiar

  • @landspide
    @landspideАй бұрын

    I used this years ago to make converting my own rect/point/etc objects to win32 api struct equivalents. Worked fine.

  • @S0Eric
    @S0EricАй бұрын

    I appreciate these thorough, efficient, fair minded, and educational explorations of specific topics.

  • @mihaelasimerea9700
    @mihaelasimerea9700Ай бұрын

    Thank you so much for making this video 👍👍👍

  • @kadirberkyagar7143
    @kadirberkyagar7143Ай бұрын

    finally! that long awaited topic!

  • @G1g4ntvltLP
    @G1g4ntvltLPАй бұрын

    Nice Video! As for the next c++ series episode: Maybe explain how to make things threadsafe, for example your Ref class, which needs to be thread safe. Would be super interesting

  • @parhamtaherkhany5357
    @parhamtaherkhany5357Ай бұрын

    Finally! A new video after a long time😄

  • @robn2497
    @robn2497Ай бұрын

    I'm learning C++ now thanks to your videos, thankyou!

  • @akadetrorjk
    @akadetrorjkАй бұрын

    New cherno video, life's good.

  • @shavais33
    @shavais33Ай бұрын

    re: what to cover next in the C++ series I'm not sure if you have yet covered these? - constexpr - async/await - C++ 20 modules. - C++20 "concepts" (template parameter (?) constraints)

  • @peppebck
    @peppebck8 күн бұрын

    always very usefull. I don't use conversion operator. I have a MyString class for example but I neither use the operator char* because sometimes I have to cast it anyway (as you shown). so I prefer to be forced to use methods and fields. It's safer and more readable (and I mantain a TON of code). Good to know C++ series is back. I learned a LOT from it!!!

  • @hyper-stack
    @hyper-stackАй бұрын

    i love this c++ series

  • @ahmadshbat8363
    @ahmadshbat8363Ай бұрын

    Man, I know this kind of topic, but I felt happy when you uploaded this vid Cuz it is not about your personal engine's emotion stories as u regularly do.

  • @sinom
    @sinomАй бұрын

    A way of making it more obvious without making it (much) more verbose is using template parameters. std::milli, std::micro etc. already exist, and you can just give the class a template parameter that sets what standard conversion does if you really want conversion, and you can have just one templated get function which then based on the ratio in in the template parameter gives you the format you actually want without any runtime slowdowns etc.

  • @vaijns
    @vaijnsАй бұрын

    Would be good to also talk about explicit vs implicit conversion operators. If you mark your operator as explicit: class my_class{ public: explicit operator bool() const{ return true; } }; you can cast to a bool like this: bool my_value = static_cast(my_class{}); but not like this: bool my_value = my_class{}; which you can without marking it as explicit. So you can't do it by accident.

  • @GameDevBeat
    @GameDevBeatАй бұрын

    Thanks cherno you really helped our community.❤

  • @velikanskaglava2087
    @velikanskaglava2087Ай бұрын

    Thank you!

  • @afmikasenpai
    @afmikasenpaiАй бұрын

    damn real thanks I never knew about this operator!

  • @theblock9221
    @theblock9221Ай бұрын

    Let's goooo were back

  • @anon_y_mousse
    @anon_y_mousseАй бұрын

    I think my favorite operator is the UDL suffix operator. I've been working on a measurement library and implementing all kinds of operations to allow quick and easy conversions. For instance, I can do distance d = 1ft; then d /= 12; and print it out and get 1in or I can have d = 1ft; d += 1in; and printing it out yields 13in. It's a lot of fun.

  • @vaijns

    @vaijns

    Ай бұрын

    if you're using literally (hehe) literals such as "ft" that's actually an ill-formed program as user-defined literals have to start with an '_' (so: 2_ft e.g.) because those without one are reserved for future standard library use. While compilers might allow you to do it (and maybe just print a warning) you should think about changing it and conforming with the standard.

  • @anon_y_mousse

    @anon_y_mousse

    Ай бұрын

    @@vaijns No thanks. I'm just using it as a testbed for ideas I'm putting into my own language, and my language doesn't force such things into the global namespace by default. For my language you'll have to import a particular module to use them and further place that module into the global namespace to make use of them as just 1ft or 2in and so on. My language also doesn't have rules about polluting namespaces because it's up to you the user to place things where you want to use them. I've always hated the idiomatic method in C++ of only using standard things through std:: and with a proper module system I would hope that becomes a thing of the past, but I haven't read what they're doing with modules yet and I'm nearly done with my own language anyway.

  • @switchix5029
    @switchix5029Ай бұрын

    Implicit casts / overloaded conversions are the first step to hell

  • @ea_naseer

    @ea_naseer

    Ай бұрын

    you'd think imgui would parse the string and then cast all parameters just to be sure and throw the necessary errors I mean even inputs from scanf are casted to their types.

  • @shavais33
    @shavais33Ай бұрын

    I just saw an interview of Bjarne Stroustrup in which he said that implicit conversions were not his idea and they were a mistake that he tried to get rid of at one point, but the C++ powers that were at the time wouldn't have it and soon thereafter it became too late.

  • @kakalisaha9428
    @kakalisaha9428Ай бұрын

    Yay itz back but sir please start a vulkan series. Please🙏🙏🙏🙏

  • @root0062
    @root0062Ай бұрын

    Woah, I had to check the date to see if this wasn't an older one I had missed.

  • @xaesthetics1769
    @xaesthetics1769Ай бұрын

    yay a new videooo

  • @user-rd4cj7fs7k
    @user-rd4cj7fs7kАй бұрын

    As a Chinese high school student, I like your C course very much. Thank you teacher. It would be perfect if you make a collection video.

  • @peppebck
    @peppebck8 күн бұрын

    I'd like to know how you detect those memory error that just cause a crash each now and then and often in a different part of the code bacause another piece of code messed up the memory. Threads and threadpool also. thanks a lot.

  • @jmlopezponce
    @jmlopezponceАй бұрын

    Templates :). I read an article about how use templates in classes in different files (.h and .cpp). The article said that you include at the end of the .h file the .cpp file. I mean literally including it: #include "class.cpp". Also said " it's magic, don't ask why. " That could be a nice topic to talk about, not only in the vsc++ but also in gcc/g++ on Linux . Stuffs like instancing an specific type of a class method (only for in the actual implementation do something with that type) is not allowed directly (as far as I know), although can be emulated.

  • @monad_tcp
    @monad_tcpАй бұрын

    Conversion Operators are surprising side effects in a lot of cases, which is why they weren't included in F# and most ML languages, you have to explicitly call a function to convert one thing to another. The same perils happens on C#, ironically with conversion operators.

  • @redcrafterlppa303
    @redcrafterlppa303Ай бұрын

    In my opinion all conversation operators should be explicit and using format strings should be avoided whenever possible.

  • @duckdoom5
    @duckdoom5Ай бұрын

    @TheCherno You should really use 'explicit' on boolean conversion operators. That bit me in the but many times in my project. You would still be able to do 'if (entity)' without the explicit cast, but it won't allow something like 'MyFunction(entity)' where MyFunction is defined as 'MyFunction(int x)'.

  • @ilieschamkar6767
    @ilieschamkar6767Ай бұрын

    I love conversion operator :)

  • @tobyuuuuu
    @tobyuuuuuАй бұрын

    How does the async load asset function work? I don‘t see where it is blocking until loaded before isReady is true…

  • @NotNotAsian
    @NotNotAsian5 күн бұрын

    13:26 I feel like if you are going to be casting to a float then maybe its not really a float you are after in this case. You are after milli / secs or some sort of time. So maybe adding a typedef (Which ultimately ends up being a float) for that would make it clearer. You are right that the implicit casting is dangerous, but I really like it as a feature and want to make it useful somehow.

  • @NotNotAsian

    @NotNotAsian

    5 күн бұрын

    Actually after thinking about it, casting to the type of data in that formatter is the "right" way of doing this imo, because. Although ImGui::Text() is defined elsewhere, its such an amorphous definition that its only really implemented at the point that it is called, which means the point that it is called should make the way that it is being called explicit. Since in this case the formatter is formatting as though the float supplied represents millis, then the variable for that format should be cast since that style of writing mimics normal function declaration. eg text(Format, millis, int) mimics text(String format, float millis, int samples)

  • @luisyebra7657
    @luisyebra765729 күн бұрын

    @The_Cherno what visual studio theme are you using in the tutorial?

  • @szirsp
    @szirsp24 күн бұрын

    19:20 I wouldn't say it keeps everything clean. I'd rather say having implicit conversion is more convenient (to write, or more precisely not to write code, but not necessarily to read, understand). It's a clever hack to make new behavior compatible with existing code. But implicit conversion makes it harder to understand the code (for everyone, but mainly new developers). It requires the reader to be familiar with the internals and have the implicit conversion on their mind, cache, increasing cognitive load. It's not strictly about code readability, it's faster to read less words, code. But to understand what is happening does not linearly correlate with word count. ;)

  • @zami001001
    @zami001001Ай бұрын

    Personally I am usually okay with bool conversion operators, but I very rarely go beyond that unless I'm making a type with the express intent of it behaving as another type just with added details behind the scenes, such as the smart reference that you use in hazel where you likely include a conversion operator to the referenced type.

  • @viliamjr
    @viliamjrАй бұрын

    To cover next: some context about C++ releases and what's new in C++23. What should we already be using from C++20?

  • @i_Have2BrainCells
    @i_Have2BrainCellsАй бұрын

    Will there be tutorial for modern c++ and all features of modern c++

  • @downbad.
    @downbad.Ай бұрын

    Please make a video on vptr and vtable

  • @omerhaciyev5001
    @omerhaciyev5001Ай бұрын

    what theme do you use in visual studio?

  • @kiyasuihito
    @kiyasuihitoАй бұрын

    How about socket programming in c++ or interoperability with other languages?

  • @AgentM124
    @AgentM124Ай бұрын

    Conversion is also only 1 level deep. If you have a conversion from A to B and B to C, you can't convert from A to C directly. (Which is a good thing imo)

  • @ohwow2074
    @ohwow2074Ай бұрын

    I use them with care. Sometimes they're nasty. In those cases I add a couple of to_underlying() functions to the struct to do the explicit conversation for me.

  • @jks234
    @jks234Ай бұрын

    I find the culture of programming in each language very interesting. Personally, as a programmer that started in Java, I loved being crystal clear about what each method and variable did with my names. But... in C++, it often feels like that isn't really the highest priority in general. Intuitiveness and clarity is much less emphasized and things like... "less code" is prized more. Perhaps it is because C++ means people might come from even lower, and they are used to programming for performance and space saving. So naming and intuitiveness is a luxury, and y rite in cumpleet wrds wen u kn save a few kb her n ther.

  • @Brahvim

    @Brahvim

    Ай бұрын

    Very true! I'm also one who started with Java, but I see things similarly.

  • @SilentFire08

    @SilentFire08

    Ай бұрын

    As someone who also started with java has their first language I can agree with you completely, I also think the "less code is prized" idea comes from the idea that the more code you write the more likely you are to shoot yourself in the foot (more likely to mess up).

  • @y_arml

    @y_arml

    Ай бұрын

    ​@@SilentFire08 In general I think it's much the opposite, the more explicit you are the less likely you are to shoot yourself in the foot ... especially with these implicit conversions

  • @Zly_u

    @Zly_u

    Ай бұрын

    Nowadays, it's a matter of preference and how people learned how to code in C++ imo. People can explicitly choose to do more implicit stuff, some don't. I, personally, from the very beginning, always preferred explicit writing and make my code as convenient and easy to understand so there is less guessing to do. Ofc some things are no brainers there because there are a bunch of common practices that are done in C++ that may throw some people off, those people probably never studied the language like from the very basics of it but instead just decided to dive into it without any preparation, or something like that. Common practices exist everywhere. And at my work where we do C++ the "less code" is not prized, and I also never prized this idea, it's very stupid, and C++ is my first language as well and it's great. (and easy hehe)

  • @luz_reyes_676

    @luz_reyes_676

    Ай бұрын

    I write C and Python code at work. I really like Python in that I can be lazy as possible and have the language do everything for me. So typing less. Less words. Less code. Keep things simple and let the computers do all the work.

  • @kyantum
    @kyantumАй бұрын

    WE ARE SO BACK RAHHHH

  • @lilgohan
    @lilgohanАй бұрын

    this series needs to come back lol

  • @user-me8dk7ds7f
    @user-me8dk7ds7fАй бұрын

    Finally!!!!!

  • @sorek__
    @sorek__Ай бұрын

    Operator overloading is AWESOME feature of C++. I had problem on my embedded system with big array of "past" values for my logging that just grew a lot for each parameter. I solved it by drop-in-replacement of Half library which basically implements float as 16 bit with less precision. It was so awesome to just be able to do simple typedef and swap normal float like that.. Just insane.

  • @obinator9065
    @obinator9065Ай бұрын

    0:23 totally not me 👀

  • @nextlifeonearth
    @nextlifeonearthАй бұрын

    The issue with the bug to me sounds like it's more of a bug with c style variatic arguments. If they used variatic template arguments, the type is retained and therefore the context of the type. This would never have happened with fmt lib for instance.

  • @Veeq7
    @Veeq7Ай бұрын

    Imho the bug is more of a problem of printf like interface rather than conversion operator (it can also happen with custom structs, or even std::string), with std::format it wouldn't happen. And then regarding implicit conversions, ideally just use auto, that always prevents implicit conversions and is still very readable. The first example of seconds vs miliseconds is probably the most convincing anti-case, however do you really use miliseconds as a double in a game engine? :P

  • @maarten1012TTT
    @maarten1012TTTАй бұрын

    What are your feelings about c-style initializers vs "modern" style? E.g int a = 2; vs int a(2);

  • @xTriplexS
    @xTriplexSАй бұрын

    We are so fucking back

  • @dario3rnandez
    @dario3rnandezАй бұрын

    Utilizo tus videos para aprender ingles y c++

  • @PedroOliveira-sl6nw
    @PedroOliveira-sl6nwАй бұрын

    16:21 Use can also use "auto" ...

  • @herrdingenz6295
    @herrdingenz6295Ай бұрын

    3:50 again you forgot to link the video you're talking about "up there" :D

  • @rosiskharel389

    @rosiskharel389

    Ай бұрын

    at this point, i'll be disappointed if he actually links it.

  • @TheCherno

    @TheCherno

    Ай бұрын

    @@rosiskharel389 be disappointed

  • @user-gv9zx3io6q
    @user-gv9zx3io6q32 минут бұрын

    Anyone knows what's the font family cherno is using? Thanks

  • @a_cats
    @a_catsАй бұрын

    it's happening i can't believe it

  • @codinablack
    @codinablack6 сағат бұрын

    I thought pointers were automatically deleted when they go out of scope, if they were defined in that scope, and not moved or assigned anywhere... is this not fact?

  • @kanecassidy9126
    @kanecassidy9126Ай бұрын

    shouldn't you use conversion operators with "explicit" keyword to prevent unwanted conversions?

  • @MeneerVerspiller
    @MeneerVerspillerАй бұрын

    I think the problem is that you can seemingly use a variable while in actually an implicit conversion and maybe a nontrivial one is executed. That is bad code practice. I can see their use in an integer container type and implicit float conversion. So I dont like them too much. I like explicit code, because then it is very clear what is happening and when something wrong is happing.

  • @katanamajesty
    @katanamajestyАй бұрын

    Just wondering why you would not synchronize access to bool AsyncAssetResult::IsReady? I suppose the flag would be set from another thread on load completion, wouldnt it? Correct me if im wrong, but it is not safe to do that and volatile/atomic should be rather used?

  • @benhetland576

    @benhetland576

    Ай бұрын

    After C++11 there are also the std::promise and std::future templates to do this kind of stuff.

  • @KovidhVSBhati
    @KovidhVSBhati28 күн бұрын

    please make a video on static_cast

  • @TheAkatran
    @TheAkatranАй бұрын

    I like your microphone! It's one of the theatrical types, right? It catches your voice no matter how far away you are!

  • @a_cats
    @a_catsАй бұрын

    What visual studio theme do you use?

  • @digitalman9588

    @digitalman9588

    Ай бұрын

    Its the visual assist extension, I'm pretty sure its paid though.

  • @AbdullahGameDev

    @AbdullahGameDev

    Ай бұрын

    You can change the class color and variables colors and so on manually and make it your own theme.

  • @hououinkyouma2426
    @hououinkyouma2426Ай бұрын

    I love your C++

  • @w3arthur
    @w3arthurАй бұрын

    Got a job because of your courses, Thank you.

  • @wickedprotagonist6600
    @wickedprotagonist660020 күн бұрын

    Which font style is this?

  • @tsvetan4431
    @tsvetan4431Ай бұрын

    LETSGO🎉

  • @nofunsir
    @nofunsirАй бұрын

    Can you imagine flying in an 737-MAX that gets its angle-of-attack float data using a conversion operator?

  • @fjxokt
    @fjxoktАй бұрын

    That sounds cool, but it introduces a whole new world of potential bugs

  • @TsvetanDimitrov1976
    @TsvetanDimitrov1976Ай бұрын

    Nothing wrong with conversion operators, but as a general rule I always make them explicit. The same applies to 1 argument ctors. I don't want implicit conversions happening without me knowing about them.

  • @errodememoria
    @errodememoriaАй бұрын

    As a C/Rust programmer, I really don't like operator overloading, but it was a good video as always

  • @pxolqopt3597

    @pxolqopt3597

    Ай бұрын

    Operator overloading is fine imo as long as there is no ambiguity with whats happening

  • @zdspider6778
    @zdspider6778Ай бұрын

    This series is down to 1 episode per Visual Studio release version, huh?

  • @kango4457
    @kango445713 күн бұрын

    your timer is multiplying by a float and returning a double? you might want to use 0.01 without the f to ensure it's a double literal

  • @gracicot42
    @gracicot42Ай бұрын

    Wait until you delve in the insanity of templated conversion operators

  • @dj10schannel
    @dj10schannelАй бұрын

    Cool

  • @dongiannisiliadis9018
    @dongiannisiliadis9018Ай бұрын

    Let's goooo

  • @mehdi-vl5nn
    @mehdi-vl5nnАй бұрын

    ABI plz

  • @brockdaniel8845
    @brockdaniel8845Ай бұрын

    fking overloaaaad !

  • @NyanCoder
    @NyanCoderАй бұрын

    Complaining about vararg don't assuming that structure conversion operators, lol Jokes aside, I dunno, I've seen some people (even my lead grade co-worker) that thought varargs behave like typed arguments just because they mentioned the type in the string in first argument, causing UB's Never trust varargs! Always explicitly cast to what type you assuming when passing as an argument (like this `printf("%f ", (float)variable)`), otherwise it's always UB. For example in "Microsoft x64" calling conventions if your struct is larger than 8 bytes it will be passed as pointer, otherwise it passed as value (I don't remember how it was on unix-like systems)

  • @benhetland576

    @benhetland576

    Ай бұрын

    Well, the %f expects a double, but a float argument implicitly gets promoted to a double anyway when you call a variadic function like printf.

  • @NyanCoder

    @NyanCoder

    Ай бұрын

    @@benhetland576 As we seen in this video, people can put there an *object* thinking their *type conversion operator* will handle this, or from my experience something like *std::optional* to *%f* or *std::pair/std::tuple* into *%d,* that causes UB (first of all: it's not guaranteed by calling conventions where and how that argument and the rest arguments are placed, second: it's not guaranteed by standard how compilers implement those classes)

  • @paulzupan3732
    @paulzupan373223 күн бұрын

    Where's the type safety :(

  • @puddleglum5610
    @puddleglum5610Ай бұрын

    That AsyncAssetResult class using those cast operators is soooooo smelly. NEVER sacrifice long term readability for short term ease of making a refactoring PR. (Ok, maybe there are some acceptable reasons like very tight deadlines, etc). The long term bugs you’ll cause by adding that ambiguity will be waaaay more effort and headaches to diagnose and fix compared to the extra effort to make the initial refactor be clean and make sense.

  • @user-nj3lp5pp3l
    @user-nj3lp5pp3lАй бұрын

    OR you just don't use implicit conversions unless you're forced to by some API. Guess which approach saves you more time.

  • @hwstar9416
    @hwstar9416Ай бұрын

    would honestly never use this feature, the alternative is *barely* more code.

  • @guilherme5094
    @guilherme5094Ай бұрын

    👍

  • @Sniperfuchs
    @SniperfuchsАй бұрын

    Might just be very opinionated of me to say this, but from my experience as a software developer as soon as your team size is larger than 1, choosing to be less explicit to save like 5-10 characters is 100% a mistake. Especially since 9 times out of 10 it will be semantically incorrect afterwards unless the class you are converting from is nothing but a wrapper (like the std pointers). The timer example you showed perfectly covers everything that's dangerous with this. A timer is a timer. It's not a time value, by its very definition of how we understand that word in English.

  • @48_subhambanerjee22
    @48_subhambanerjee22Ай бұрын

    Lezzz gooo

  • @zdspider6778
    @zdspider6778Ай бұрын

    It's been a while.