<div dir="ltr">Hi John,<div><br></div><div>Thank you for your reply.<br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/2/27 John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Feb 24, 2013, at 12:38 AM, Dai MIKURUBE <<a href="mailto:dmikurube@acm.org">dmikurube@acm.org</a>> wrote:<br>


> Hi Douglas and John,<br>
><br>
> I started to try your approach, but I'm still not sure what it does, and still a little doubtful that it's easy to catch allocation by non-global (in-class) operator news.  When a project has 100 in-class operator news, doesn't it need to prepare 101 replacement functions?  If it needs, I think it's so unrealistic.  We cannot track all changes in a big project (e.g. WebKit).  If a developer adds a new class with its local operator new, it's impossible to track all such local operator news.<br>


><br>
> Could you tell me make sure 1) what should happen in the compiler and 2) what replacement functions should be added, in the simple example below?<br>
><br>
> (Also, I'd like to know where is the DWARF code in Clang you mentioned.)<br>
<br>
</div>Okay, here's the deal.<br>
<br>
I don't think we're really interested in taking your original language extension into mainline clang.  It's invasive, it's complicated, it's novel, and it doesn't seem to have broad applicability.<br>


<br></blockquote><div><div>Yes and yes, your point on my original extension is right at all.  I also think it's complicated.  (So, I asked about it at cfe-dev@ weeks ago, before I started implementing for upstream since I was worried about its complicacy.)</div>

<div><br></div><div>I don't want to stick on my original proposal, and I don't want to contradict your suggestion.  I *just* wanted hints to understand Douglas's suggestion (maybe just simple answers to my questions) since I didn't well-understand how his suggestion should be implemented and how the implementation should work.  If it's not enough for our purpose, I'll think out another idea.  Or, any other suggestions are also welcome.</div>

</div><div><br></div><div style>What do you think, Douglas?</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


Doug and I were suggesting adding infrastructure to LLVM under which arbitrary calls could be annotated with metadata which would potentially survive into DWARF.  This would be a broadly-applicable feature that could be used by potentially many projects.  This would be a lot of work on your part, but as a carrot, we would be open to an extension which merely annotates an operator new call using this new LLVM feature.  It may not, however, actually achieve your purposes that well;  I don't know them well enough to speculate.<br>


<br>
Ultimately, however, this is an open-source project, and you are welcome to maintain your patch out-of-tree.<br>
<span class=""><font color="#888888"><br>
John.<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Dai MIKURUBE<br>   <a href="mailto:dmikurube@acm.org" target="_blank">dmikurube@acm.org</a><br>
</div></div></div>