Hi David,<br><br>Thanks for make this clearer. I'm doing some changes in<br>controlflowgraph to disable the automatic generation of fully deep<br>graphs. Maybe keep the automatic generation only for two or three<br>level graphs without the incoming arcs and provide a button for<br>

request such expansion.<br><br>Thanks,<br clear="all">Sandro
<br><br><div class="gmail_quote">On Sat, Apr 17, 2010 at 10:49 AM, David Nolden <span dir="ltr"><<a href="mailto:zwabel@googlemail.com">zwabel@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

First an overview of the different declaration pointers:<br>
Declaration*   :   A simple pointer, only guaranteed to be valid<br>
within one duchain lock cycle. After you unlocked the duchain, you<br>
must not use a stored pointer any more, as it may have been deleted or<br>
unloaded, leading to a crash.<br>
<br>
DeclarationPointer    : A weak pointer to a declaration, which notices<br>
when the declaration was deleted, returning zero if that's the case.<br>
This class is old though, and somewhat superseded by<br>
IndexedDeclaration.<br>
<br>
IndexedDeclaration     :  A very efficient reference to a declaration<br>
by its indices. Generally the functionality is similar to<br>
DeclarationPointer, but it does not impose any additional<br>
memory-overhead for the KShared stuff, and it is persistent (can be<br>
stored to disk, and it can trigger loading of a top-context from disk<br>
if it has been unloaded out of memory)<br>
<br>
LocalIndexedDeclaration    :  Like IndexedDeclaration, except that it<br>
is slightly smaller and doesn't store the top-context index, so it<br>
gets the top-context handed directly. Used only internally by<br>
DUContext to save disk space and memory.<br>
<br>
DeclarationId     :     Does not refer one declaration object<br>
specifically, but rather just a declaration by its identifier. When<br>
the declaration is requested, it is looked up in the symbol table. A<br>
DeclarationId needs to get a top-context handed, and may return<br>
different declarations depending on the declarations included into<br>
that context. For example when you have the class "C" declared within<br>
two different files, you will always get the declaration within the<br>
file you give the top-context for. The big advantage of this class is<br>
that it is even more "correct" and persistent than IndexedDeclaration,<br>
as an IndexedDeclaration can also be invalidated sometimes when a<br>
declaration was deleted and re-created.<br>
<br>
2010/4/15 Sandro Andrade <<a href="mailto:sandro.andrade@gmail.com">sandro.andrade@gmail.com</a>>:<br>
<div class="im">>> > 6) If I select a new symbol while collecting uses, apparently the<br>
>> > collect<br>
>> > is paused and resumed from the last point if first symbol is selected<br>
>> > again. The pause point can be restored from m_waitForUpdate and<br>
>> > m_updateReady QSets in UsesCollector, but the question is: are the<br>
>> > remaining updateContextForUrl calls cancelled when a new symbol is<br>
>> > selected ? Or do they run to completion ?<br>
<br>
</div>Usually many context updates are requested to find the uses of one<br>
object (for all files that include a definition of a searched symbol).<br>
All the updates are queued into the background parser, and when the<br>
user stops the search, then the updates are removed again from the<br>
background-parser through backgroundParser::revertAllRequests.<br>
Next time the symbol is searched the same files will be requested for<br>
updating, but since they were already updated last time, they are<br>
returned instantly without having to wait, so it looks as if the<br>
search was "continued".<br>
<br>
As for efficiency: If you have a problem with the efficiency, then I<br>
guess you have to reduce the "backwards" expansion of the control flow<br>
graph, and maybe let the user do the expansion manually by clicking if<br>
he likes.<br>
<br>
Greetings, David<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>