Move Semantics in C++ 

Do you have your own personal library of functions, classes, namespaces, etc? My professor told me that it's important for programmers to have their own tools which make their own methods easier.

ok

Excuse me, I know this is out of the point, but, do you know a way to turn off auto save in Visual Studio Community 2019?

Thanks for starting with Move Semantics.. looking forward for more about this..👍

Can you make a video about the rule of 3 and the rule of 5 and how to implement them properly?

Thanks, I was getting two "Destroyed" and was like what the heck ;). Then I debugged it and the first one is destroying object with size of 0 and data as null, so I actually deduced this somehow myself too...

Thanks! I was wondering exactly that. Saved me some googling

yeah I was wondering! saved me some time!

Bless your soul...

it helps! should read the comment first before figuring it out myself🤣

what's the talk you saw? :)

@@IndyR0ck Probably this one: Back to Basics: Move Semantics (part 1 of 2) - Klaus Iglberger - CppCon 2019

@@torstein5 thx!

This didn't aged well...

​@@godnyx117 Oh yeah I expected this series to cover more advanced topics but had to do my own research on the topic instead. Still a very great series and the best C++ series there is on RU-vid!

Pointing fingers at sir John Carmack? Sounds like the DOS days to me! I'm sorry I'm asking this _TWO_ years later, but in your opinion, how fast is C++ at evolving? It is often called an ever-evolving language, and especially with us getting a new standard every third year, I, a beginner, feels the same way. Thoughts? I invite other veterans to answer, too!

It should also be m_Size + 1 when allocating for the null terminator

@@gideonunger7284 Not necessarily. You don't need to store a null terminator if you know your string's size. Though it can be useful with C style string functions. But he should've used delete[] or maybe even allocated with a unique_ptr instead.

That is good advice in general, however in this case is not necessary because the destructor of char is a no-operation. In this specific scenario is not necessary to call the destructor of every object in the array by calling delete[].

@@Spirrwell yes sure if you don't work with any c string functions or pass that pointer to the outside it's fine. But it's still dangerous in c++ since the assumption of a char* is that it's null terminated. Rust doesn't use null termination but there it's the standard of the language so it's not a problem anywhere

@@gideonunger7284 It's already dangerous to assume the const char* passed to strlen() will be null terminated. In C++ a compiler might add a null character to such values in double quotes but a C compiler won't do that implicitly which makes sense because you will know the length of a constant array of chars in your code already as developer.

Unless you're using namespace std, it doesn't really matter.

@Artem Katerynych #include using namespace std; string string(string string) { string string = string; } int main() { string string = “string”; string(string); }

@@ianpan0102 Using namespace std is a cardinal sin anyway

@@unsafecast3636 Bruh Bruh(Bruh);

@@unsafecast3636 god

He should've tested it on PVS-Studio to see if it can detect the memory leak.

what is the difference ?

@@abdallahrashed1947 "delete" destroys a dynamically allocated object and "delete[]" destroys a dynamically allocated array

@@TernaryM01 underrated comment lol

Technically its UB with char* string literals

what really?

According to the standard, using delete instead of delete[] is UB. In practice, both delete and delete[] are simply forwarded to the libc function "free", and therefore end up behaving the same. Of course I an NOT advocating using delete instead od delete[], that would be terrible practice. But there isn't an implementation out there that only frees the first element. In fact there isn't a function you could use to only free the first element. Even realloc won't do that.

With `delete` instead of `delete[]`, the whole array gets freed, no problem so far, but only one destructor might be called: that of the first element. This doesn't matter in the case of a `char` array, but it can be relevant for more complex objects, which in turn might allocate their own memory (which would then have to be freed again).

@@Flinsch77 that is correct. Thanks for that

Memory ordering is a very tricky subject.

Yes, the program needs to clean the continuous block of memory allocated to m_Data.

John True Statement,this popped up and I was like where PS5 part 2 video everyone is waiting for😁

How do you know its being released on Saturday?

@M. de k., could be the Discord?

@@redscorpion9325 go to his channel and look at his community post. He said it's coming on Saturday:)

Casting to xvalue

tomorrow

How do you know🤷🏽‍♂️seems like rumors to me

Move semantics in c++ are a terrible mess though. Compared to move semantics in rust it's so overengeneered, complicated and also worse to use.

@@gideonunger7284 tbh if you compare c++ to most of the languages, it's a mess, i'm an avid c# user besides c++ and i know what you mean.

Move semantics is really not much more than fancy syntax sugar for pointer management behind the scenes IMO. Ownership of heap-allocated data is perhaps the most crucial issue to retain a clear overview over in order to stear clear of producing an app full of memory leaks (or the opposite: double-freeing). In languages with automatic built-in memory mgmt this challenge is attempted solved with a different philosophy than in C++ with its direct mem.mgmt, and that may well justify hiding those details from the programmer there. But with direct mem.mgmt hiding such details just appears to falsely relieve the programmer from that concern which they really ought not, and should not, forget about, ever! Thus, an unaware coder is easily mislead into not caring so much about it as they probably should; there is a loss of awareness. One got more direct control of mem.mgmt with a potential for better performance and flexibility, but with that potential also comes risks and responsibilities. In light of this I personally think we would be better off without the feature, as the smart pointers actually provide the same solution except you can better see what is actually going on. Move semantics actually cannot completely avoid copying in all cases anyway (consider objects on the stack as well as the underlying ptr to heap memory, for example), and it also introduces a nasty side-effect in that it may leave the source object in a limbo state while it is still technically accessible and within scope of the code. While such use is declared illegal/undefined, it is something that becomes all too easy to do by mistake. I guess I have just seen too many bugs arising from using uninitialized vars/objs over the years too feel comfortable in presence of any new feature with similar risks... It is not always that easy to know in an instance whether a move ctor or assignment was invoked instead of the corresponding copy ctor/asgmt ;-)