thank you jacob for your great content! as others mentioned, if you assign person2 = person1 and one of the struct members is a pointer you will get at this field another pointer to the same memory. very important at the end of the video.

I typically just assign a struct var with another. Compiler will either map out each assignment or compile it as a `memcpy` call. If the struct has pointers, then gotta do a special deep copying function.

Hey Dr. Sorber just discovered your channel and been binging the vids, currently a freshman and our language of choice is C. Your DSA videos have been super helpful! Hopefully you would upload more embedded content as that's what I'm also doing in my free time right now using STM32 microcontrollers. Keep doing what you do!

NO! This is the sort of example that gave operator overloading in C++ a bad reputation when it was introduced. Please do not ever write an operator= that does anything other than copy every struct/class member. Maintainers of your code will hunt you down and hurt you. Okay, I'm sure someone can find an exception to this. Perhaps there's a field that holds some cached information that is better off being recalculated than copied, or perhaps for debugging purposes you keep some sort of unique ID that really does need to be unique. But the rule is that after assignment a = b, then a == b should always be true, so you'll also need to make sure your overloaded operator== does not consider the un- or mis-copied field as part of the meaning of equals for that type. In fact, don't overload operator= unless you need to, and the only time you need to is when your class/struct has some resource (like a pointer, file ID, network socket, etc.) that either cannot be copied, or which requires special care when being copied. And if that's the case, you will want to implement your own copy ctor and dtor (and perhaps the move operations also). Having control over these operations is one of the things that makes C++ unique; in particular it allows automatic resource cleanup (RAII) in ways that few other languages can match. But that control can be misused. And with all due respect (and that's not an empty cliché; I recommend a lot of your excellent videos to my students), this is an example of one of those misuses.

Thank a lot, I am looking for how to do this specifically and I finally found it very well explained

I have been programing in C for 20 years and I still learn new things from your video's. I especially liked the EFAULT thing with a pipe. I may never use it but it's good to know. Please don't worry about your video's being to long, I'd watch an hour long video if you made one that did a really deep dive on some topic. But mostly i love c programing and I find your video's very interesting even if i already know the subject your discussing. I've written application's, kernel modules and even chipset drivers. Keep producing these videos!

Be very careful when using strncpy. If the source string length is >= size of dest buffer, the buffer will not be NUL terminated.

I was waiting the whole time for you you to talk about shallow/deep copies. This is one of the reasons to overload the assignment operator, to give it deep copy behaviour.

You rarely want to copy the pointers around cause if one object is destructed then the other object pointing to one of the members of the first object will malfunction. Essentially copying with memcpy is safe only for POD structs and not for non-POD.

In automotive SW we need to markup all variables, constants, pointers, structs... For example, person1 and person2 in ASW would be person1_s and person2_s or sPerson1 and sPerson2, respectively and sPerson1_t and sPerson2_t for definitions. That's the easiest way to see with what you are dealing with, even IDE can highlight the elements. CamelCase and underscore are equally allowed.

Something that hasn't been commented on is the issue of a potential UMR (uninitialized memory read) with a memcpy in this case. With the example struct, an int (4 bytes) is followed by a char30 (30 bytes) which is followed by a double, which on some/most systems will be double-word aligned, meaning that 2 additional padding bytes will appear before the double so that the offset to the double is 36, a multiple of 8. These padding bytes are technically uninitialized by element-wise assignment. When a memcpy occurs, a strict runtime code checker will detect these bytes of automatic storage have not been initialized and will flag the UMR. To avoid the UMR, the memory containing the struct should be initialized to 0, such as by memset(&person1,sizeof(person1),0); If the struct is coming from dynamically allocated memory, this is still necessary unless the memory is being explicitly zeroed when allocated. Another way to avoid the UMR, if it is acceptable, is to rearrange the structure elements so that no padding bytes are needed, by placing the doubles first, then the longs, then the ints, and then the chars. I know this is a bit esoteric, but in my pre-retirement development work, a UMR - whether a benign one such as this or a "real" one - always needed to be avoided.

memcpy(&str2, &str1, sizeof(struct_type)); - please don't throw tomatoes at me -

Hey Jacob, great video as always! It would be interesting to see more complex cases, let's say instead of the char array, you've got a char pointer that you allocated dynamically. I guess you're kind of stuck with explicit copying of these pointer variable members? (or C++ overloading, which is the same as writing a C function)

Very good to know the various approaches, what would be the best way to swap two struct?

It's possible direct struct copying didn't work in K&R C and manual copying is just a throwback from that. I tried it explicitly using the C89 standard and it seems to work (assuming the compiler it handling it correctly).

Custom data types such as uint8_t wont work correctly Because of padding but byte aligning can help

One thing to note is that when doing assignments on structs that has compiler paddings, the compiler is not required to copy the values of these padded bytes per C99. This could be a problem if the struct is used for checksum calculation purposes which, depending on how it's calculated, could cause an issue. This issue can be resolved by the user by explicitly pad the struct or simply ensure the struct will not result in padded bytes by the compiler.

Could you explain why you can return a *this for the reference return type in the c++ example ? Many thanks !

at 8:50 you mention that it's probably better to work with memcpy in that case, but I disagree, because it has the same issue If person1 and person2 are pointers, this will still work &person1 takes the address of the variable that's holding the pointer, dito for person2, and sizeof(person1) will just be the size of a pointer, so everything still works but we did the exact same thing as say `person2 = person1;` - just more verbosely and harder to debug in that case too

12:29 I know relying on tooling is not the best option. But most intelligent editors will highlight overloaded operators. In case of visual studio (code) the operator is written in yellow and if you hover it will tell you the overload signature like a function. You can even press ctrl + left click to jump to the definition. So I feel like clarity is a question of tooling in this case.

personally the reason I'd guess that "person 2 = person 1" doesn't work is because it wouldn't work like that in Python, and I assume C is gonna be harder rather than easier. haha. I kind of like the memcopy option more because I was confident it would work immediately without much experience, so it must be good for communication, at least considering C newbies like me :p

are you making an embedded systems course anytime soon?

I had to lookup strncpy() since your C example didn't take into account the terminating NULL from the source name. According to Tutorials Point, "In a case where the length of src is less than that of n, the remainder of dest will be padded with null bytes". Curious that this apparently doesn't happen in C++. One issue you didn't address is what to do if a struct contains pointers. Do we copy the pointer or do we duplicate the memory the pointer points to? (I know, the answer is "it depends"). I think that if I were to do frequent copying of structures I would create a separate function like personCopy() which would be clearer than using = or an overloaded = (especially if personCopy() is documented).

Put me in the camp of people who learned c++ 30 years ago, went through an operator overloading phase and got over it. I simply don't do it anymore. C++ is already too clever to have glyphs with common meanings do exciting things. You want to do something clever, then it deserves a name. That said, one reason to maybe implement your own copy rather than simple assignment or memcpy is performance. Let's say that your name string member is a megabyte long but the typical name is 5 bytes. Assignment and memcpy will copy the whole struct, whereas if you write your own routine, you can use strncpy and save yourself some runtime in the common case.

Well, approach 1 is begging to be turned into a mystruct_copy(a, b) function.

What I don't like with person2 = person1, it's a day someone change char name[30] by char *name with dynamic allocation, everything will be broken down. Maybe the best way it's to make a function?

You should always copy structs through assignment, since if `memcpy()` is the best way to copy the struct, the compiler will just do that anyway, but unlike using `memcpy()` directly, you are not forcing it to use `memcpy()`, as in some cases there is a better way to do it and then the compiler has the freedom to use this better way. If in doubt, always leave choices to the compiler as compilers today make better choices than programmers do. That's because most programmers make assumptions about what is fast and what not and quite often those assumptions are wrong, as they never really tested their assumption across a variety of platforms in the first place. In 9 out of 10 cases, a C compiler will generate faster code than a programmer writing whatever he thinks is fastest directly in assembly. And in the one case, were the compiler won't win, the differences to hand written code is usually neglectable, so not even in that case it really paid off.

Inrmemeber use different techinques to copy data from one class to another in c++ one of them is to use = operator though you need to use operator overload =

Correct me if I'm wrong. I learnt C many many moons ago and I dont think you were allowed to copy structs using the '=' operator back then. If you could then none of my cohorts knew this either.

@1:52 - It's hinting that strncpy() takes va_args. What kind of broken IDE is that? Even if it's the result of some underlying macro mapping mess, it should give the proper signature of what it maps to.

Question: why do strlen("NONAME") + 1 instead of sizeof("NONAME")?

Only problem with memcpy/memset is if you arent running on arm cortex m7 or on windows (havent tried on linux) you will run into packing issues when casting data / putting it into a buffer where sometimes it can even crash if you try writting to an odd memory address. NOTE: Coretex M7 chips pack by default (i think), and windows handles this is the background. Don't know how linux handles it, and some embedded system compilers support packing through a #pragma call.

0:55, 1st thing I notice, that height variable should come before the other members because it's a double, had the compiler spit out a number of alignment/endian warnings to me at one time after I updated it, they only went away after I moved the doubles to the top of the struct. **Edit:** might've been a union instead, been a long time since I had those errors after all

Can you pass non type defined memory as arguments to functions. Like if i have a swap function and i want it to be able to work with any datatype. Is there something you can do with memcopy or void pointers or with anything else in the c language

i think it would have been nice, when the print function would also give out the addresses of the struct members, so that you can be sure it's not just the same struct. Also I'm a C person and not a C++ person, so maybe that's why I don't like the overloaded assignment operator at the end but my thoughts are: If you create an extra function to copy your structs/classes/objects, call it what ever, you might as well just call it STRUCTNAME_copy(). I assume that you have the function call overhead anyway, so might as well make it explicit. I mean what is easier to understand: myObject A = ...; myObject B; B = A; or B = A.copy(); I think the second one is much clearer in what it does, especially when you are dealing with heap objects. Does B = A just do pointer stuff and doesn't copy actual data ? B = A.copy() is obvious in my opinion, especially when you write some documenting comments to the function.

it's funny, I saw so many lectures about c++ constructors (rule of three, rule of five, rule of six, rule of zero), but hardly anything about the assignment operator. I guess it's just not popular to use it? because we can have scoped variables? because of std::optional?

people assume it doesn't work with structs because arrays' ids are treated as pointers, and struct might be too.

If you have to add the whole string library only for memcpy() then maybe it's not the best solution.

strncpy() is not the correct way to prevent buffer overrun, because it doesn't append a terminating zero in the worst case. You would have to write strncpy(dst, src, sizeof(dst)-1); dst[sizeof(dst)-1] = 0; to be sure. Use C99's strcpy_s() instead: strcpy_s(dst, sizeof(dst), src);

hey jacob, newbie question but is it bad to use compiler specific additions to C (ex. nested functions in gcc)

0:36 me right after beginning with the program compilation

Wait why doesn't the assignment operator work with arrays? Does trying to do that result in an error? If not, what is the result? Also, are "person1.name" and "person2.name" pointers (since memcpy needs pointers)? Even though the structs themselves weren't declared as pointers?

Re C++; the will look at the class defn and see any overloaded operators..

0th!

person2 = person1; Wouldn't this leave out the actual copying of the string? Changes made to person1's name would reflect in person2, and vice-versa

What is the difference between #include and #include "filename"?

Hi Jacob - I like your videos and they all have great content. This one is misleading as you are taking very simple example to show it works. Typically, it the structure contains pointer to another structure or array.

This might be a dumb question but can Jacob or someone in the comments explain why `memcpy` was fine with person2.name and person1.name, but needed the address of person2 and person1? Oh wait a string is basically a char* so essentially an address. Wow that was a rubberduck debugging moment.

English: (using C, not C++) Very good video! But, I have a question: how can I copy using "memcpy", if, instead of having "char name[30]", I have "char * name" and dynamically allocate its space at runtime? Thank you!! Español: (usando C, no C++) ¡Muy bueno el video! Pero, tengo una pregunta: ¿cómo puedo copiar usando "memcpy", si, en vez de tener "char name[30]", tengo "char * name" y su espacio lo asingo dinámicamente en tiempo de ejecución? Gracias!!

Serious question: When shifting from C to C++, you've added a function to the struct that clones an original. I wonder why you chose to not change the struct to a class and use C++'s facilities of constructors and "copy constructors"... person_c p1( "Clair", 45, 5.2 ); person_c p2( p1 ); strncpy( p2.name, "Marie", sizeof( p2.name )-1 ); // EDIT: moved -1 outside of ')''... Doh!! or even person_c p2( p1, "Marie" ); that would create Claire's twin sister... Then it's on to "p1.Print(); p2.Print()" to, again, take advantage of data hiding and code reuse.

I have a problem with compilers - I don't trust them. So I tend to program quite defensively. On the upside, that approach allows 10 KLOC programs to compile (almost) warning free over a wide range of C compilers - starting with K&R.

0:27 Jacob be like: Only a sith deals in absolutes... I will do what I must.

Beware the evil cloned string pointer, by copying the structs!

On overloading "=" with a non-obvious copy facility: As the saying goes, "With great power comes great responsibility." This is why C++ needs the '±' operator... It's very like assignment ('=') but shows that the destination will be "more-or-less" like the source... 🤣

Thank you, Jacob, for this interesting episode. But I cannot understand why all these examples use a person's age instead of the person's year of birth. You might get in trouble if you have filled a database with the persons' ages over several years...

I notice that you use Person& person instead of Person &person. The & is a modifier, it modifies the variable not the type. The same counts for Person* person vs Person *person. If you write Person *personA, personB; it is clear that personA is an pointer and personB is a struct. However if you write Person* personA, personB; most programmers will assume both personA and personB are pointers. Yes I tested it in an exam and most students give a wrong answer. Of course it is better to avoid ambiguity and write two lines of code.

I usually solve the pointer issue by keeping a copy of the original struct to the side prior to overwriting the destination struct: typedef struct _SUM { int a, b; int (*op)( struct _SUM *sum ); } SUM; int foo( SUM *dst, const SUM *src ) { SUM tmp = *dst; *dst = *src; dst->op = tmp.op; return dst->op( &two ); }

you struggling with the pointer really breaks my vi heart, you should try the vim extension for your editor. you wil still be able to navigate it as you used to but you'll gain all the superpowers of vim and hopefully eventually completely switch

Pls don't throw away const correctness... T& operator=(T const &other);

Sirr, Comments are a thing in C, pretty useful when you want to make your intent clear rather than having someone read everything

all three examples are painfully wrong and demonstrate the problems with C and C++. Lets say your struct has handles to objects or pointers to btrees. step in STL/templates and reference counting. which already is beyond most amateur developers. I love C and C++. I write kernel drivers, so C/C++ is pretty much a given. second overloading is a nightmare, although it does demonstrate a good point. lets say you had a 1MB bitmap, hashtable, string ect... it is ridiculous to copy the whole thing if only 2 bytes are valid. C++ has a lot of member functions to deal with this kind of thing, and paired with templates/generics/patterns they can be solved. again, with added complexity, but if you are writing potenially shared code/ libraries the extra effort is always worth it. example: for the windows IO model you have a complex structure called an IRP. copying that would immediately blue screen the system as you have threading issues, memory issues, locking issues... the list goes on. so my super simple solution is just write a copy function for your struct (C). there are exemptions of course. if your struct represents a 3d transform matrix then memcpy or naked assignment is fine. aka if all the data in your struct is always vital to the identity of the structure and contained.