problème d'initialisation dans un constructeur

ReBojour

J'ai un problème avec un warning que je ne comprend pas:
Voici le warning :
feature.h: In constructor ‘recotex::Feature::Feature(real, real)’:
feature.h:114: attention : ‘recotex::Feature::m_weight’ will be initialized after
feature.h:110: attention : ‘int recotex::Feature::ind_orientation’
feature.h:124: attention : when initialized here


sachant que ma classe feature à les attribut suivant:
protected:
real m_orientation;
real m_scale;
int ind_orientation;
int ind_scale;
int type;
real m_weight;

et que le constructeur en question est :
inline Feature::Feature( real o, real s, real w )
: m_orientation( o ), m_scale( s ), m_weight( w ), ind_orientation(0),ind_scale(0)
{}

Je ne comprend vraiment pas le Warning.
Pouvez vous m'aider

D'avance merci

L'initialisation des membres se fait dans l'ordre dans lequel ils apparaissent dans la classe, pas dans l'ordre dans lequel ils sont cites dans la liste d'initialisation.

Le warning t'averti que les deux ordres sont differents.

Merci depuis le temps que j'éssayait de comprendre ce warning ça fais plaisir :D

Sinon j'ai egalement un warning type:
/usr/lib/qt-3.3/include/qfiledialog.h:78: attention : ‘class QFilePreview’ has virtual functions but non-virtual destructor


qui apparement vient de QT.
Que puis-je y faire??

Rien, tu ne vas pas modifier le code de QT pour ca.

Tu peux regarder la doc de ton compilo et ne pas activer le warning correspondant.
(Warning assez pénible quand on a des classes à fonctions membre virtuelles, mais dont le destructeur est protégé non virtuel..

Citation:

---

Envoyé par Luc Hermitte

(Warning assez pénible quand on a des classes à fonctions membre virtuelles, mais dont le destructeur est protégé non virtuel..

---

Hum, tu pourrais me donner un exemple pertinent de ce schéma ?

:koi:

Oui. C'est pour quand le LSP n'est pas la raison première de l'héritage, et que je veux tout de même spécialiser des comportements (des sortes de hooks).
Il m'arrive de faire ça pour des objets uniques (singletons par construction et sans l'artillerie instance()) vivant sur la pile.
Ce n'est pas une construction fréquente, mais parfois pertinente.

On rejoint l'item 50 du C++ coding standard : Make base class destructors public and virtual, or protected and non virtual. En traduisant un extrait à la volée on a:

Citation:

---

Envoyé par Herb Sutter et Andrei Alexandrescu

Exemple 2 : Classes de bases sans suppression (deletion) polymorphique. Si la suppression polymoprhique ne doit (shouldn't) pas être permise, le destructeur doit (must) être non-public (pour que le code utilisateur ne puisse pas l'appeler), et devrait (should) être non virtuelle (parce que cela n'est plus nécessaire).
[...]
Les classes Police (Policy classes) sont fréquemment utilisées comme classes de base par commodité, pas pour leur comportement polymorphique. Il est recommandé de définir leur destructeur protégé et non virtuel

---

.