Spent some more time on my property grid attempt. Finally got it working, had to give my reflection system some love. The nested types/arrays are pretty ugly but I have no ideas how to improve so I'm moving on...pic.twitter.com/Wc8fWc6EAy
Voit lisätä twiitteihisi sijainnin, esimerkiksi kaupungin tai tarkemman paikan, verkosta ja kolmannen osapuolen sovellusten kautta. Halutessasi voit poistaa twiittisi sijaintihistorian myöhemmin. Lue lisää
I suppose I am conflating reflection and serialization. I automate serialization through reflection, but in order to do that array types must also reflect certain members. Pushback, clear, data, size, reserve. Maybe one more I’m forgetting.
And I’m not using libclang, as you are. I have in the past and I found that because it introduces a pre-build step in order to get compile-time reflection, I’ve preferred just using constexpr and a few helper macros.
The libclang has benefits like being able to get exact enum values, even ones that include macros and expressions. It can also give me info on things like "abstractness", underlying types, etc... It is rather slow but it gives me what I need without crazy macro magic.
I actually have several types of serialization in the engine. Static binary/json serialization through manually serialization functions. And then dynamic using the reflection data to basically allow for partial serialization of objects.
Do you have separate functions for binary and json serialization?
hm. I never considered that approach. I basically only allow "dynamic arrays" through a single type. At runtime reflection is not really used for anything. In the tools, I use reflection to generate proxy types so I never touch the actual runtime data. I might be doing it wrong
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.