momotte (./48) :
sinon le "high probability", bah, a partir du moment ou les const sont utilises la ou il faut, tu as l'info directement dans la declaration de la fonction

Ça ne vaut pas l'information que d'avoir les & dans chaque ligne qui utilise la fonction fournit!

et si tu utilises une IDE un minimum evoluee (style visual studio, par exemple ), tu as l'info directement lorsque tu ecris l'appel a la methode...

Mais le code est lu bien plus souvent qu'écrit.

Sasume (./50) :
Mouais justement je trouvais ça très bien au début aussi, mais en fait maintenant à chaque fois que j'utilise un objet Qt, j'en viens à me poser la question de savoir s'il est implicitement partagé ou non pour savoir comment je peux l'utiliser dans mon code sans affecter les performances. Du coup je suis obligé de vérifier, et je perds du temps, et puis le fait que ça crée deux niveaux d'objets ça fait que je suis obligé de produire deux styles de code selon les objets que je manipule, etc. Enfin bref, ça ne me fait pas vraiment gagner de temps (sauf pour QString parce que j'ai l'habitude avec celui-là mais c'est tout) et ça me conforte dans l'idée que le C++ est pénible à utiliser

Pourtant, c'est simple, avec Qt 4 il n'y a que 2 types d'objet (Qt 3 était un peu plus bordélique, il y avait des classes explicitly shared):
* les objets dérivés de QObject. Ce sont les "vrais" objets, tout ce qui peut envoyer ou recevoir des évènements est un QObject. Ces objets sont normalement toujours utilisés sous forme de pointeurs (c'est une mauvaise idée d'avoir un QObject local parce qu'un QObject peut être libéré automatiquement si l'objet parent l'est, et aussi parce que ça consomme trop de place sur la pile), il est interdit de copier un QObject et l'héritage multiple est interdit (on peut bien sûr hériter d'un QObject + autre chose, mais pas de 2 dérivés de QObject). Ça se rapproche beaucoup au modèle d'objets du Java (mais en plus clair parce qu'il est toujours explicit qu'on manipule des pointeurs, pas directement des objets).
* les objets implicitly shared: ce sont les classes de données, ce sont donc des types de données de première classe, tout comme int, et peuvent s'utiliser de la même manière, sans se soucier du fait qu'il s'agit en réalité de classes, sauf qu'on peut appeler des méthodes de ces classes.

vive les langages de plus haut niveau tel que le Java ou le Python ou ces problèmes ne se posent pas...

En Java et Python tu as des chaînes de caractères immutables, c'est beaucoup moins pratique que l'implicitly shared. Le système de Qt te donne les mêmes avantages de performance (pas de copies inutiles) sans les limitations d'utilisation (qui se traduisent souvent par d'autres problèmes de performance, par exemple faire des concaténations de chaînes de caractères Java, ça rame!) qui vont avec.

Et si tu veux absolument des chaînes immutables, rien ne t'empêche de travailler avec des const QString, ça te donne essentiellement le même effet.

JackosKing (./51) :
et on se retrouve avec des gens qui dérivent un carré d'un rectangle .

Je ne vois rien de "triso" là, un carré est un rectangle... C'est l'inverse qui serait absurde (et pourtant ça se voit: "tiens, on a déjà le concept de longeur dans le carré, rajoutant un champ largueur et ça devient un rectangle"... mais du coup, quand on regarde le polymorphisme résultant, un rectangle serait un carré!?).

Ne peut-on pas résoudre le problème avec du copy on write ici aussi?
Carre c(4); // crée un objet Carre qui contient un CarrePrivate *
Rectangle r = c; // r est un Rectangle qui contient un RectanglePrivate * qui pointe sur CarrePrivate *
r.setWidth(3); // le RectanglePrivate est copié et modifié et Rectangle pointe maintenant sur un vrai RectanglePrivate et plus le CarrePrivate
c.setWidth(3); // error: Carre::setWidth(int) is private (c'est aussi simple que ça de supprimer une méthode d'une classe de base)