Broken Code in KDevelop/C++
apaku at gmx.de
Tue Feb 26 19:57:56 UTC 2008
On 26.02.08 20:40:57, David Nolden wrote:
> On Tuesday 26 February 2008 20:23:42 Andreas Pakulat wrote:
> > Hi,
> > languages/cpp/cppduchain/templateparameterdeclaration.cpp:21
> > uses a private header from the duchain. That is not possible, the _p.h
> > header are only usable inside the duchain library.
> > Also they are now installed, which is complete and utter nonsense, the
> > whole point of the private classes is to be able to break BC on them, so
> > nothing outside the language library can use them. That change needs to
> > be reverted.
> > Andreas
> Have you looked at the code? That shared d-pointer thing was your own idea,
Yes, but not using it across module boundaries.
> and why should it stop at the border between kdevplatform and kdevelop? Do we
> need binary comptability between different versions of kdevplatform and
> kdevelop? No we don't.
Its not about that. Exporting the class and especially installing its
header makes it part of the public API and thus subject to all those BC
rules (including having a Private dptr). Thats not going to work.
We're writing a BC-keeping library here, so we need our Private classes
to stay private. The fact that it works between editor and language lib
is simply due to both being in the same module and thus being able to
directly use the _p.h header of the other lib.
> I prefer having a kdevelop that does not eat my whole gigabyte of memory just
> for the code model some time.
Then start working on putting some of that model into a persistant
> Of course you can revert that change, but it would clearly be a step back to
Thats unfortunate, though there's another option (which I already
mentioned in the other mail): Simply move that single class that
actually used the private class into kdevplatform.
Be cheerful while you are alive.
-- Phathotep, 24th Century B.C.
More information about the KDevelop-devel