DU-chain classes questions ...

[Sandro Andrade]

Hi David,

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

Thanks,
Sandro

On Sat, Apr 17, 2010 at 10:49 AM, David Nolden <zwabel at googlemail.com>wrote:

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