[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    developer.kde.org/documentation/other
From:       Albert Astals Cid <tsdgeos () terra ! es>
Date:       2005-03-27 21:16:40
Message-ID: 20050327211640.488013E9 () office ! kde ! org
[Download RAW message or body]

CVS commit by aacid: 

Some more <p> and <li> closing


  M +18 -18    binarycompatibility.html   1.3


--- developer.kde.org/documentation/other/binarycompatibility.html  #1.2:1.3
@@ -21,9 +21,9 @@
 ensuring binary compatibility between releases, people will be forced
 to provide statically linked binaries. Static binaries  are bad because they
+</p>
 <ul>
-<li> waste resources (especially memory)
-<li> don't allow the program to benefit from bugfixes or extensions in the libraries
+<li> waste resources (especially memory)</li>
+<li> don't allow the program to benefit from bugfixes or extensions in the libraries</li>
 </ul>
-</p>
 
 <p> In the KDE project, we will provide binary compatibility within
@@ -37,5 +37,5 @@
 <ul>
 
-<li> add new non-virtual functions.
+<li> add new non-virtual functions.</li>
 
 <li> reimplement virtual functions defined in one of the base classes
@@ -43,5 +43,5 @@
 the library call the implementation in the base class rather than the
 new one. <em> This is tricky and might be dangerous. Think twice
-before doing it. </em>
+before doing it. </em></li>
 
 <li> change an inline function or make an inline function non-inline
@@ -50,28 +50,28 @@
 be dangerous. Think twice before doing it. </em> Because of this, classes
 that are supposed to stay binary compatible should <b>always</b> have
-non-inline destructor, even if it's empty.
+non-inline destructor, even if it's empty.</li>
 
 <li> Remove private non-virtual functions <b>if</b> they are not called
-by any inline functions.
+by any inline functions.</li>
 
 <li> change the default arguments of a method. It requires
-recompilation to use the actual new default argument values, though.
+recompilation to use the actual new default argument values, though.</li>
 
-<li> add new <b>static</b> data members.
+<li> add new <b>static</b> data members.</li>
 
-<li> add new classes.
+<li> add new classes.</li>
 
 </ul>
 
-<p> You cannot ...
+<p> You cannot ...</p>
 <ul>
 
 <li> add new virtual functions as this will change the layout of the
 virtual table and thus break subclasses. (In really necessary cases,
-there may be a workaround possible though - ask on mailing lists).
+there may be a workaround possible though - ask on mailing lists).</li>
 
 <li> change the order of virtual functions in the class
 declaration. This will just as well change the layout of the virtual
-table.
+table.</li>
 
 <li> change the signature of a function. Note that extending a
@@ -100,10 +100,10 @@
 (i.e. changing private->protected->public).
 The only compiler affected by this, that we know of, is MSVC++,
-and KDE doesn't compile on Windows anyway.
+and KDE doesn't compile on Windows anyway.</li>
 
 <li> add new data members to a class or change order of data members
-in a class (doesn't apply to static ones).
+in a class (doesn't apply to static ones).</li>
 
-<li> change the class hierachy apart from adding new classes.
+<li> change the class hierachy apart from adding new classes.</li>
 
 </ul>
@@ -272,6 +272,6 @@
 
 <li> Do not forget to add a BCI remark, so that the hack can be
-removed in the next version of the library.
-<li> Do not forget to add a d-pointer to your next class.
+removed in the next version of the library.</li>
+<li> Do not forget to add a d-pointer to your next class.</li>
  </ol>
 


[prev in list] [next in list] [prev in thread] [next in thread]