Benutzer:Rdiez/HowToWriteMaintainableInitialisationAndTerminationCode - Versionsgeschichte

Rdiez: Weiterleitung nach Benutzer:Rdiez/PageRemoved erstellt

2015-03-22T19:17:05Z

Weiterleitung nach Benutzer:Rdiez/PageRemoved erstellt

Rdiez am 19. April 2013 um 18:08 Uhr

2013-04-19T18:08:56Z

Rdiez: Die Seite wurde neu angelegt: „= How to write maintainable initialisation and termination code = The traditional, C-style way is still the best one: int main ( int argc, char * argv[] ) { …“

2013-03-08T20:51:38Z

Die Seite wurde neu angelegt: „= How to write maintainable initialisation and termination code = The traditional, C-style way is still the best one: int main ( int argc, char * argv[] ) { …“

Neue Seite

= How to write maintainable initialisation and termination code =

The traditional, C-style way is still the best one:

int main ( int argc, char * argv[] )
{
InitA();
InitB();
InitC();
...
create some threads
...
do some work
...
wait for thread termination
...
FiniC();
FiniB();
FiniA();

// Here you can check for memory and file descriptor leaks.

return whatever;
}

Don't over-engineer it! The method above is not cool, but is perfectly adequate. It's
easy to understand and to maintain. Sometimes it can be tricky to find the right
initialisation order, but then it will be explicitly described, and above all,
it will remain the same no matter what the other code does.

The only real drawback is that, if you have different applications/programs,
you need to write a new version of the above for each one,
and probably most of it will be copy-paste duplication. But that is a minor inconvenience.

== Do not define global or static object instances, use pointers instead ==

Global or static object instances generate constructor calls that are executed before main(),
and that may be too early, if not today, then probably in the future.

Besides, singleton objects tend to use other global, singleton objects, and the initialisation order
of such objects is not guaranteed in the C standard. The order in which the constructors are called may depend
on your operating system, on your compiler version, or even on the order in which the object modules
are listed on your makefile (the order in the linker command line).

If you want to reuse the code in an embedded application, you may find it difficult to control
the initialisation order, especially since it is often poorly documented or hard to adapt.
For example, think about the PowerPC EABI, which injects a hidden __eabi() call in
main() in order to initialise C++ exception support and so on. Say you want to use your own
memory allocator and __eabi() is calling some C++ constructors before your code runs:
you'll have to learn much more about EABI and about the C runtime initialisation than you ever wanted to.

If you need to move the code to a Windows DLL or to a Unix Shared Object at a later point in time, you will have to rewrite the initialisation logic anyway.

Therefore, always use global or static pointers, and let them be NULL on start-up, then follow the initialisation method described above:

CreateSingletonA();
CreateSingletonB();
...
GetSingletonA()->UseIt(); GetSingletonB()->UseIt(); ...
GetSingletonA()->UseIt(); GetSingletonB()->UseIt(); ...
...
DestroySingletonB();
DestroySingletonA();

== Do not initialise global singletons on first touch ==

Unless you really need the performance improvement that lazy initialisation may provide, avoid
using such an object creation pattern:

MyClass * GetSingleton ( void )
{
static MyClass obj;
return &obj;
}

Reasons to avoid it are:

* The function above may not be thread-safe on all platforms, especially on embedded targets.
* The destructor will run after main(), making memory leak detection difficult. <br/> An error during destruction may need to be logged, but the logger object may have been destroyed already.
* The destruction order for such objects is not specified, not portable, etc. <br/> At some point in the future, you may need to destroy some other singleton beforehand, and that's impossible to do in a portable way.
* The initialisation order will depend on the code that uses the singletons. <br/> If the usage pattern changes, the object may initialise too early or too late. It is not immediately obvious that moving a call to GetSingleton() may change the initialisation or destruction order.

== Forget about atexit() and friends ==

You'll have a hard time trying to control the destruction order in a portable manner. Some embedded platforms do not have atexit() support.

← Nächstältere Version		Version vom 19. April 2013, 18:08 Uhr
Zeile 1:		Zeile 1:
		+	{{BenutzerSeitenNichtVeraendernWarnung\|rdiez}}
		+
	= How to write maintainable initialisation and termination code =		= How to write maintainable initialisation and termination code =

@@ Zeile 1: / Zeile 1: @@
-{{BenutzerSeitenNichtVeraendernWarnung|rdiez}}
+#REDIRECT [[Benutzer:Rdiez/PageRemoved]]
-−
-= How to write maintainable initialisation and termination code =
-−
-The traditional, C-style way is still the best one:
-−
- int main ( int argc, char * argv[] )
-−
-   InitA();
-   InitB();
-   InitC();
-   ...
-   create some threads
-   ...
-   do some work
-   ...
-   wait for thread termination
-   ...
-   FiniC();
-   FiniB();
-   FiniA();
-−
-   // Here you can check for memory and file descriptor leaks.
-−
-   return whatever;
-−
-−
-Don't over-engineer it! The method above is not cool, but is perfectly adequate. It's
-easy to understand and to maintain. Sometimes it can be tricky to find the right
-initialisation order, but then it will be explicitly described, and above all,
-it will remain the same no matter what the other code does.
-−
-The only real drawback is that, if you have different applications/programs,
-you need to write a new version of the above for each one,
-and probably most of it will be copy-paste duplication. But that is a minor inconvenience.
-−
-== Do not define global or static object instances, use pointers instead ==
-−
-Global or static object instances generate constructor calls that are executed before main(),
-and that may be too early, if not today, then probably in the future.
-−
-Besides, singleton objects tend to use other global, singleton objects, and the initialisation order
-of such objects is not guaranteed in the C standard. The order in which the constructors are called may depend
-on your operating system, on your compiler version, or even on the order in which the object modules
-are listed on your makefile (the order in the linker command line).
-−
-If you want to reuse the code in an embedded application, you may find it difficult to control
-the initialisation order, especially since it is often poorly documented or hard to adapt.
-For example, think about the PowerPC EABI, which injects a hidden __eabi() call in
-main() in order to initialise C++ exception support and so on. Say you want to use your own
-memory allocator and __eabi() is calling some C++ constructors before your code runs:
-you'll have to learn much more about EABI and about the C runtime initialisation than you ever wanted to.
-−
-If you need to move the code to a Windows DLL or to a Unix Shared Object at a later point in time, you will have to rewrite the initialisation logic anyway.
-−
-Therefore, always use global or static pointers, and let them be NULL on start-up, then follow the initialisation method described above:
-−
-  CreateSingletonA();
-  CreateSingletonB();
-  ...
-  GetSingletonA()->UseIt();  GetSingletonB()->UseIt();  ...
-  GetSingletonA()->UseIt();  GetSingletonB()->UseIt();  ...
-  ...
-  DestroySingletonB();
-  DestroySingletonA();
-−
-== Do not initialise global singletons on first touch ==
-−
-Unless you really need the performance improvement that lazy initialisation may provide, avoid
-using such an object creation pattern:
-−
-  MyClass * GetSingleton ( void )
-−
-    static MyClass obj;
-    return &obj;
-−
-−
-Reasons to avoid it are:
-−
-* The function above may not be thread-safe on all platforms, especially on embedded targets.
-* The destructor will run after main(), making memory leak detection difficult. <br/> An error during destruction may need to be logged, but the logger object may have been destroyed already.
-* The destruction order for such objects is not specified, not portable, etc. <br/> At some point in the future, you may need to destroy some other singleton beforehand, and that's impossible to do in a portable way.
-* The initialisation order will depend on the code that uses the singletons. <br/> If the usage pattern changes, the object may initialise too early or too late. It is not immediately obvious that moving a call to GetSingleton() may change the initialisation or destruction order.
-−
-== Forget about atexit() and friends ==
-−
-You'll have a hard time trying to control the destruction order in a portable manner. Some embedded platforms do not have atexit() support.