Kevin> Je ne connais pas le partage implicite de Qt donc je ne pourrai pas faire de commentaire, désolé. Mais je vais me documenter.
A propos du vector je suis d'accord, et c'est toujours la merde de retourner ce type d'objets dans d'autres langages. Par contre conceptuellement ça marche bien avec les tableaux natifs.

Aze>
1) Parce que l'application qui utilise ta classe ne devrait pas avoir besoin de toutes les infos de l'objet, qui sont privées justement. Mais le souci c'est que tu exposes trop l'implémentation sous-jacente. Si tu devais changer ton code pour utiliser un autre type d'objet en interne (par exemple une table de hachage plutôt qu'un dictionnaire, ou un objet provenant d'une autre librairie dont les conventions de nommage changent légèrement), tu vas casser tous les programmes qui utilisent ta classe... et dans un bon prog objet c'est à éviter.
2) const objet& en C++ ça ressemble mais c'est différent d'un objet immuable, puisqu'en C++ tu peux avoir un objet conçu comme muable (qui peut évoluer) que tu "figes" avec le mot const, et du coup tu restreins son champ d'action.
Je suis mal placé pour aller à l'encontre, c'est un concept que j'aime bien et que j'utilise, sauf que ça implique beaucoup de choses lourdes pour le codeur. Les objets immuables, bien que moins performants dans certains cas, sont plus naturels d'un point de vue OO et n'ont pas besoin d'avoir 500 concepts associés: il suffit de déclarer "final class" pour avoir automatiquement toute la sécurité autour.