Store modification times in Declaration Data class?

Sven Brauch svenbrauch at googlemail.com
Sun Jul 31 20:54:51 UTC 2011


Hey,

I'm just trying to subclass UnsureType, but I can't seem to get it to
work. I always get weird crashes in KDevVarLengthArray (see
http://pastebin.kde.org/104239/). (I only got it to compile when
calling the DECLARE_LIST_MEMBER_HASH macro again, otherwise it
wouldn't even link).
Are there modifications necessary to the base Data class so I can
inherit from it? I found some macros in appendedlist.h which might
have to do with that, bit I just didn't understand it.

Thanks and bye,
Sven

2011/7/4 David Nolden <zwabel at googlemail.com>:
> 2011/7/4 Sven Brauch <svenbrauch at googlemail.com>:
>> Hi David,
>>
>> thanks for your response.
>> I imagined this to work like this: As soon as a file is parsed, it
>> throws all its type hints at all relevant declarations. Those stay
>> valid until the file is re-parsed; if it's re-parsed, it just creates
>> *new* type hints, which then are valid instead of the old ones. The
>> old ones will then be invalidated by comparing their creation time
>> with the current modification revision of the file, and noticing that
>> they're old. However, I don't know how much performance that would
>> eat.
>>
>> Still, your approach is probably more elegant. I'm just not entirely
>> sure if a type-hint can be bound to a specific use in all cases; it
>> *might* be a more complex expression. However, for the basic
>> function-argument hints I want to implement now I think that should
>> work.
>> I didn't exactly understand how your example works, tough... I do not
>> want to delete declarations if uses go away, I want to store a list of
>> types for a declaration which are deleted if their "uses" go away. How
>> is that to be realized with your example?
>
> There would need to be a version of UnsureType, where each sub-type
> attached to the UnsureType is conditioned by a specific use.
>
> Greetings, David
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>




More information about the KDevelop-devel mailing list