Problème de conversion 'QString *' en 'QChar'

Bonjour à tous,

Voilà je suis en train de développer une application et au moment de compiler je reçois une erreur que je ne comprends pas :
"C2664: 'QString::QString(QChar)' impossible de convertir le paramètre 1 de 'QString *' en 'QChar'.

Et donc voici le code qui provoque cette erreur :

FenetreAttribut.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#ifndef FENETREATTRIBUT_H #define FENETREATTRIBUT_H   #include <QtGui>   class FenetreAttribut { public: FenetreAttribut(); QString getCodeA() const;   private: QString *m_codeA; };   #endif // FENETREATTRIBUT_H

---

FenetreAttribut.cpp

Code:

---

1 2 3 4 5 6 7 8 9

FenetreAttribut::FenetreAttribut() { m_codeA = new QString; }   QString FenetreAttribut::getCodeA() const { return m_codeA; }

---

Pourquoi est-ce que mon accesseur provoque une erreur de conversion ? J'ai bien l'impression de n'utiliser que QString et aucun QChar.

Je code sous Qt Creator.
Merci d'avance.

Bonjour

Ca sent le développeur Java :) Pourquoi utiliser un pointeur ?
En tout cas, avoir une erreur est normal, tu essaies de passer un QString* dans un QString
Et même si Qt utilise le COW, prendre l'habitude de renvoyer une référence constante (ou même ne pas faire d'accesseur...) est une bonne chose

Citation:

---

Envoyé par gbdivers

Ca sent le développeur Java :)

---

Euh nan désolé je ne me suis pas encore lancé dans Java :mrgreen:

Je déclare tout ceci de cette façon (avec pointeur) car je l'ai appris comme ça en cours...

Mais en effet en se passant du pointeur ça fonctionne également je n'avais pas vraiment essayé :oops:

En tout cas merci beaucoup pour ta réponse rapide :ccool:

Citation:

---

Envoyé par karnivor

car je l'ai appris comme ça en cours...

---

A utiliser des pointeurs quand c'est pas nécessaire ? (c'est à dire la plus part du temps en C++ moderne ?) Change de cours... ou passe à l'auto-formation

Salut,

Citation:

---

Envoyé par karnivor

Je déclare tout ceci de cette façon (avec pointeur) car je l'ai appris comme ça en cours...

---

Quel :furieux: a donc bien pu t'apprendre en cours à déclarer tous tes membres sous la forme de pointeur :question:

Cela parait tellement incongru que je pencherais beaucoup plus volontiers pour une très mauvaise compréhension de ta part ;)

Citation:

---

Mais en effet en se passant du pointeur ça fonctionne également je n'avais pas vraiment essayé :oops:

---

Et c'est ce qu'il faut faire, autant que possible ;)

Ceci dit, si, vraiment, tu dois utiliser un pointeur pour ton membre, et que tu souhaites renvoyer non pas un pointeur mais plutot une référence (pour éviter les copies inutiles), de préférence constante, tu peux toujours renvoyer "ce qui est pointé" par ton pointeur en le déréférençant ;)

Citation:

---

Envoyé par koala01

Ceci dit, si, vraiment, tu dois utiliser un pointeur pour ton membre, et que tu souhaites renvoyer non pas un pointeur mais plutot une référence (pour éviter les copies inutiles), de préférence constante, tu peux toujours renvoyer "ce qui est pointé" par ton pointeur en le déréférençant ;)

---

Mais euh...
Très dangereux ça je trouve. On doit toujours vérifier qu'un pointeur n'est pas nullptr avant de le déréférencer. Or si on renvoie une référence, comment l'utilisateur veut vérifier que la données est valide ?

Soit on fait la brute et on lance un exception si le pointeur est nullptr :

Code:

---

1 2 3 4 5 6 7

QString const& FenetreAttribut::getCodeA() const { if (!m_codeA) throw (std::jeFaisNImporteQuoiAvecLesPointeursException); else return *m_codeA; }

---

Soit faire comme Qt (par exemple avec QVector::Value) et renvoyer une copie si c'est valide ou T() sinon (ce qui est encore acceptable avec certaines classes de Qt qui utilisent le COW, mais pas top en général) :

Code:

---

1 2 3 4 5 6 7

QString FenetreAttribut::getCodeA() const { if (m_codeA) return QString(); else return *m_codeA; }

---

Mais dans les 2 cas, j'aime pas trop :(

Salut koala01,

Citation:

---

Envoyé par koala01

Cela parait tellement incongru que je pencherais beaucoup plus volontiers pour une très mauvaise compréhension de ta part ;)

---

Beh c'est la base non ? J'ai zyeuter un tuto en + de mon cours et je retrouve la même chose...
Dans le .h :

Code:

---

1 2	private: QPushButton *bouton;

---

Et dans le .cpp :

Code:

---

bouton = new QPushButton;

---

Je veux bien croire que ce n'est pas utilisé par les vrais développeurs mais c'est ce qu'on apprend aux débutants visiblement...
Ou alors effectivement j'ai rien compris :aie:

En fait mon but est de récupérer ce qui va être entré dans la variable m_codeA et de le réutiliser pour l'afficher dans une autre fenêtre d'où l'accesseur.
Donc au final quelle solution est la meilleure ? pointeur / pas pointeur

Citation:

---

Envoyé par gbdivers

Mais euh...
Très dangereux ça je trouve.

---

Je n'ai jamais dit que ce n'était pas dangeureux...

J'ai dit que c'est une possibilité offerte qui peut s'avérer utile dans certaines conditions ;) On doit toujours vérifier qu'un pointeur n'est pas nullptr avant de le déréférencer. Or si on renvoie une référence, comment l'utilisateur veut vérifier que la données est valide ?

Citation:

---

Soit on fait la brute et on lance un exception si le pointeur est nullptr :

Code:

---

1 2 3 4 5 6 7

QString const& FenetreAttribut::getCodeA() const { if (m_codeA) throw (std::jeFaisNImporteQuoiAvecLesPointeursException); else return *m_codeA; }

---

---

Dans certaines conditions ( si m_codeA est quelque chose qui se doit d'être défini, mais qui peut ne pas exister), cela peut etre la "moins mauvaise" solution ;)

Citation:

---

Soit faire comme Qt (par exemple avec QVector::Value) et renvoyer une copie si c'est valide ou T() sinon (ce qui est encore acceptable avec certaines classes de Qt qui utilisent le COW, mais pas top en général) :

Code:

---

1 2 3 4 5 6 7

QString FenetreAttribut::getCodeA() const { if (m_codeA) return QString(); else return *m_codeA; }

---

---

voir, plutot

Code:

---

1 2 3 4 5 6

QString FenetreAttribut::getCodeA() const { if (m_codeA) m_codeA = new QString("undefined"); // ou new QString() selon le cas return *m_codeA; }

---

que je préférerais sans doute (tout dépendant du contexte, bien sur ;))

Le fait est que, même pour une chaine de caractères, une chaine vide peut ne pas être invalide (comprends : représenter, en interne du moins, une valeur cohérente différente de "qui n'existe pas" ).

Pour une chaine de caractères, tu pourrais te passer du pointeur et définir (comme je l'ai fait avec "undefined" ) connue pour indiquer clairement que le membre ne doit pas être pris en compte parce que "inexistant".

Cependant, cela peut rapidement poser problème car:

• La comparaison d' une chaine de caractères est très lente (en tout cas, beaucoup plus lente que celle d'un simple pointeur)
• Le problème peut etre généralisé à n'importe quel type dont des types non défaut constructibles et / ou pour lequel il est impossible de définir une valeur connue pour représenter une valeur "non définie".

En attendant l'arrivée de std::optionnal et sans passer par boost::optionnal, l'utilisation d'un pointeur initialisé à NULL (ou nullptr) est l'une des rares solutions pour indiquer que quelque chose "n'existe pas" ;)

Citation:

---

Envoyé par karnivor

Salut koala01,

Beh c'est la base non ?

---

Non, la base, c'est de n'utiliser les pointeurs que lorsqu'on en a vraiment besoin ;)

Citation:

---

J'ai zyeuter un tuto en + de mon cours et je retrouve la même chose...
Dans le .h :

Code:

---

1 2	private: QPushButton *bouton;

---

Et dans le .cpp :

Code:

---

bouton = new QPushButton;

---

---

Attention, QPushButton a sémantique d'entité, et dérive en outre de QWidget.

Et c'est parce que la gestion des widgets est particulière que tu dois faire une allocation dynamique pour ton QPushButton:

Ton QPushButton va être inséré soit dans un Q(H/V/HV)Layout, soit dans le layout de ta fenêtre (si tu écrit bouton=new QPushButton(this); ) et tu dois donc passer par l'allocation dynamique parce que le pointeur sur QPushButton sera considéré comme un pointeur sur QObject et que la mécanique interne des layout va considérer qu'il a été construit de manière dynamique, et donc tenter de faire un delete dessus lorsque ta fenetre sera détruite.

Une QString, par contre, a sémantique d'entité de valeur et n'est pas directement inclue dans les layout : elle sera inclue indirectement sous la forme d'un QLabel, d'un QTextEdit ou de tout autre widget capable d'afficher une chaine de caractères ;)

Mais elle sera toujours maintenue en interne sous la forme d'une valeur et non sous la forme d'un pointeur, et sera d'ailleurs systématiquement passée sous la forme d'une référence (éventuellement constante )

Citation:

---

Je veux bien croire que ce n'est pas utilisé par les vrais développeurs mais c'est ce qu'on apprend aux débutants visiblement...

---

Ce qui se passe, c'est que tu apprend Qt avant d'avoir compris les principes inhérents au C++, ce qui est très dommageable ;)

Citation:

---

Ou alors effectivement j'ai rien compris :aie:

---

Je vais être plus gentil que toi en disant que tu n'as pas tout compris ;)

Ce qu'il faut comprendre, c'est que ton QPushButton entre dans une hiérarchie de classes relativement complexe qui dérivent toutes de manière directe ou indirecte de QWidget.

L'exemple de QPushButton fonctionnera avec toutes les classes qui dérivent de QWidget.

Seulement, QString ne dérive pas de QWidget (je ne suis même pas sur qu'elle dérive de QObject, d'ailleurs :aie:) et tu ne dois donc pas te baser sur ce que tu ferais pour un QWidget pour essayer d'en déduire ce que tu ferais pour une QString (les QVector, QList et autres QStringList sont d'ailleurs dans le même cas ;))

Citation:

---

En fait mon but est de récupérer ce qui va être entré dans la variable m_codeA et de le réutiliser pour l'afficher dans une autre fenêtre d'où l'accesseur.
Donc au final quelle solution est la meilleure ? pointeur / pas pointeur

---

Pas pointeur.

Tant que ta variable m_codeA sera dans la fenêtre "parent", il n'y aura pas de problème.

Si elle se trouve dans la fenêtre "enfant", et que tu veux la récupérer dans la fenêtre principale, tu devras veiller à l'avoir récupérée avant de perdre la référence sur la fenêtre enfant ;)

Ah oui en effet j'ai compris, tout est de ma faute. :fessee:

A force de voir des Q partout j'en est oublié que le String était différent...:whistle:

En tout cas merci beaucoup pour tes explications c'est maintenant très clair :ccool:

Citation:

---

Envoyé par koala01

je ne suis même pas sur qu'elle dérive de QObject, d'ailleurs

---

Je confirme que non

Citation:

---

Envoyé par koala01

Une QString, par contre, a sémantique d'entité

---

Lire "sémantique de valeur"

Citation:

---

Envoyé par gbdivers

Je confirme que non

---

C'est bien ce qu'il me semblait, mais j'étais pris d'un doute étrange tout autant que subit :aie:

Citation:

---

Lire "sémantique de valeur"

---

Je corrige, ce sera mieux :D

Comme me l'a fait remarqué Troudhyl, il faut lire :

Code:

---

if (!m_codeA)

---

koala01 :toutcasse: pour avoir copié mes bétises

Citation:

---

Envoyé par gbdivers

Comme me l'a fait remarqué Troudhyl, il faut lire :

Code:

---

if (!m_codeA)

---

koala01 :toutcasse: pour avoir copié mes bétises

---

Et après ca, tu t'étonneras encore que je ne me sente pas en forme pour écrire un roman dans une autre discussion :question: :D