Hello Sebastian!
You wrote:
 SN>  I came to the following question,
 SN>  The fact that constructors and destructors MUST be public, doesn't go
No they don't.  But the reasons you'd make them protected or provate are to 
implement a particular idiom.
 SN>  against the OOP philosophy, which says that the good-working of the
 SN>  object should be asured, restricting the access the programmer to
 SN>  the methods and/or data he shouldn't touch?
How do you propose to allow objects to be created and destroyed either in 
static memory or as local variables on the stack?  In each case, the dtor is 
called automatically when the object goes out of scope by code that is not 
part of a member function of the object's class.  So, external access is 
necessary unless you intend that all objects should be created on the heap.  
Similary, the ctor has to be public if the object is to be created in static 
memory or on the stack, as the code to generate the object will (almost 
always) also not be in a member function of the object's class.
There is a sneeky, back door way to create a local variable when either it's 
ctor or dtor are private.  I'll award extra guru points to anyone who can 
identify it.  Note that I do expect the solution to be leak proof.
 SN>  I mean, nothing stops me from calling a constructor or destructor in
 SN>  the middle of a process and continue using the object as nothing has
 SN>  happened (wich of course leads to God knows what).
You can't just "call" the ctor for an existing object.  If your compiler 
allows you to compile such code, it is badly broken, and you should replace 
it.  There is one specific case where you need to be able to call the ctor 
directly for an object.  But this is an advanced application, and it is 
expected that advanced software engineers can be trusted with real tools.
    -Ron  (ron-bass@ti.com)
--- EZPoint V2.2
---------------