<div dir="ltr">Thanks Nat!<div><br></div><div>I'll look into it once this hopefully gets checked in.</div><div><br></div><div>Cheers,</div><div>Dave</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 12:44 PM Nat! via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 11.12.18 05:06, Dave MacLachlan via cfe-dev wrote:<br>
> Hey esteemed colleagues,<br>
><br>
> We recently noticed that we were generating some incredibly large <br>
> Objective C runtime encodings in some of our apps that are using <br>
> Objective C++ and passing C++ types in Objective C methods, or have <br>
> C++ types as instance variables. Templates are especially notorious <br>
> for generating huge amounts of Objective C runtime information. I did <br>
> a write up on it here:<br>
><br>
> <a href="https://medium.com/@dmaclach/objective-c-encoding-and-you-866624cc02de" rel="noreferrer" target="_blank">https://medium.com/@dmaclach/objective-c-encoding-and-you-866624cc02de</a><br>
><br>
> but am looking for a better solution than my hacky "smart pointers". <br>
> As a first step I wanted to have a warning I could control to <br>
> understand where my problem spots are.<br>
><br>
> I would appreciate any thoughts on<br>
><br>
> <a href="https://reviews.llvm.org/D55544" rel="noreferrer" target="_blank">https://reviews.llvm.org/D55544</a><br>
><br>
> It is my first real foray into clang coding, so I expect my <br>
> implementation is naïve.<br>
><br>
> Tracking bug:<br>
><br>
> <a href="https://bugs.llvm.org/show_bug.cgi?id=38346" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=38346</a><br>
><br>
> Cheers,<br>
> Dave<br>
><br>
<br>
Hi<br>
<br>
This is a an idea, that may or may not be useful, depending on your <br>
circumstances.<br>
<br>
What you could do is turn off the "bool EncodeBlockParameters, bool <br>
EncodeClassNames, bool EncodePointerToObjCTypedef" (especially the <br>
latter) flags passed to ASTContext::getObjCEncodingForTypeImpl, <br>
depending on a newly introduced compiler flag in `Options.td`. The <br>
resulting encodings are much smaller yet remain compatible. The amount <br>
of code out there that actually correctly introspects C++ type @encodes <br>
is probably extremely close to zero.<br>
<br>
Usually the decision to use extended or traditional @encode is made at <br>
the runtime level. My runtime <br>
(<a href="https://github.com/mulle-objc/mulle-objc-runtime" rel="noreferrer" target="_blank">https://github.com/mulle-objc/mulle-objc-runtime</a>) uses extended format, <br>
but I don't support C++ anyway :) I could see a warning or compiler <br>
option like this as being useful, especially if the type is used in a <br>
lot of methods. But then this could also be part of the runtime...<br>
<br>
I also can't help but comment, that mixing C++ and Objective-C gets you <br>
the worst of both worlds. :)<br>
<br>
Ciao<br>
<br>
    Nat!<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>