Easy C++ Reflection 

not my finest choice of words I have to admit 😂😂

​@@lowlevelgamedev9330XDD

sorry if I was not clear in the video, I would encourage people to use anything they see fit and I think that unions are a good option. For that case I used a pointer because well I need a refference. The thing that I dislike is the cpp union (I think it is called variadic or soemthing)

@@lowlevelgamedev9330 why do you hate so much std::variant en.cppreference.com/w/cpp/utility/variant ? It serves as an alternative to a platform specific functionality but cross platform and much more well designed en.wikipedia.org/wiki/Variant_type_(COM)

thank you bro 💪💪

thank you glad to hear feedback 💪

good question, so I didn't add it so that the user has to add it when using declare macro, this way declare macro looks more like an orinary cpp function where you havw to add ; at the end of the statement

std::variant is implemented using recursive inheritance of unions, the type layout is an absolute mess. a lot of it is exclusive to your STL implementation and not particularly ergonomic to use.

​@@marcs9451 But you don't need to deal with the type layout, it is kind of already made, no? And, talking about ergonomics, do you think there is a better alternative than them in this sense?

@@diadetediotedio6918 When it comes to (efficient) serialising you absolutely need to know the precise data layout, as you will be storing it in some binary format, you don't need to serialise std::variant as-is, but in the end you will end up writing your own variant in the form of serialisable data with a type tag + an "adapter" to std::variant. So basically you'll have duplicated work for little benefit. std::variant is just... very bad, when presented with the opportunity of having proper tagged unions (like Pascal, Rust, Odin, Zig, D, etc...) the C++ committee thought it was a bad idea and instead went with std::variant, which is just an ugly template hack. There's no better alternative in the realm of C++ here, this is a fundamental design flaw of the language that I can assure you, will *never* be fixed. What I do if I'm forced to use C++ is to just generate the boilerplate for a proper tagged union type with its own internal enum (I use a python script for that), so you can use `switch(value.kind())` and exhaustively check all data types (similar to Rust/OCaml enums). In the case of serialisation you can also use a protobuf style interface to handle reading a bunch of bytes from a file and decoding into a struct (reporting errors as needed).

@@marcs9451 Why does the implementation and layout matter unless you are doing non-standard stuff?

yes that is significantly more difficult to do, you probably have to use the things that I talked about at the end of the video.

nevermind, i see it gets called by std::vector

thanks 💪

thanks 💪

probably 😂😭

-fno-strict-aliasing

You can use memcpy.

hmm I don't think you can use templates to help you much in this situation but you can try to if you want

@@lowlevelgamedev9330 I tried, I managed to implement basic reflection using some weird templates and some of C++20 features, but it's just way too hard. I gave up :)

@@netfri25That's how advanced Template stuff always goes for me in C++ 😂

I havent used reflection with cpp so i don't quite know. You are probably right tho I still think that the things in this video are interesting to see

While C++ is definitely a more difficult language to get this up and running, you can definitely achieve it with code generation. Your best bet would be writing your own preprocessor using something like clangd, and inserting code before compilation. It would be difficult, for sure, but if you were able to develop a general-purpose tool for this it would be amazing. There's already some impressive tooling for C++, but due to the nature of C++ it's more difficult. I think, if Bison and Flex were able to do it 20 years ago (albeit in C and a lot less language-aware), certainly you can achieve it using clangd. Also, QT has already achieved this with the Meta Object Compiler.

oh yeah I am also waiting for that 😂 but they are taking too long + not everyone might be able to port to cpp26 + some libraries might not support those features (for example I wasn't able to make glm variables constexpr) and O honestly don't think macros are that bad if you know how to use them

@@lowlevelgamedev9330 The problem with macros is the pollution propagation of the pre-processor: it won't understand the different contexts and just replace whatever matches with the macro identifier. Hence, it's a dangerous practice, specially in libraries, because may the people using your library don't notice a macro identifier and confidently use that w/o noticing, opening up the doors for bugs, undefined-behaviour, etc... But i understand that when some feature lacks you gotta offer alternatives, i just don't think macros are the ideal alternative, some people went down to the Clang AST level and tried to deflect some info of its ASTNodes, either from the dumped AST or from the AST Emitter itself, by modifying the source code, i think thats a better approach to this problematic, because these also offer capabilities that can't be reached even with the use of macros.