Assorted questions ...

[Andreas Pakulat]

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

Thats absolutely correct. But if you look closer the example header
doesn't have a forward declaration for Bar. And thats what this problem
is about, if you have the include order bar, foo then your source will
compile because bar is already known when foo is included. However if
another source uses foo but not bar it will fail because Bar is unknown.
Now to make sure you catch these errors earlier you include foo.h as
first thing then Bar is not defined in your source either and you get an
error.

Andreas

-- 
You are as I am with You.