./105 > Le faire à la main ça se fait avec LoadLibrary() et GetProcAddress() sous Windows, et dlopen() et dlsym() à d'autres endroits.
Mais ce n'est intéressant que pour des scénarios spécifiques (le plus commun étant: un système de plug-ins), et c'est pareil, il *faut* _toujours_ libérer les références à ces librairies quand tu ne t'en sers plus. Tu ne sais absolument pas ce que la librairie peut avoir à gérer (donc allouer) comme ressources derrière ton dos, donc tu te dois de la libérer proprement !
Pareil pour la classe Application non libérée. Désolé Brunni, mais il n'y a rien de pire que faire ça. Dans un langage avec GC, ta classe sera automatiquement libérée donc c'est hors-propos, mais pour un langage comme le C++, bien conçue, le detructeur de ton "Application" va certainement faire bien plus que de simplement libérer la mémoire. C'est juste un gros bug de passer outre… un « delete myApplication; » ça te coute quand même pas grand chose…

Globalement quand tu codes, il faut considérer tout ce que tu utilises comme une boîte noire (même si c'est toi qui l'a codé…). Tu sais ce que ça prend en entrée et ce que ça fait en sortie. Le reste tu n'as pas à t'en préoccuper (ou en dernier recours si le truc est buggué et impossible à réparer ni à contourner). De cette manière, si tu change un composant (par une version avec un API compatible hein ) sans toucher aux autres, le code continue de compiler et de fonctionner à la perfection. Allouer et désallouer la mémoire fait partie des protocoles à respecter, c'est tout…