Quand java comence à vous parler de  
"cannot reference this before supertype constructor has been called", c'est la merde.  
 
 
je vous donne l'exemple typique en java :

On n'a pas le droit de toucher à this avant que le constructeur de la superclasse ne soit appellé. Hors ici le this est implicite. On a écrit un code qui nécessite d'évaluer this.pipo() avant d'évaluer super().
 
l'appel à super peut-lui aussi être implicite :

Ici le compilo va vous parler de déréférencement de this alors qu'aucune référence this n'est écrite (le this() est l'appel du constructeur, rien à voir avec une référence vers l'objet courant) et qu'aucun super n'est écrit.
 
D'autre part, les langages on tendance à fournir un constructeur par défaut quand il n'y en a pas, ça peut être source de petit pièges.
 
Même combat en C#, quelqu'un a eu un problème du même type récement sur le forum. Il est important de bien lire les specs des langages quand on a un message d'erreur louche, le code que l'on voit n'est pas forcément celui qui est compilé.
 
références :
les constructeurs java :
http://java.sun.com/docs/books/jls [...] html#78435
 
les constructeurs C# (qui adoptent la syntaxe C++ pour l'initialisation) :
http://www.jaggersoft.com/csharp_standard/17.10.htm
avec l'appel automatique au constructeur de base dans l'initialisation :
http://www.jaggersoft.com/csharp_standard/17.10.1.htm
 
constructeurs C++ :
http://www.kuzbass.ru:8086/docs/is [...] class.ctor
initialisation :
http://www.kuzbass.ru:8086/docs/is [...] class.init
 
 
on voit au passage de C++ et C# font les bidouilles d'appels (implicites et explicites) de constructeurs dans l'initialisation alors que java qui n'a pas d'initialisation possède une syntaxe optionelle pour la première instruction du constructeur.
 
 
Tout ceci est logique quand on y réfléchit mais ce n'est pas immédiant, en particulier quand le message d'erreur vous parle de code que vous n'avez pas écrit.
Une chose rassurante : si vous risquez de galérer devant un message d'erreur cryptique, le code généré est parfaitement logique, il faudrait vraiment le chercher pour que le compilo génère un code qui soit source de bug et qui compile coreectement. Donc globalement, si ça compile, ça devrait faire ce qu'on attend de lui.
 
 
edit :
2 cas réels  
en java :
http://216.239.59.104/search?q=cac [...] n&ie=UTF-8
en C# récement :
http://forum.hardware.fr/forum2.ph [...] subcat=405

merci

euh je vois pas le problème en C++ ?

encore un détail  
l'appel de la méthode pipo() des exemples java peut se classer dans 3 catégories :

• soit c'est une vraie méthode dont le résultat dépend de l'état interne de l'objet et alors il était de toutes façons con de vouloir l'appeller avant la fin de la construction vu qu'on ne sait rien de l'objet et que ça a toutes les chances de mal se finir.
• soit c'est une fonction, ie. un bout de programme renvoyant un résultat qui ne dépend que de ses arguments ; auquel cas elle n'a rien à foutre, là, une classe c'est la description du comportement d'un objet, pas un système de rangement de fonctions par ordre d'idée. Il faut la passer en statique, domaine qui est déjà bordélique.
• soit c'est une méthode dont le résultat dépend à la fois des arguments et des champs statiques de la classe, auquel cas, le mot-clef statique n'est pas fait pour les chèvres.

 
(dans mon cas, puisque vous vous doutez bizn que mon topic n'est pas inocent, c'est le 2ème, mais c'est pas moi qui est écrit la méthode, qui va d'ailleur gicler très rapidement).