Appended lists / DUChain item repository problem

[Sven Brauch]

Hi David,

thanks for your answer.

> Sorry, I've been very busy recently.
Not a problem at all, this wasn't very urgent -- I just sent the email
as a friendly reminder, since I assumed most people don't routinely
look through emails which are older than two months.
It is invaluable to have someone as familiar with the API as you are
answer tricky questions, no matter if it takes a few weeks now and
then.

The solution you suggested did indeed fix the crashes -- cool! Now I
can finally merge this nice feature :)
I was always confused about that m_dynamic parameter -- I assumed the
default value taken from that member function would do the same as
passing m_dynamic. Turns out this is not the case.
And yeah, UnsureType is indeed a good example, I'll look at it next
time I have such a problem.

Greetings,
Sven

2012/7/24 David Nolden <david.nolden.kdevelop at art-master.de>:
> Sorry, I've been very busy recently.
>
> Did you take a look at KDevelop::UnsureType? UnsureTypeData has
> exactly the same internal structure as your IndexedContainerData,
> except that it works. :-)
>
> initializeAppendedLists needs to be given an initialization parameter
> which tells it whether the internal data structures representing
> appended lists are to be in shared memory together with the internal
> type data (eg. _not_ dynamic), or whether the data is to be stored in
> the changeable dynamic member hash. After loading, the data is static,
> since it's in a memory-mapped region within the duchain data store.
>
> I think, all you need to do to fix your issue is calling
> "initializeAppendedLists(m_dynamic)", as UnsureType does.
>
> For DUChain data inheriting within the Declaration hierarchy this
> doesn't need to be done, because there this info comes implicitly from
> DUChainBaseData::appendedListDynamicDefault(), this is indeed a bit
> confusing. The best way to go is always following the examples. A good
> example for the type hierarchy is UnsureType, a good example for the
> declaration hierarchy is ClassFunctionDeclaration.
>
> Greetings, David
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel