Hey esteemed colleagues,
We recently noticed that we were generating some incredibly large Objective C runtime encodings in some of our apps that are using Objective C++ and passing C++ types in Objective C methods, or have C++ types as instance variables. Templates are especially notorious for generating huge amounts of Objective C runtime information. I did a write up on it here:
but am looking for a better solution than my hacky “smart pointers”. As a first step I wanted to have a warning I could control to understand where my problem spots are.
I would appreciate any thoughts on
It is my first real foray into clang coding, so I expect my implementation is naïve.
This is a an idea, that may or may not be useful, depending on your circumstances.
What you could do is turn off the "bool EncodeBlockParameters, bool EncodeClassNames, bool EncodePointerToObjCTypedef" (especially the latter) flags passed to ASTContext::getObjCEncodingForTypeImpl, depending on a newly introduced compiler flag in `Options.td`. The resulting encodings are much smaller yet remain compatible. The amount of code out there that actually correctly introspects C++ type @encodes is probably extremely close to zero.
Usually the decision to use extended or traditional @encode is made at the runtime level. My runtime (https://github.com/mulle-objc/mulle-objc-runtime) uses extended format, but I don't support C++ anyway I could see a warning or compiler option like this as being useful, especially if the type is used in a lot of methods. But then this could also be part of the runtime...
I also can't help but comment, that mixing C++ and Objective-C gets you the worst of both worlds.
I’ll look into it once this hopefully gets checked in.