[Mockpp-commits] mockpp/mockpp/docs/en dev_embedded.docbook,1.3,1.4

[Ewald A. <ewa...@us...>]

Update of /cvsroot/mockpp/mockpp/mockpp/docs/en
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv29487/mockpp/docs/en

Modified Files:
	dev_embedded.docbook 
Log Message:
extend

Index: dev_embedded.docbook
===================================================================
RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/dev_embedded.docbook,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- dev_embedded.docbook	3 Dec 2005 15:56:33 -0000	1.3
+++ dev_embedded.docbook	3 Dec 2005 18:13:14 -0000	1.4
@@ -69,7 +69,33 @@
 
 </para>
 
-<para>
+<para>Disabling RTTI in mockpp; has little consequences. It is only used for a
+few diagnostic messages. In the worst case you might have to search for the
+problematic class.</para>
+
+<para>Disabling the regular STL is also no problem as far as &mockpp; is
+affected. If you use the minimalistic built-in STL for your own code you might
+miss the one or the
+other feature current implementations have. Either you find a workaround for
+this or you implement what is missing. There are also STL implementations
+available which are optimzied for embedded systems.</para>
+
+<para>The only real problem is exception handling. You can't simply turn his
+feature off and continue with the programm flow instead of throwing. When
+throwing an exception an application is typically in a critical state and its
+objects tend to be unusable. Continuing to
+use such an object is likely to crash the application. The other problem is the
+fact that the compiler can't prepare a way back to destroy automatic variables.
+This causes resource leaks.</para>
+
+<para>The only workaround so far is to immediately terminate the application.
+A compromise might be to start a thread for each single test case and terminate
+the thread upon the first malfunction. Probably this significantly slows down
+the test execution. Another possibility is to split the tests into portable and
+platform specific sections. The portable sections can be run on the development
+machine with full speed very often wherereas the complete tests are run on the
+target device only if appropriate.
+
 
 <programlisting>