<br>Hi Andreas,<br><br>Thanks for reply. I read the documents about BC and some other questions have raised:<br><br>1) I did some tests concerning binary compatibility. The scenario was:<br><br>liblib1.so contains:<br><br>

class Lib1<br>{<br>public:<br>   void doSomething();<br>private:<br>   int x;<br>};<br><br>void Lib1::doSomething()<br>{<br>   cout << "Hello World !" << endl;<br>}<br><br>liblib2.so contains:<br><br>

class Lib2<br>{<br>public:<br>   void doSomething();<br>private:<br>   Lib1 *lib1;<br>}<br><br>void Lib2::doSomething();<br>{<br>   lib1->doSomething();<br>}<br><br>my application contains:<br><br>int main()<br>{<br>   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 ?

<br><br>2) Regarding the include order cited in <a href="http://techbase.kde.org/Policies/Library_Code_Policy">http://techbase.kde.org/Policies/Library_Code_Policy</a>:<br><br>"<i>In your file foo.cpp, you should include "

foo.h" as the first include, before the system includes.</i> The rationale behind that is to make your header standalone. Let's imagine that your foo.h looks like this:

<pre class="cpp"><span style="color: rgb(0, 0, 255);">class</span> Foo<br><span style="color: rgb(0, 0, 0);">{</span><br><span style="color: rgb(0, 0, 255);">public</span>:<br>    Bar getBar<span style="color: rgb(0, 0, 0);">

(</span><span style="color: rgb(0, 0, 0);">)</span>;<br> <br><span style="color: rgb(0, 0, 0);">}</span>;</pre>

<p>And your foo.cpp looks like this:

</p>

<pre>#include "bar.h"<br>#include "foo.h"<span style="font-family: arial,sans-serif;"><br><br></span>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." </pre>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 ?

<br><br>Thanks in advance,<br>Sandro Andrade<br><br><div><span class="gmail_quote">On 6/18/07, <b class="gmail_sendername">Andreas Pakulat</b> <

<a href="mailto:apaku@gmx.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

apaku@gmx.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On 18.06.07 11:37:33, Sandro Andrade wrote:<br>> Hello,

<br>><br>> I would be grateful for some explanation about the kdevelop code aspects<br>> below:<br>><br>> 1) Why does the Core class (and others classes) in shell directory contain a<br>> CorePrivate struct ? Why the controller attributes weren't declared directly

<br>> in the Core class ?<br><br>Because its easier to keep BC with that. See<br><a href="http://techbase.kde.org/Policies/Library_Code_Policy" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://techbase.kde.org/Policies/Library_Code_Policy

</a><br><a href="http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++</a> > 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 ?

<br><br>I don't see that happening. CorePrivate::initialize creates the<br>document controller, Core::initialize just calls<br>CorePrivate::initialize()<br><br>> 4) In main method the loadingPlugin signal from pluginController is

<br>> connected to the splash slot AFTER the invocation of<br>> pluginController()->loadPlugins(). Is this useful ? No messages are<br>> exhibited in the splash !!!<br><br>Right, none of this is actually working at the moment. This will be

<br>fixed "some day".<br><br>Andreas<br><br>--<br>You may be gone tomorrow, but that doesn't mean that you weren't here today.<br><br>_______________________________________________<br>KDevelop-devel mailing list

<br><a href="mailto:KDevelop-devel@kdevelop.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">KDevelop-devel@kdevelop.org</a><br><a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

</a><br></blockquote></div><br>