Conversion Operators in C++

  Рет қаралды 35,872

The Cherno

The Cherno

Күн бұрын

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.

Пікірлер: 187
@TheCherno
@TheCherno 2 ай бұрын
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 2 ай бұрын
variadic templates would be just perfect theme for next video!!! like how to make tuple with them etc
@nortski78
@nortski78 2 ай бұрын
Std::move and std:: forward next please 🙂
@nortski78
@nortski78 2 ай бұрын
​@@user-ib3ev5pl2tare you following the same game dev course as me? Thats exactly where im stuck lol
@abacaabaca8131
@abacaabaca8131 2 ай бұрын
Do you mind explain the code """ for(const auto& [name, perFrameData] : prevFrameData) """ @13:08
@tomasruzicka9835
@tomasruzicka9835 2 ай бұрын
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 2 ай бұрын
THE C++ SERIES IS BACK
@mjthebest7294
@mjthebest7294 2 ай бұрын
Next topic: the missing promised template videos.
@callmejobson
@callmejobson 2 ай бұрын
lmao I just got to that section in the course!
@ankitanand3364
@ankitanand3364 2 ай бұрын
Multithreading , threadpool ,All threading concept for interview preparation will be damn helpful
@antagonista8122
@antagonista8122 2 ай бұрын
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 2 ай бұрын
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 2 ай бұрын
@@epiphaeny How would explicit help in that case? Conversion ops are there to not have explicits, aren't they?
@duckdoom5
@duckdoom5 2 ай бұрын
@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 Ай бұрын
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
@BryceDixonDev
@BryceDixonDev 2 ай бұрын
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 2 ай бұрын
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 2 ай бұрын
@@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 2 ай бұрын
@@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 2 ай бұрын
@@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.
@GameboySR
@GameboySR 2 ай бұрын
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 2 ай бұрын
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 2 ай бұрын
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 2 ай бұрын
@@sledgex9 Yeah, I pray that is not my case, haha
@jamesmnguyen
@jamesmnguyen 2 ай бұрын
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 2 ай бұрын
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.
@TheAndiKurz
@TheAndiKurz 20 күн бұрын
I really like the jetbrains IDEs for this, because they also show a symbol, if something is implicitly converted with an operator.
@sergeikulenkov
@sergeikulenkov 2 ай бұрын
Great tutorial-explanation, simple example, real-world example, important issues. (also really like the new mic)
@mr.anderson5077
@mr.anderson5077 2 ай бұрын
Finally my man is back please keep these coming
@landspide
@landspide 2 ай бұрын
I used this years ago to make converting my own rect/point/etc objects to win32 api struct equivalents. Worked fine.
@Beatsbasteln
@Beatsbasteln 2 ай бұрын
nice one! didn't know that yet, but i'm already a big fan of operator overloading and this seems similiar
@redcrafterlppa303
@redcrafterlppa303 2 ай бұрын
In my opinion all conversation operators should be explicit and using format strings should be avoided whenever possible.
@S0Eric
@S0Eric 2 ай бұрын
I appreciate these thorough, efficient, fair minded, and educational explorations of specific topics.
@robn2497
@robn2497 2 ай бұрын
I'm learning C++ now thanks to your videos, thankyou!
@shavais33
@shavais33 2 ай бұрын
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
@peppebck Ай бұрын
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!!!
@G1g4ntvltLP
@G1g4ntvltLP 2 ай бұрын
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
@sinom
@sinom 2 ай бұрын
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.
@mihaelasimerea9700
@mihaelasimerea9700 2 ай бұрын
Thank you so much for making this video 👍👍👍
@kadirberkyagar7143
@kadirberkyagar7143 2 ай бұрын
finally! that long awaited topic!
@parhamtaherkhany5357
@parhamtaherkhany5357 2 ай бұрын
Finally! A new video after a long time😄
@akadetrorjk
@akadetrorjk 2 ай бұрын
New cherno video, life's good.
@switchix5029
@switchix5029 2 ай бұрын
Implicit casts / overloaded conversions are the first step to hell
@ea_naseer
@ea_naseer 2 ай бұрын
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.
@vaijns
@vaijns 2 ай бұрын
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.
@anon_y_mousse
@anon_y_mousse 2 ай бұрын
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 2 ай бұрын
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 2 ай бұрын
@@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.
@maarten1012TTT
@maarten1012TTT 2 ай бұрын
What are your feelings about c-style initializers vs "modern" style? E.g int a = 2; vs int a(2);
@velikanskaglava2087
@velikanskaglava2087 2 ай бұрын
Thank you!
@hyper-stack
@hyper-stack 2 ай бұрын
i love this c++ series
@GameDevBeat
@GameDevBeat 2 ай бұрын
Thanks cherno you really helped our community.❤
@theblock9221
@theblock9221 2 ай бұрын
Let's goooo were back
@luisyebra7657
@luisyebra7657 2 ай бұрын
@The_Cherno what visual studio theme are you using in the tutorial?
@ahmadshbat8363
@ahmadshbat8363 2 ай бұрын
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.
@NotNotAsian
@NotNotAsian Ай бұрын
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 Ай бұрын
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)
@afmikasenpai
@afmikasenpai 2 ай бұрын
damn real thanks I never knew about this operator!
@duckdoom5
@duckdoom5 2 ай бұрын
@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)'.
@shavais33
@shavais33 2 ай бұрын
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.
@root0062
@root0062 2 ай бұрын
Woah, I had to check the date to see if this wasn't an older one I had missed.
@xy7914
@xy7914 17 күн бұрын
Could you please explain what do you mean by talking about the c++ learning curve, at the end of the video?
@omerhaciyev5001
@omerhaciyev5001 2 ай бұрын
what theme do you use in visual studio?
@monad_tcp
@monad_tcp 2 ай бұрын
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.
@user-rd4cj7fs7k
@user-rd4cj7fs7k 2 ай бұрын
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
@peppebck Ай бұрын
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.
@user-gv9zx3io6q
@user-gv9zx3io6q Ай бұрын
Anyone knows what's the font family cherno is using? Thanks
@kiyasuihito
@kiyasuihito 2 ай бұрын
How about socket programming in c++ or interoperability with other languages?
@szirsp
@szirsp 2 ай бұрын
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. ;)
@kakalisaha9428
@kakalisaha9428 2 ай бұрын
Yay itz back but sir please start a vulkan series. Please🙏🙏🙏🙏
@Testbot379
@Testbot379 Ай бұрын
Have you talked about object slicing yet?
@xaesthetics1769
@xaesthetics1769 2 ай бұрын
yay a new videooo
@tobyuuuuu
@tobyuuuuu 2 ай бұрын
How does the async load asset function work? I don‘t see where it is blocking until loaded before isReady is true…
@PedroOliveira-sl6nw
@PedroOliveira-sl6nw 2 ай бұрын
16:21 Use can also use "auto" ...
@Veeq7
@Veeq7 2 ай бұрын
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
@viliamjr
@viliamjr 2 ай бұрын
To cover next: some context about C++ releases and what's new in C++23. What should we already be using from C++20?
@AgentM124
@AgentM124 2 ай бұрын
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)
@dario3rnandez
@dario3rnandez 2 ай бұрын
Utilizo tus videos para aprender ingles y c++
@wickedprotagonist6600
@wickedprotagonist6600 2 ай бұрын
Which font style is this?
@jmlopezponce
@jmlopezponce 2 ай бұрын
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.
@ilieschamkar6767
@ilieschamkar6767 2 ай бұрын
I love conversion operator :)
@i_Have2BrainCells
@i_Have2BrainCells 2 ай бұрын
Will there be tutorial for modern c++ and all features of modern c++
@sorek__
@sorek__ 2 ай бұрын
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.
@KovidhVSBhati
@KovidhVSBhati 2 ай бұрын
please make a video on static_cast< >
@zami001001
@zami001001 2 ай бұрын
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.
@katanamajesty
@katanamajesty 2 ай бұрын
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 2 ай бұрын
After C++11 there are also the std::promise and std::future templates to do this kind of stuff.
@downbad.
@downbad. 2 ай бұрын
Please make a video on vptr and vtable
@xTriplexS
@xTriplexS 2 ай бұрын
We are so fucking back
@ohwow2074
@ohwow2074 2 ай бұрын
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.
@MeneerVerspiller
@MeneerVerspiller 2 ай бұрын
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.
@jks234
@jks234 2 ай бұрын
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 2 ай бұрын
Very true! I'm also one who started with Java, but I see things similarly.
@SilentFire08
@SilentFire08 2 ай бұрын
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 2 ай бұрын
​@@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 2 ай бұрын
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 2 ай бұрын
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.
@a_cats
@a_cats 2 ай бұрын
What visual studio theme do you use?
@digitalman9588
@digitalman9588 2 ай бұрын
Its the visual assist extension, I'm pretty sure its paid though.
@AbdullahGameDev
@AbdullahGameDev 2 ай бұрын
You can change the class color and variables colors and so on manually and make it your own theme.
@kanecassidy9126
@kanecassidy9126 2 ай бұрын
shouldn't you use conversion operators with "explicit" keyword to prevent unwanted conversions?
@nextlifeonearth
@nextlifeonearth 2 ай бұрын
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.
@herrdingenz6295
@herrdingenz6295 2 ай бұрын
3:50 again you forgot to link the video you're talking about "up there" :D
@rosiskharel389
@rosiskharel389 2 ай бұрын
at this point, i'll be disappointed if he actually links it.
@TheCherno
@TheCherno 2 ай бұрын
@@rosiskharel389 be disappointed
@lilgohan
@lilgohan 2 ай бұрын
this series needs to come back lol
@user-me8dk7ds7f
@user-me8dk7ds7f 2 ай бұрын
Finally!!!!!
@obinator9065
@obinator9065 2 ай бұрын
0:23 totally not me 👀
@a_cats
@a_cats 2 ай бұрын
it's happening i can't believe it
@kyantumzelda
@kyantumzelda 2 ай бұрын
WE ARE SO BACK RAHHHH
@TheAkatran
@TheAkatran 2 ай бұрын
I like your microphone! It's one of the theatrical types, right? It catches your voice no matter how far away you are!
@codinablack
@codinablack Ай бұрын
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?
@w3arthur
@w3arthur 2 ай бұрын
Got a job because of your courses, Thank you.
@TsvetanDimitrov1976
@TsvetanDimitrov1976 2 ай бұрын
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 2 ай бұрын
As a C/Rust programmer, I really don't like operator overloading, but it was a good video as always
@pxolqopt3597
@pxolqopt3597 2 ай бұрын
Operator overloading is fine imo as long as there is no ambiguity with whats happening
@hououinkyouma2426
@hououinkyouma2426 2 ай бұрын
I love your C++
@NyanCoder
@NyanCoder 2 ай бұрын
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 2 ай бұрын
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 2 ай бұрын
@@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)
@user-nb9sb3te8d
@user-nb9sb3te8d Ай бұрын
直接看最后一集对比之前的视频,声音变化真大
@kango4457
@kango4457 2 ай бұрын
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
@zdspider6778
@zdspider6778 2 ай бұрын
This series is down to 1 episode per Visual Studio release version, huh?
@fjxokt
@fjxokt 2 ай бұрын
That sounds cool, but it introduces a whole new world of potential bugs
@gracicot42
@gracicot42 2 ай бұрын
Wait until you delve in the insanity of templated conversion operators
@user-nj3lp5pp3l
@user-nj3lp5pp3l 2 ай бұрын
OR you just don't use implicit conversions unless you're forced to by some API. Guess which approach saves you more time.
@dj10schannel
@dj10schannel 2 ай бұрын
Cool
@puddleglum5610
@puddleglum5610 2 ай бұрын
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.
@paulzupan3732
@paulzupan3732 2 ай бұрын
Where's the type safety :(
@brockdaniel8845
@brockdaniel8845 2 ай бұрын
fking overloaaaad !
@dongiannisiliadis9018
@dongiannisiliadis9018 2 ай бұрын
Let's goooo
@tsvetan4431
@tsvetan4431 2 ай бұрын
LETSGO🎉
@mehdi-vl5nn
@mehdi-vl5nn 2 ай бұрын
ABI plz
@zdspider6778
@zdspider6778 2 ай бұрын
It's been a while.
@Sniperfuchs
@Sniperfuchs 2 ай бұрын
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.
Make C++ Apps & Games FOR THE WEB
15:30
The Cherno
Рет қаралды 44 М.
Global Variables in C++... not as easy as it seems
18:25
The Cherno
Рет қаралды 59 М.
Super gymnastics 😍🫣
00:15
Lexa_Merin
Рет қаралды 108 МЛН
Универ. 13 лет спустя - ВСЕ СЕРИИ ПОДРЯД
9:07:11
Комедии 2023
Рет қаралды 6 МЛН
Should I pass by const reference or by value?
10:45
The Cherno
Рет қаралды 99 М.
I HAD to fix this immediately // Code Review
31:47
The Cherno
Рет қаралды 29 М.
Wisdom From Linus | Prime Reacts
12:18
ThePrimeTime
Рет қаралды 412 М.
Stack vs Heap Memory in C++
19:31
The Cherno
Рет қаралды 554 М.
I Rewrote This Entire Main File // Code Review
16:08
The Cherno
Рет қаралды 131 М.
LEARNING C++ with Java/C#/Python Experience // Code Review
47:46
The Cherno
Рет қаралды 145 М.
Understanding B-Trees: The Data Structure Behind Modern Databases
12:39
BEST WAY to read and understand code
17:24
The Cherno
Рет қаралды 151 М.
SINGLETONS in C++
19:16
The Cherno
Рет қаралды 195 М.
Super gymnastics 😍🫣
00:15
Lexa_Merin
Рет қаралды 108 МЛН