Nice intro, Mike. This is just the tip of the iceberg. If your project is long-lived, it and it's data will evolve. You'll be dealing with serialization issues with each new version. How will you handle deleting a field? Where will you place new fields? That's just the beginning. At that point you'll likely look at designing something far more generic probably with a fair amount of meta-data to assist in handling prior versions. Ugh; if you have external clients, you'll have to maintain the entire version hierarchy because you can't rely on the clients being up to date with your software. There's a playlist for you. Good start, Mike. I do like it.
Hey mike, i am pranav and i just started leaning c and c++ with your videos n it's going very good thanks to you . there is suggestion of mine is that, Sorting the playlist by topics or sequence will enhance learning and ensure a smoother experience. Like : 1)Basics of c++ 2)Array & Pointer 3)OOP 4)STL Thanks for your time
I always get tripped up with these streams when it comes to implementing custom streams and what the CharT and Traits template arguments do for the std::basic_ streams. For instance, if I wanted to create a stream that worked strictly with uint8_t and didn't have to constantly cast it to uint8_t when using regular char streams.
wouldn't it be easier just to (de)serialize the entire struct at once by just reading and writing the size of the struct? processing individual fields might be necessary only if the field members are pointers that have allocated objects that need to be dealt with separately.
I see this as way over complicated. Why not just FILE *fp; fp = fopen(); fwrite(&go, sizeof(GameObject), fp); and be done with it. This way if I update or change my GameObject, I never need to go and find/update the serialization/deserialization logic.
Portability: fwrite isn't the same on every machine. Efficiency: you don't always want to serialize everything and you can compress specific data in different ways. Debugging: you can make parts human-readable to see if things are being serialized correctly in the binary file.
Please don't use platform dependent types like integer, long and short etc. These types can be different on different platforms / OS. You write in Windows and want read on Linux this can be sucks. C++ has inherited the the uncertainty of primitive types from C. You can't trust the size of these types.
![[Dlang Episode 104] D Language - [tools] Code coverage (with unittest and ctfe)](http://i.ytimg.com/vi/SFgnFOlKins/mqdefault.jpg)
![Beef Language - First Impression [Programming Languages Episode 33]](/img/n.gif)
Nice intro, Mike.
This is just the tip of the iceberg. If your project is long-lived, it and it's data will evolve. You'll be dealing with serialization issues with each new version. How will you handle deleting a field? Where will you place new fields? That's just the beginning.
At that point you'll likely look at designing something far more generic probably with a fair amount of meta-data to assist in handling prior versions. Ugh; if you have external clients, you'll have to maintain the entire version hierarchy because you can't rely on the clients being up to date with your software.
There's a playlist for you.
Good start, Mike. I do like it.
Overloading, specifically the ostream operators, was the first thing I learned about c++.
std::cout
Hey mike, i am pranav and i just started leaning c and c++ with your videos n it's going very good thanks to you .
there is suggestion of mine is that, Sorting the playlist by topics or sequence will enhance learning and ensure a smoother experience.
Like :
1)Basics of c++
2)Array & Pointer
3)OOP
4)STL
Thanks for your time
I always get tripped up with these streams when it comes to implementing custom streams and what the CharT and Traits template arguments do for the std::basic_ streams. For instance, if I wanted to create a stream that worked strictly with uint8_t and didn't have to constantly cast it to uint8_t when using regular char streams.
wouldn't it be easier just to (de)serialize the entire struct at once by just reading and writing the size of the struct? processing individual fields might be necessary only if the field members are pointers that have allocated objects that need to be dealt with separately.
🎉🎉🎉🎉
I see this as way over complicated. Why not just FILE *fp; fp = fopen(); fwrite(&go, sizeof(GameObject), fp); and be done with it. This way if I update or change my GameObject, I never need to go and find/update the serialization/deserialization logic.
Portability: fwrite isn't the same on every machine. Efficiency: you don't always want to serialize everything and you can compress specific data in different ways. Debugging: you can make parts human-readable to see if things are being serialized correctly in the binary file.
Please don't use platform dependent types like integer, long and short etc. These types can be different on different platforms / OS. You write in Windows and want read on Linux this can be sucks. C++ has inherited the the uncertainty of primitive types from C. You can't trust the size of these types.
u wot m8?