Discussion :

[white_tentacle]

Si il n'y a aucun empêchement, alors il s'agit d'une erreur de conception car la valeur de qApp et celle de retour de QApplication::instance() seront indéterminées à l'exécution.

Nope. Tu peux dire que c’est une erreur d’implémentation si tu y tiens, mais certainement pas de conception. Le contrat te dit :
* tu dois créer une et une seule instance de QApplication
* tu choisis délibérément de faire autre chose, ça te pète à la gueule, c’est de *ta* faute, et uniquement de la tienne car tu n’as pas respecté le contrat.

Après, quand c’est possible, on aime bien forcer les gens à respecter les contrats plutôt que ça leur pète à la gueule, c’est généralement ce qui fait un code robuste . Mais c’est important de bien déterminer les responsabilités et de ne pas accuser un innocent.

[Kaamui]

Si il n'y a aucun empêchement, alors il s'agit d'une erreur de conception car la valeur de qApp et celle de retour de QApplication::instance() seront indéterminées à l'exécution.

Je ne penses pas que l'on puisse parler d'erreur de conception comme conséquence inévitable d'un "s"il n'y a aucun empêchement". Il s'agit peut-être d'un état indéterminé suite au non respect par l'utilisateur d'une précondition, si précisé comme suit dans la doc. Il s'agit ici plus d'une philosophie (empêcher l'utilisateur de faire des bêtises ou juste prévenir l'utilisateur ou juste ne pas déterminer les mauvaises utilisations). Ceci ne veut pas dire que tu as tord dans la finalité, juste que ton raccourci n'est pas correct.

C'est la balise QUOTE pour les citations, pas CODE

Pas vraiment. Une interface ne possède que des signatures de méthodes en Java (pas d'implémentation et donc pas d'attributs) à la différence de la classe abstraite qui elle n'est tout simplement pas complétement implémentée (donc pas instanciable non plus). Le pattern que j'utilise est "fréquent" en Java car l'API native est plus riche en Java qu'en C++ mais il ne s'agit pas d'une particularité de ce langage donc je ne cherche pas à tout prix à reproduite le schéma de Runnable.

Je ne disais pas qu'une interface Java = classe abstraite C++, je disais que si tu souhaites forcer l'utilisateur à implémenter des méthodes, alors cf. ce que j'ai dit. Pour ce qui est du Runnable, je n'ai pas dit que c'est ce que tu cherchais à tout prix . Mais j'ai cru lire que tu cherchais à faire une classe non instanciable obligeant à coder une fonction run(), j'ai donc imaginé que tu puisait ton inspiration de la classe Runnable.

Je reste également persuadé que ce que tu souhaites est faisable à la compilation. A condition d'avoir bien posé le problème ou la problématique

[RPGamer]

En principe la valeur de retour d'une fonction ne doit jamais être indéterminée à l'exécution. Cette règle s'applique, pour des raison évidentes de fiabilité, quelle que soit la situation, d'où ma remarque.

Pour en revenir au sujet, je ne pense pas qu'il soit possible aisément de détecter ce genre de mauvaise utilisation à la compilation car il faudrait une directive de précompilation capable de déclarer une règle de compilation, ce qui, à ma connaissance, n'existe pas.

La seule idée qui me vient en tête serait de remplacer le constructeur par une macro. Mais ca parait casse-gueule.

[mintho carmo]

Dans QCoreApplication, c'est un simple pointeur statique (comme dans un singleton), avec un assert pour vérifier que la classe n'est pas instanciée plusieurs fois. Aucun mécanisme de vérification a la compilation

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class K {
public:
  K() : p_(0) {
    assert(!p_);
  }
 
  static K* instance() { 
    assert(p_);
    return p_;
  }
 
private:
  static K* p_;
};

[RPGamer]

OK c'est ce qui paraissait le plus probable. Dans mon code je remplace juste assert() par une exception dédiée.

Merci pour vos interventions.