List Info

Thread: Assorted questions ...
Assorted questions ...
user name
 2007-06-18 09:37:33 

  


  

    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 ?


2) Where is the Core::setDocumentController method declared ? The Core class contains just a documentController() accessor method !!!

3) Why to setup a new DocumentController if the initialize() method on CorePrivate already creates a DocumentController ?


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 !!!


Thanks in advance,
Sandro



  

  
  
   
     
    

  

    Re: Assorted questions ...
  


  

     user name

     2007-06-18 10:11:20
  


  

    
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_Com
patibility_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-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel



  


  

    
  

  
  
   
     
    

  

    Re: Assorted questions ...
  


  

     user name

     2007-06-18 21:25:52
  


  

    

  


  

    
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()
{
 &nbsp; cout << "Hello World !" << endl;
}

liblib2.so contains:


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

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

my application contains:

int main()
{
&nbsp;  Lib2 *lib2 = ...;

&nbsp;  lib2->doSomething();
 &nbsp; 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.&quot;
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 <
 apakugmx.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
apakugmx.de>; wrote:
On 18.06.07 11:37:33, Sandro Andrade wrote:
>; Hello,

&gt;
> I would be grateful for some explanation about the kdevelop code aspects
&gt; 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++

&gt; 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()-&gt;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-develkdevelop.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">KDevelop-develkdevelop.org


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






  

  
  
   
     
    

  

    Re: Assorted questions ...
  


  

     user name

     2007-06-18 22:49:16
  


  

    

  


  

    On 6/18/07, Matthew Woehlke < mw_triadusers.sourceforge.net">mw_triadusers.sourceforge.net> wrote:

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

Because you weren't using the class that you changed.

Thanks, Matthew. Now I got a "bus error"; !


Thanks,
Sandro

--
Matthew
"Still the prettiest." -- Legolas

(as quoted in The Very Secret Diaries by Cassandra Claire)
http://www.ealasaid.com/misc/vsd/


_______________________________________________
KDevelop-devel mailing list

 KDevelop-develkdevelop.org">KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel






  

  
  
   
     
    

  

    Re: Assorted questions ...
  


  

     user name

     2007-06-19 03:20:14
  


  

    
On 18.06.07 23:25:52, Sandro Andrade wrote:
> 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 !!!!!

I'd like to add to what Matthew said that there are certain
things that
are binary compatible, for example adding a new non-virtual
function. Of
course an application can't use this unless the application
is
recompiled against the newer version of the library.

> 2) Regarding the include order cited in
> kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel



  


  

    
  

  
  
   
     
    

  

    Re: Assorted questions ...
  


  

     country flaguser name
Romania		
     2007-06-19 06:55:30
  


  

    
On Tuesday 19 June 2007, Sandro Andrade wrote:
> Thanks for reply. I read the documents about BC and
some other
> questions have raised:

Did you read this one: 
http://developer.kde.org/documentation/othe
r/binarycompatibility.html ?

It writes down clearly what you can and can't do.

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel



  


  

    
  

  
  
   
     
    

  

    Re: Assorted questions ...
  


  

     user name

     2007-06-19 07:11:02
  


  

    
On 19.06.07 14:55:30, Andras Mantia wrote:
> On Tuesday 19 June 2007, Sandro Andrade wrote:
> > Thanks for reply. I read the documents about BC
and some other
> > questions have raised:
> 
> Did you read this one: 
> http://developer.kde.org/documentation/othe
r/binarycompatibility.html ?

Or rather: 
http://techbase.kde.org/Policies/Binary
_Compatibility_Issues_With_C%2B%2B

which is the maintained version

Andreas

Andreas

-- 
So this is it.  We're going to die.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel



  


  

    
  

  
  
   
     
    

  

    RE: Assorted questions ...
  


  

     country flaguser name
United States		
     2007-06-19 07:18:14
  


  

    
> class Foo
> {
> public:
>     Bar getBar();
> };
>
> 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 ?

In this particular instance, you are wrong.  Forward
declarations only
work for references or pointers.  A source file that
#include's foo.h
cannot compile w/o first #include'ing bar.h, which is bad
form.

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel



  


  

    
  

  
  
   
     
    

  

    Re: Assorted questions ...
  


  

     user name

     2007-06-19 08:03:51
  


  

    

  


  

    

In this particular instance, you are wrong.&nbsp; Forward declarations only

work for references or pointers.&nbsp; A source file that #include&#39;s foo.h
cannot compile w/o first #include&#39;ing bar.h, which is bad form.

Kris Wong

Hi guys ! It's all very clear now ! Thanks !




Sandro


_______________________________________________
KDevelop-devel mailing list

 KDevelop-develkdevelop.org">KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel






  

  
  
   
     
    

  

    Re: Assorted questions ...
  


  

     country flaguser name
Romania		
     2007-06-19 10:06:52
  


  

    
On Tuesday 19 June 2007, Andreas Pakulat wrote:
> On 19.06.07 14:55:30, Andras Mantia wrote:
> > On Tuesday 19 June 2007, Sandro Andrade wrote:
> > > Thanks for reply. I read the documents about
BC and some other
> > > questions have raised:
> >
> > Did you read this one:
> > http://developer.kde.org/documentation/other/
binarycompatibility.ht
> >ml ?
>
> Or rather:
> http://techbase.kde.org/Policies/Binary_Com
patibility_Issues_With_C%2
>B%2B
>
> which is the maintained version

Thanks, unfortunately "gg:binary compatibility
site:kde.org" still gives 
no matches to techbase on the first page (and gives
"my" link as the 
first match).

Andras


-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel



  


  

    
  

  
  
   
     
    






 [1-10] [11-12]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )