Re: Ordre des constructeurs

ça semble être un soucis d’analyse du problème.

Ça pourrait bien être le cas. Ceci dit, il arrive bien souvent qu'un «problème d'analyse» ne soit pas vraiment distinguable d'une chose que C++ ne sait pas faire ; c'est clair que j'essaye de faire quelque chose qui n'est pas naturel en C++. Le principe de ce qui me semblerait naturel (vite fait):

struct Point {
 Point(double xx, double yy) : x(xx), y(yy) { }
 double x;
 double y;
};
class Polygon {
 public:
 Polygon() { init(); }
 virtual ~ Polygon() {}
 virtual void init() {
 for (int i = 0; i < get_nb_points(); i++) {
 Point p = Point(cos(i*360/get_nb_points()), sin(i*360/get_nb_points()));
 v.push_back(p);
 }
 }
 virtual int get_nb_points() { return 0; }
 protected:
 std::vector<Point> v;
};
class Triangle: public Polygon {
 public:
 Triangle(): Polygon() { } 
 int get_nb_points() const { return 3; } // pourrait être plus compliqué, lire dans un fichier, etc. 
};

La logique, c'est que Polygon sait se construire tout seul avec un code générique, il lui manque juste quelques infos auxquelles il pourrait accéder par des "getters" virtuels qui, eux, sont spéciques des classes dérivées. Finalement, ça revient à dire que je souhaite juste éviter quelque chose du style Polygon * p = new Triangle(); p->init(); afin d'éviter de pouvoir laisser l'objet dans un état pas complètement construit.

Le callback permet d'inverser artifciellement l'ordre de la construction, et je réalise que dans tous les cas un bricolage de ce style s'impose. Ça pourrait aussi être une Factory qui s'occuppe d'appeler le constructeur et init() dans la foulée, ou tout un tas d'autres «solutions» (par ex. une fonction statique Polygon* Construct()...). Plus j'y pense et plus j'ai l'impression que ce que j'essaye de faire, c'est de donner également le rôle de Factory à la classe de base, et que ça n'est pas une bonne idée...

Merci pour les pistes!