Re: Hmm :/

J'aime bien ta solution, conceptuellement, elle est élégante. Juste une remarque cependant, tel que présenté, tu t'appuies implicitement sur l'ordre d'évaluation des expressions en C et notamment sur le fait qu'une expression booléenne ne sera pas évaluée jusqu'au bout si on est sûr qu'elle est fausse. Mais le problème se règle de façon assez évidente avec un problème plus concrêt :


bool init1()
{
bool error = false;

error = request_region (...);
if (!error)
{
error = init2 ();
if (error)
release_region (...);
}

return error;
}

bool init2()
{
bool error = false;

error = init_device (...);
if (!error)
{
error = init3 ();
if (error)
/* nothing to do */;
}

return error;
}


Mais pour être franc, cette solution ne me semble adaptée que pour des initialisations lourdes et où l'on souhaite coder le processus d'initialisation en dur.

Parce que pour la plupart des initialisations, le nombre d'éléments dans la pile d'initialisation se compte sur les doigts d'une main. Pour ce genre de problème, le goto est une bonne solution puisque :
- c'est court, donc plus facile à lire (si tout tient en quelques lignes bien sûr)
- c'est une solution connue, elle est donc facilement lisible par tout programmeur ayant un minimum d'expérience
- ça ne mets pas en jeu la moindre (méta) donnée (explicite ou même implicite comme dans ta solution), ça ne joue que sur du contrôle

Pour les initialisation plus lourdes, il existe une foule d'autres solutions qui feront sans doute usage de données pour décrire la pile d'initialisation. Je n'ai pas d'exemple sous la main, mais à mon avis, c'est plus rare et ta solution sera sans doute en concurrence avec d'autres plus adaptées à des problèmes complexes (par exemple si on ajoutait du parallélisme et des dépendances, mais je m'égare).