Will be speaking about KDevelop at LinuxCon Japan 2012

[Alexandre Courbot]

On Apr 27, 2012 12:09 AM, "Milian Wolff" <mail at milianw.de> wrote:
> Ah thanks :) I heard of such things, mostly from people who wondered
whether
> the kernel people would rewrite some parts with C++ once Linus goes away
and
> with him the NIH syndrome when it comes to such C++-mimicking :P Offtopic
of
> course!

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).

> Here, both b::i and c::i have the same type. But once you assign different
> *values* to b::i::p and c::i::p these should be shown differently... How?
> You'd need to store that information somewhere, essentially breaking the
> invariant that b::i has the same type as c::i.

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.

> One could try to assign a custom StructureType to declarations using a
struct
> that contains function pointers and somehow introduce a mapping there...
> Question again is: What if one assigns different functions to the function
> pointer? I.e.: it shouldn't be a 1to1 mapping...

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.

> This is certainly possible, but far from trivial (see above). Personally,
with
> typical time constraints I'd definitely think this needs more than a
month but
> if one would work full time on it it... Maybe it could be done...

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.

> Yes this should be properly separated to not complicate our c++ parser.
And
> you still need to find a way to define whether a file is c or c++ (esp.
for .h
> files). Afaik that also was mentioned in the merge request for the
designated
> initializers.

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?

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.

Thanks for your insight!
Alex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120428/535295a2/attachment.html>