Assorted questions ...

[Sandro Andrade]

Hi Andreas,

Thanks for reply. I read the documents about BC and some other questions
have raised:

1) I did some tests concerning binary compatibility. The scenario was:

liblib1.so contains:

class Lib1
{
public:
   void doSomething();
private:
   int x;
};

void Lib1::doSomething()
{
   cout << "Hello World !" << endl;
}

liblib2.so contains:

class Lib2
{
public:
   void doSomething();
private:
   Lib1 *lib1;
}

void Lib2::doSomething();
{
   lib1->doSomething();
}

my application contains:

int main()
{
   Lib2 *lib2 = ...;
   lib2->doSomething();
   return 0;
}

After all things compiled successfully, I added a second private data member
in Lib1 (float y), recompiled the liblib1.so, and all thinks in my
applications works fine !!! The added data member didn't break the binary
compatibility !!!!!

If I change the visibility of Lib1::doSomething() from public to private,
the application keeps working and a visibility error occurs only if I
recompile the application !!!

I'm using g++ v4 in a Debian-like Linux ! Why does BC remain working after
the included data member ?

2) Regarding the include order cited in
http://techbase.kde.org/Policies/Library_Code_Policy:

"*In your file foo.cpp, you should include "foo.h" as the first include,
before the system includes.* The rationale behind that is to make your
header standalone. Let's imagine that your foo.h looks like this:

class Foo
{
public:
    Bar getBar();

};

And your foo.cpp looks like this:

#include "bar.h"
#include "foo.h"

Your foo.cpp file will compile, but it will not compile for other
people using foo.h without including bar.h . Including "foo.h" first
makes sure that your foo.h header works for others."

I really didn't understand this. If foo.h contains a forward declaration of
Bar, other classes including foo.h will be successfully compiled, am I wrong
? Any troubles would occur at linking-time. Why the order of includes would
make difference ?

Thanks in advance,
Sandro Andrade

On 6/18/07, Andreas Pakulat < apaku at gmx.de> wrote:
>
> On 18.06.07 11:37:33, Sandro Andrade wrote:
> > Hello,
> >
> > I would be grateful for some explanation about the kdevelop code aspects
> > below:
> >
> > 1) Why does the Core class (and others classes) in shell directory
> contain a
> > CorePrivate struct ? Why the controller attributes weren't declared
> directly
> > in the Core class ?
>
> Because its easier to keep BC with that. See
> http://techbase.kde.org/Policies/Library_Code_Policy
> http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
>
> > 2) Where is the Core::setDocumentController method declared ? The Core
> class
> > contains just a documentController() accessor method !!!
>
> Thats right. There is no setDocumentController, the documentcontroller
> is setup during initialization
>
> > 3) Why to setup a new DocumentController if the initialize() method on
> > CorePrivate already creates a DocumentController ?
>
> I don't see that happening. CorePrivate::initialize creates the
> document controller, Core::initialize just calls
> CorePrivate::initialize()
>
> > 4) In main method the loadingPlugin signal from pluginController is
> > connected to the splash slot AFTER the invocation of
> > pluginController()->loadPlugins(). Is this useful ? No messages are
> > exhibited in the splash !!!
>
> Right, none of this is actually working at the moment. This will be
> fixed "some day".
>
> Andreas
>
> --
> You may be gone tomorrow, but that doesn't mean that you weren't here
> today.
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070618/e007f039/attachment.html>