Oh, I missed this series last year :0. Went through it now and I love the Chili way of showing first the nonscalable way of solving the problem and then the better one. I definitely saw the build up for the better way coming up, but the actual solution was a big mistery until the last minute >
Happy new Year! Currently in the midst of your Intermediate C++ series (and having a great time), but already taking a look at what the future of the C++ journey holds. Thank you for the incredibly well-crafted tutorial series and hope you'll continue putting out new content! Though your health and family (and especially the newest addition ;)) should be the priority.
Reflection solved the main issue which was forgetting about a member of the struct. Cereal supports NVP and it would be trivial to extend to it using reflection. For the template metaprogramming hacks, hmm I think I'd have gone the way of checking whether all my types are serializable with some static assert on the variant, and still manually add support for each one (add one line of the macro) to fix when it fails to compile. And here it would simply use the cereal method to check if it's serializable. Less hacky IMHO, and don't forget you will still need to add cereal includes if you serialize other "native" types. But there's a magic to getting it all done automatically as you did! Happy new year and thanks for this awesome channel.
I like the namespace detection approach, but you can't deny that UB, however unlikely to actually blow up, leaves a bad taste in the mouth. Thanks for watching and happy new year to you as well!
Did you try using std::is_aggregate_v instead of std::is_class_v? Then there'd be much fewer types to exclude (if any). Also, maybe you could avoid the UB of injecting a function into std by checking for "move" or some other function that's already guaranteed to be in std (and hopefully nowhere else, since I can't think of a situation where you'd name your own single-argument function "move").
is_aggregate is interesting. Would still need fixing up for stuff like std::pair. Using a pre-existing std function for the ADL is too risky though. E.g. for your example of "move", consider boost::move. Actually thinking about it, you could inject a template specialization (which is not UB) for something like std::hash, and use that for your ADL if you wanted to be 100% correct.
Hey happy christmas and new year. I have some doubts. Iam very very new to your channel. Where should i start learning from your channel. I mean like which playlist should i start. Iam a beginner.
![C++ std::variant Multi-Command Polymorphism [Reflective Serialization]](http://i.ytimg.com/vi/FbjOniQmG3g/mqdefault.jpg)
![C++ std::variant Multi-Command Polymorphism [Reflective Serialization]](/img/tr.png)
![C++ Custom std::streambuf for Packet Optimization [Reflective Serialization]](http://i.ytimg.com/vi/Af_ORIQLWMA/mqdefault.jpg)
![C++ Has Reflection Now??? [Reflective Serialization]](http://i.ytimg.com/vi/FhK1A_rPQYE/mqdefault.jpg)
Oh, I missed this series last year :0. Went through it now and I love the Chili way of showing first the nonscalable way of solving the problem and then the better one. I definitely saw the build up for the better way coming up, but the actual solution was a big mistery until the last minute >
Happy new Year!
Currently in the midst of your Intermediate C++ series (and having a great time), but already taking a look at what the future of the C++ journey holds.
Thank you for the incredibly well-crafted tutorial series and hope you'll continue putting out new content!
Though your health and family (and especially the newest addition ;)) should be the priority.
@@solipsist644 thanks for the kind words! There will always be new content :)
Reflection solved the main issue which was forgetting about a member of the struct. Cereal supports NVP and it would be trivial to extend to it using reflection.
For the template metaprogramming hacks, hmm I think I'd have gone the way of checking whether all my types are serializable with some static assert on the variant, and still manually add support for each one (add one line of the macro) to fix when it fails to compile. And here it would simply use the cereal method to check if it's serializable. Less hacky IMHO, and don't forget you will still need to add cereal includes if you serialize other "native" types.
But there's a magic to getting it all done automatically as you did!
Happy new year and thanks for this awesome channel.
I like the namespace detection approach, but you can't deny that UB, however unlikely to actually blow up, leaves a bad taste in the mouth.
Thanks for watching and happy new year to you as well!
Another christmas miracle!
Hallelujah 🎄
And that is why I say that "C++ Templates" (the book) is the black magic book. Maybe it should be named "Templates of the Dark Arts"
One day imma finish reading that one.
Wishing you a great 2025!
Right back at you!
Did you try using std::is_aggregate_v instead of std::is_class_v? Then there'd be much fewer types to exclude (if any). Also, maybe you could avoid the UB of injecting a function into std by checking for "move" or some other function that's already guaranteed to be in std (and hopefully nowhere else, since I can't think of a situation where you'd name your own single-argument function "move").
is_aggregate is interesting. Would still need fixing up for stuff like std::pair. Using a pre-existing std function for the ADL is too risky though. E.g. for your example of "move", consider boost::move.
Actually thinking about it, you could inject a template specialization (which is not UB) for something like std::hash, and use that for your ADL if you wanted to be 100% correct.
Hey happy christmas and new year.
I have some doubts. Iam very very new to your channel.
Where should i start learning from your channel. I mean like which playlist should i start. Iam a beginner.
@@aswinaswin5672 beginner c++ playlist. Check wiki.planetchili.net
@@ChiliTomatoNoodle Thanks