<p>On Apr 27, 2012 12:09 AM, "Milian Wolff" <<a href="mailto:mail@milianw.de">mail@milianw.de</a>> wrote:<br>
> Ah thanks :) I heard of such things, mostly from people who wondered whether<br>
> the kernel people would rewrite some parts with C++ once Linus goes away and<br>
> with him the NIH syndrome when it comes to such C++-mimicking :P Offtopic of<br>
> course!</p>
<p>Ohhhh don't get me started on this. :) But in short, apart from the heavy legacy that would render such an effort impracticable,  having a C++ runtime in the kernel has a cost and functions pointers do the job pretty well anyway (apart from the point I'd like to fix using KDevelop). There is a lot of posts dealing about it on the LKML if you want more details (and usually they don't end well for the poor soul who raised the question).</p>

<p>> Here, both b::i and c::i have the same type. But once you assign different<br>
> *values* to b::i::p and c::i::p these should be shown differently... How?<br>
> You'd need to store that information somewhere, essentially breaking the<br>
> invariant that b::i has the same type as c::i.</p>
<p>Excellent point. Well, as a first step I think it would be acceptable if all assignments to i::p were returned in both cases. It would already be a huge improvement over the current status, and anyway in such patterns most functions that manipulate ::i would directly take a pointer to an instance of ::i and not of b or c, rendering any further investigation impossible (it is similar to a function taking an instance of a base class instead of a more specialized subclass - in that case you need to list all subclasses as possible implementations). Sure for the cases where b::i or c::i is explicitly manipulated it would be nice to optimize. But that would be step 2. For now I don't even understand how the lookup thing in KDevelop really works.</p>

<p>> One could try to assign a custom StructureType to declarations using a struct<br>
> that contains function pointers and somehow introduce a mapping there...<br>
> Question again is: What if one assigns different functions to the function<br>
> pointer? I.e.: it shouldn't be a 1to1 mapping...</p>
<p>It does not need to be, and that's exactly the purpose. Every new assignment should be treated as a new "subclass". See, that's actually more powerful than C++ virtual functions, since you can hijack the implementation of a method in runtime, just like you would do in Python. ;) I used the comparison with C++ virtual functions to explain the main use, but actually it's a different thing.</p>

<p>> This is certainly possible, but far from trivial (see above). Personally, with<br>
> typical time constraints I'd definitely think this needs more than a month but<br>
> if one would work full time on it it... Maybe it could be done...</p>
<p>Yeah, maybe I should give up on having that ready before the conference, and instead concentrate on fixing remaining parser errors and mention it as (close) future work.</p>
<p>> Yes this should be properly separated to not complicate our c++ parser. And<br>
> you still need to find a way to define whether a file is c or c++ (esp. for .h<br>
> files). Afaik that also was mentioned in the merge request for the designated<br>
> initializers.</p>
<p>You're right. Well, the main problem is with .h files, as other source files can be appropriately discriminated through their extension. Actually I fail to understand how the KDev parser handles .h files - for instance, I noticed that if I open one without anything else it would be parsed "as is", but in some other cases (probably if a .c file that includes it is already open?) if would also use the context (defines, etc.) that was before its #include directive. In the last case the language of the including file (C or C++) could be passed to the child parser. Could you elaborate a little bit about how .h files parsing works?</p>

<p>In any case, separating C and C++ sounds like the most immediate thing to do at the moment. Moreover the kernel uses words like "class" or "virtual" for initializers a big lot. Just doing that would remove more than half of the parsing errors I still see.</p>

<p>Thanks for your insight!<br>
Alex.<br>
</p>