Handling of anonymous structs

[dmikushin]

Hi @mlomb ,

In Linux the following error occurs in metacpp_cli:

Generated.cpp:10518:48: error: expected id-expression before ‘(’ token
10518 |                         type->SetSize(sizeof(::(unnamed union at /usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h::6::)));

This is due to the fact that this field is anonymous:

/* Conversion state information.  */
typedef struct
{
  int __count;
  union
  {
    __WINT_TYPE__ __wch;
    char __wchb[4];
  } __value;		/* Value so far.  */
} __mbstate_t;

I've investigated ASTScrapper.cpp, and it turns out the handling of anonymous records is not implemented.

I don't know yet how to implement it, so the best what I can do is to disable them:

--- a/ASTScraper.cpp
+++ b/ASTScraper.cpp
@@ -198,6 +198,9 @@ namespace metacpp {
                                                return 0; // forward declaration
                                        }
                                }
+                               if (!cxxRecordDecl->getDeclName()) {
+                                       return 0; // TODO is anonymous
+                               }
                                templateArgs = ResolveCXXRecordTemplate(cxxRecordDecl, qualifiedName);
 
                                if (qualifiedName.GetName().size() == 0) {

With this change the MetaCPP example compiles successfully.

Could you advise me how the anonymous fields should be handled in a good way? I can only image some decltype taken from the explicit type spec. On the other hand, I think two identical types are not yet equal, so perhaps this idea won't work anyway.

[dmikushin]

I think the strategic flaw of the current MetaCPP design is in the attempt to create every piece of reflection data, which is possible to create. With all your efforts put into it, it still might not work due to the compiler internal oddities. I mean to say, at a certain depth of internal logic the compiler may choose to hack the type system in a non-standard way. It's not blessed, but is likely to happen for the sake of taking reasonable shortcuts. So the MetaCPP's attempt to dig as deep as possible is doomed to fail.

I believe there is one very easy fix. MetaCPP should stop trying to create every viable type and instead create only the requested types in a lazy manner. In this case, it should never fail. If it fails, it means the user code compilation should already fail beforehand.

[mlomb]

Hey thanks for taking the time to look at MetaCPP.
You are right, MetaCPP should work in a lazy manner. There are many flaws with the approach of this library, and it is very annoying to work with. Only a small subset of features were implemented, which does not include anonymous structs.

---

This project was more of a proof of concept than a serious approach to serialization, so I'll keep it at that.

[dmikushin]

Hi @mlomb , your project is very useful, thank you for publishing it!

I've seen you are a passionate developer also, so I'm curious: do you wish and have time to contribute into a next-gen MetaCPP? The tool like MetaCPP could be extremely useful for many purposes. It just needs to be developed a little further.

[mlomb]

I did MetaCPP when I was experimenting on serializing objects for my personal graphics engine. Nowadays I mostly use Rust, so I have no motivation or real use case to build something like MetaCPP.
Also, IIRC upcoming standards (2026+) of C++ include static reflection, so it may be futile.

[dmikushin]

Yes, reflect-cpp uses C++20 static reflection. But my practical tests showed it's still quite slow to compile, as the whole typesystem still must be implemented with templates. Clearly, an LLVM-based solution could be more robust by managing serialization with #pragma statements alone. I've started rewriting your MetaCPP code here: https://github.com/dmikushin/tapetum

What about Rust, I think it is also based on LLVM? Just imagine that C++ and Rust could interoperate through a single type serialization engine!