Discussion :

[karnivor]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[gbdivers]

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

[karnivor]

Ca sent le développeur Java

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

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é

En tout cas merci beaucoup pour ta réponse rapide

[gbdivers]

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

[koala01]

Salut,

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

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

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

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

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

[gbdivers]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[karnivor]

Salut 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
private:
    QPushButton *bouton;

Et dans le .cpp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[koala01]

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 ?

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
QString FenetreAttribut::getCodeA() const
{
    if (m_codeA)
        return QString();
    else
        return *m_codeA;
}

voir, plutot

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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"

[koala01]

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
private:
    QPushButton *bouton;

Et dans le .cpp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 )

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

Ou alors effectivement j'ai rien compris

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 ) 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 )

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

[karnivor]

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

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

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

[gbdivers]

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

Je confirme que non

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

Lire "sémantique de valeur"

[koala01]

Je confirme que non

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

Lire "sémantique de valeur"

Je corrige, ce sera mieux

[gbdivers]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (!m_codeA)

koala01 pour avoir copié mes bétises

[koala01]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (!m_codeA)

koala01 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