<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 9:33 PM, Dmitri Gribenko <span dir="ltr"><<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Nov 13, 2013 at 6:21 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>

><br>
> On Wed, Nov 13, 2013 at 9:05 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Wed, Nov 13, 2013 at 6:01 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>
>> ><br>
>> > On Wed, Nov 13, 2013 at 8:25 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Wed, Nov 13, 2013 at 5:22 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>
>> >> ><br>
>> >> > On Wed, Nov 13, 2013 at 8:08 PM, Dmitri Gribenko<br>
>> >> > <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >> Or we could only return the first paragraph.  Faking a paragraph<br>
>> >> >> requires creating AST nodes, which requires memory allocation on the<br>
>> >> >> ASTContext, which is permanent.<br>
>> >> ><br>
>> >> > Why not create it on demand in "freeable" storage?<br>
>> >><br>
>> >> There is no API to free a CXComment node, because it is supposed to<br>
>> >> represent an real AST node, which is allocated on ASTContext.<br>
>> ><br>
>> ><br>
>> > Can't you allocate it on the CXTranslationUnit (or whatever the relevant<br>
>> > nearby "context" object is that is explicitly created/destroyed)?<br>
>><br>
>> There is no difference, because the lifetime of these contexts is the<br>
>> same.<br>
><br>
> Wait then what's the big deal with just allocating them permanently? It's<br>
> not like these comments are going to be gigabytes in size.<br>
<br>
</div>Not gigabytes, but possibly very large.  For example, on OS X, the<br>
text of fully preprocessed Cocoa.h with comments takes over 90 Mb.<br></blockquote><div><br></div><div>That's why I was suggesting to create them on-demand; that 90Mb will only be paid if they happen to call getParagraph on every single comment in those headers. Also I would suggest to not allocate them in the ASTContext, and just keep them in the CXTranslationUnit (or whatever the "context" object is) as strictly a "compatibility" thing.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Anyway, I see that a stable API promise from libclang is not to be<br>
taken lightly, so it might be the case that we will need to keep these<br>
APIs.</blockquote><div><br></div><div>Breaking APIs that are claimed to be stable and that users depend on is one of the worst sins in software engineering; far worse than for example breaking tests (insofar that those tests don't indicate that the stable API is broken... I think you get what I'm trying to say).</div>
<div>API stability plays roles in business decisions e.g. no budget or developer time is allocated to "fixing" breakage (since it's stable); if suddenly the API breaks, then developer time will need to be allocated to fixing it instead of working on "actual stuff that we planned and that is needed for the business". Often it will be a nontrivial amount of work to fix API breakage; even besides developer time. For example the planned deployment strategy may not admit bundling an XML library, and then suddenly fixing the problem might require coordination with non-technical management or marketing ("we had to switch to this other installer software which requires a 240x240 logo on a dark background instead of 180x180 on a light background"), etc.; not all breakage is as bad as I just described, but there are a lot of cases where breakage can cause *much* worse issues than I just described)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But this case clearly shows that exposing such low-level<br>
details is not sustainable, and leads to unfortunate workarounds.<br></blockquote><div><br></div><div>Indeed. It is a design decision like any other. Generally speaking any declaration that is added to a stable public header should be accompanied by a lot of careful thought about the ramifications.</div>
<div><br></div><div>In this regard, things like (schema-validated) XML are useful since they generally admit more flexibility in what can be changed without breaking existing code that processed it.</div><div><br></div><div>
-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Dmitri<br>
<br>
--<br>
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>>*/<br>
</div></div></blockquote></div><br></div></div>