Petits warnings apres compilation sous Solaris

Hello tout le monde, lorsque j'effectue une compilation du code suivant, sous Solaris :

Code:

---

1 2 3 4 5 6 7

char* Fichier_analyse::stringtochar(std::string entree) { //CONVERTIT STRING EN CHAR size_t size = entree.size() + 1; char *buffer = new char[ size ]; strncpy( buffer, entree.c_str(), size ); return(buffer); }

---

J'obtiens le warning suivant, apres compilation :

Citation:

---

line 78: Warning: buffer hides Fichier_analyse::buffer.

---

Je crois que le "buffer" créé dans la méthode est susceptible de rentrer en conflit avec le buffer créé dans la classe Fichier_analyse.

Est-ce effectivement le cas ?

Non, il indique simplement que ta variable locale cache ta variable de classe.

Et comme cette fonction ne semble avoir aucun besoin des variables de classe, je pense que tu as deux solutions:

1. Sortie ta fonction de la classe
2. La déclarer static (si ça ne corrige pas le warning, il faudra quand même changer le nom de variable)

Citation:

---

Envoyé par Médinoc

Et comme cette fonction ne semble avoir aucun besoin des variables de classe, je pense que tu as deux solutions:

1. Sortie ta fonction de la classe
2. La déclarer static (si ça ne corrige pas le warning, il faudra quand même changer le nom de variable)

---

Eh bien, justement, la méthode est indépendante de toute classe (pas de préfixe maclasse::ma_methode)

Pour la déclarer Static, je dois faire un

Code:

---

1 2 3 4

static ma_methode{ ... ... }

---

à l'extérieur de toute classe ?

Si c'est en dehors de toute classe, c'est une fonction libre normale, static sert dans une classe.

Citation:

---

Envoyé par Miles

Si c'est en dehors de toute classe, c'est une fonction libre normale, static sert dans une classe.

---

Alors je peux tout simplement rennomer le membre privé de la classe (ex : buffer -> buffer_m) ?

Edit: un joli double-post croisé...

Citation:

---

Envoyé par Thordax

Eh bien, justement, la méthode est indépendante de toute classe (pas de préfixe maclasse::ma_methode)

---

Code:

---

char* Fichier_analyse::stringtochar(std::string entree)

---

:roll:
À moins que Fichier_analyse soit un namespace et Fichier_analyse::buffer une variable globale ?
Une variable globale en C++ alors qu'on a les singletons et les variables membres static ? :sm:

Citation:

---

Envoyé par Thordax

Pour la déclarer Static, je dois faire un

Code:

---

1 2 3 4

static ma_methode{ ... ... }

---

à l'extérieur de toute classe ?

---

Non, sauf si tu veux qu'elle soit limimitée au fichier source.
(Et sorti d'une classe, je n'appelle plus cela une méthode: C'est une fonction, tout simplement.
Et j'ai déjà tord d'appeler cela une méthode, car en C++, on dit "Fonction membre"; mais "méthode" est plus court)

Citation:

---

Envoyé par Médinoc

Edit: un joli double-post croisé...

Code:

---

char* Fichier_analyse::stringtochar(std::string entree)

---

:roll:
À moins que Fichier_analyse soit un namespace et Fichier_analyse::buffer une variable globale ?
Une variable globale en C++ alors qu'on a les singletons et les variables membres static ? :sm:

---

Effectivement, si je lis mal mon code, aussi ...

Citation:

---

Non, sauf si tu veux qu'elle soit limimitée au fichier source.
(Et sorti d'une classe, je n'appelle plus cela une méthode: C'est une fonction, tout simplement.
Et j'ai déjà tord d'appeler cela une méthode, car en C++, on dit "Fonction membre"; mais "méthode" est plus court)

---

Donc, je dois la créer statique dans une classe ?

Ou en faire une fonction hors-classe non-static.

Oui, si elle a un rapport avec une classe. Si elle n'a aucune rapport avec aucune classe, c'est une fonction libre dans un namespace, c'est tout.

Merci pour vos réponses, ca marche nickel ;)

Ah, et autre situation ! J'ai le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

std::vector<int> SDU::cherche_PDU(int &index_PDU) {//RETOURNE LA POSITION DE LA TRAME PDU EN PREMIER ELEMENT // ET LA TAILLE DE LA TRAME EN DEUXIEME ELEMENT   std::vector<int> resultat; int index_PDU_fin = contenu_SDU.find("E14D", 2*index_PDU+2);   index_PDU_fin /= 2; resultat.push_back(index_PDU); resultat.push_back(index_PDU_fin - index_PDU); index_PDU = index_PDU_fin; return resultat;}

---

le compilo me retourne :

Citation:

---

line 212: Warning: index_PDU hides SDU::index_PDU.

---

Mais ici index_PDU est passé comme référence (ajout du "&"). Le warning est-il valable ?

Ben, tant que tu auras des paramètres/variables locales du même nom que tes variables membres, tu auras des warnings.

Une chose courante pour éviter ce genre de problème, c'est de toujours préfixer les noms des variables membres (la convention Microsoft, par exemple, c'est "m_" : m_index_PDU, m_contenu_SDU, etc.).

Citation:

---

Envoyé par Médinoc

Ben, tant que tu auras des paramètres/variables locales du même nom que tes variables membres, tu auras des warnings.

Une chose courante pour éviter ce genre de problème, c'est de toujours préfixer les noms des variables membres (la convention Microsoft, par exemple, c'est "m_" : m_index_PDU, m_contenu_SDU, etc.).

---

En l'occurence, le passage par référence du paramètre fait que j'appelle un membre privé de la classe, que je modifie par la méthode de cette classe.

Le fait de renommer index_PDU en m_index_PDU me forcera aussi a changer le &index_PDU en &m_index_PDU, non ?

Pas du tout.
Mais :

1. Es-tu sûr d'en avoir besoin ?
   Normalement, pour appeler une fonction d'un objet, on n'a pas besoin de lui passer par référence une de ses propres variables membres... Ou bien, c'est pour une autre instance ?
2. Il faudra que tu changes le nom lors de l'APPEL de ta fonction membre.

Conclusion: Montre-moi dans quelles circonstances tu appelles ta fonction.

Je prends un exemple concret.
Je génere la classe suivante :

Code:

---

1 2 3 4 5

class SDU{ private : int m_index_PDU; public : std::string getPDU(int &index_PDU);};

---

et la méthode getPDU :

Code:

---

1 2 3 4 5 6

std::string SDU::getPDU(int &index_PDU) { std::vector<int> carac = SDU::cherche_PDU(index_PDU); std::string PDU = getBuffer(carac[0], carac[1]); return PDU; }

---

avec les deux méthodes cherche_PDU et getbuffer :

Code:

---

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

std::vector<int> SDU::cherche_PDU(int &index_PDU) {std::vector<int> resultat; int index_PDU_fin = contenu_SDU.find("E14D", 2*index_PDU+2); index_PDU_fin /= 2; resultat.push_back(index_PDU); resultat.push_back(index_PDU_fin - index_PDU); index_PDU = index_PDU_fin; return resultat;}   std::string SDU::getBuffer(int index, int length){ std::string contenu = contenu_SDU.substr(2*index,2*length); return contenu; }

---

Si, dans le main, je créé un objet associé a ma classe SDU, et que j'utilise la méthode getPDU de la manière suivante :

Code:

---

1 2 3 4

SDU trame_SDU; int temp_PDU = index_SDU; //index_SDU déclare precedemment string trame_atraiter = trame_SDU.getPDU(temp_PDU);

---

Comment le compilo va-t-il comprendre que temp_PDU (déclaré dans le main) est associé au membre privé m_index_PDU si, dans la méthode get_PDU je mets en référence : &index_PDU ?

Ai-je mal compris ?

Là, m_index_PDU n'est pas du tout utilisé...

Ce qui est une bonne chose: là, tu passes par un paramètre externe (temp_PDU) ce qui rend tes fonctions membres réentrantes.
D'ailleurs, ainsi, tu peux les déclarer const...

1/ Effectivement m_index_PDU n'est pas signalé dans la méthode de la classe, mais si je modifie la référence &index_PDU en &m_index_PDU, le warning associé au probleme des membres cachés par les éléments des méthodes apparait.

2/ Tu entends quoi par réentrantes ? On peut effectivement l'utiliser avec un nouveau paramètre qui se servira du membre privé de la classe ...

3/ A quoi cela sert il de passer les méthodes en const ?

1. Ça ne sert à rien d'appeler un paramètre comme une variable membre quand ladite variable n'est pas utilisée... On dirait que tu cherches ) à embrouiller le lecteur (y compris toi-même)...
2. Oui, on peut l'utiliser avec un nouveau paramètre, et même en multithread.
   D'une manière générale, c'est mal d'utiliser une variable membre pour la lecture d'un objet.
   Regarde les listes de MFC, elles utilisent un type POSITION passé par référence, et les listes standard utilisent des iterator, plutôt que de laisser la liste mémoriser elle-même où tu en es...
3. À montrer que la méthode ne modifie pas l'objet, ce qui permet par exemple de passer à une fonction un pointeur const vers l'objet...

Petite question, maintenant que les plus gros problèmes ont été résolus. C'est quoi l'intérêt du stringtochar() ?
- Si c'est pour obtenir un pointeur sur (const) char vers un buffer zéro-terminé (ou non) que tu n'altèrera pas, tu as std::string::c_str() (ou std::strig::data())
- Si c'est pour obtenir un pointeur sur char vers un buffer modifiable (tu as le new + std::string::copy ou strncpy effectivement), mais attention que ton buffer modifiable n'est modifiable qu'en contenu et non en longueur ; et qu'à faire des new à la main, il y a des risques de fuites de mémoire). L'intérêt me parait assez limité.
- Si c'est pour utiliser une API C mal codée (/ancienne) qui attend un pointeur sur char vers un buffer qui ne sera jamais modifié par la fonction, alors ce doit être un des rares cas où le const_cast sur le c_str() est acceptable. Rendre l'API const-correcte est la solution à priviliéger quand on peut la modifier.

Citation:

---

Envoyé par Luc Hermitte

Petite question, maintenant que les plus gros problèmes ont été résolus. C'est quoi l'intérêt du stringtochar() ?
- Si c'est pour obtenir un pointeur sur (const) char vers un buffer zéro-terminé (ou non) que tu n'altèrera pas, tu as std::string::c_str() (ou std::strig::data())
- Si c'est pour obtenir un pointeur sur char vers un buffer modifiable (tu as le new + std::string::copy ou strncpy effectivement), mais attention que ton buffer modifiable n'est modifiable qu'en contenu et non en longueur ; et qu'à faire des new à la main, il y a des risques de fuites de mémoire). L'intérêt me parait assez limité.
- Si c'est pour utiliser une API C mal codée (/ancienne) qui attend un pointeur sur char vers un buffer qui ne sera jamais modifié par la fonction, alors ce doit être un des rares cas où le const_cast sur le c_str() est acceptable. Rendre l'API const-correcte est la solution à priviliéger quand on peut la modifier.

---

Je ne pourrai pas te dire directement s'il s'agit du premier, du deuxieme ou du troisieme cas cité.

Je me sers de stringtochar dans le cas suivant par exemple :

Code:

---

1 2	char *nom = Fichier_analyse().stringtochar(fichier_sortie); std::ofstream fileC(nom, std::ios_base::app);

---

Ceci dit, le problème a été résolu, car le passage par référence n'était pas nécessaire.

Merci encore !

Oh la vilaine fuite de mémoire.
Cas 1! Utilise c_str()!

Merci pour l'info, je corrige de ce pas ;)