Discussion :

[haraelendil]

Bonjours,

Voila mon petit problème:
je suis en train de ma faire une petite classe String qui sert juste à rajouter des fonctionnalités à la classe std::string pour que ça soit plus pratique à utiliser.

Donc au début je me suis dit que le plus simple pour pas avoir à retaper les méthodes déjà existantes avec std::string serait que ma classe String hérite de std::string.

Hors, après compilation, j'ai toute un flopée de warnings:

warning: will never be executed

qui renvoient tous sur le destructeur de basic_string:

Code :

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

1
2
      ~basic_string()
      { _M_rep()->_M_dispose(this->get_allocator()); }

Donc je me suis dit qu'il n'était peut-être pas bon d'hériter un std::string.
Est-ce que cela est un fait connu ou y a pas de problèmes à priori? (déjà le destructeur est pas virtuel, c'est peut-être pas bon signe).

Enfin, en attendant, je me suis dit que j'allais mettre ma string en membre de ma classe String plutôt que d'en hériter, mais les warnings sont toujours la...

Quelqu'un a une idée de ce qui pourrait se passer?


voici le code de la version encapsulée:
string.hpp

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
17
18
19
20
21
22
23
24
25
26
27
28
#ifndef __STRING_HPP__
#define __STRING_HPP__
 
#include <string>
#include <iostream>
 
class String
{
    public:
        String();
        String(char* chain);
        String(const char* chain);
 
        //convenience operators
        String& operator<<(double d);
        String& operator<<(const String& str);
 
        String& operator+(double d);
        String& operator+(char* chain);
        String& operator+(const String& str);
 
        friend std::ostream& operator<<(std::ostream& o, const String& str);
 
    protected:
        std::string innerString;
};
 
#endif // __STRING_HPP__

string.cpp

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
#include <core/String>
#include <sstream>
 
using namespace std;
 
String::String()
{}
 
String::String(char* chain): innerString(chain)
{}
 
String::String(const char* chain): innerString(chain)
{}
 
String& String::operator<<(double d)
{
    std::ostringstream oss;
    oss << d;
    innerString.append(oss.str());
    return *this;
}
 
String& String::operator<<(const String& str)
{
    innerString.append(str.innerString);
    return *this;
}
 
String& String::operator+(double d)
{
    std::ostringstream oss;
    oss << d;
    innerString.append(oss.str());
    return *this;
}
 
String& String::operator+(char* chaine)
{
    innerString.append(chaine);
    return *this;
}
 
String& String::operator+(const String& str)
{
    innerString.append(str.innerString);
    return *this;
}
 
ostream& operator<<(ostream& o, const String& str)
{
    o << str.innerString;
    return o;
}

PS: je développe sous CodeBlocks avec MinGW

[ElGat0]

Le compilateur te dit ça parce qu'effectivement le destructeur n'est pas virtuel...parce que cette classe n'est PAS destinée à être dérivée.


Je ne comprends pas trop les fonctionnalités que tu souhaiterais ajouter, d'ailleurs...Tes surcharges d'opérateurs reviennent à faire des fonctions déjà existantes.

[haraelendil]

Bon, c'est bien ce que je me disais, mais dans ce cas, pourquoi le problème persiste dans la version encapsulée?

Après je n'ai pour le moment codé que des opérateurs basiques, j'ai d'autres idées en tête mais je préfèrerais déjà me débarrasser de ces warnings avant d'aller plus loin...

[Arzar]

Bonjour,

Bonjours,
Voila mon petit problème:
je suis en train de ma faire une petite classe String qui sert juste à rajouter des fonctionnalités à la classe std::string pour que ça soit plus pratique à utiliser.

Ce qui est probablement une très mauvaise idée.

Je te conseille de lire cet article assez fun qui développe plus en détail les raisons pour lesquelles on déconseille de le faire.
La conclusion de l'article est qu'il vaut mieux utiliser des fonctions libres en C++ pour rajouter des fonctionnalités aux conteneurs standards.

C'est en tout cas l'approche retenue par Boost.StringAlgo (voir ici pour un aperçu des fonctions libres proposées par boost.stringalgo)

[haraelendil]

oui ça je me suis douté que c'était une mauvaise idée de dériver string, mais si c'est une classe qui encapsule une string, comme ici ma 2e version, c'est sensé revenir au même qu'une batterie de fonctions.

Je vais jeter un œil voir ce qu'ils ont fait chez boost

[Invité]

Bonjour,
Je crois que std::string est une classe un peu particulière, ce qui fait qu'il faut éviter de créer une classe qui en hérite.
Par contre, vous pouvez créer une classe CHAINE qui contienne des membres privés de type string, donc profiter de la classe string en utilisant ses possibilités sans faire un héritage.
Petit exemple

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class CHAINE
{
  string Str1,Str2,Str3;
public:
  CHAINE(string str1, string str2, string str3)
  {
    Str1=str1;
    Str2=str2;
    Str3=str3;
  }
  string Moyenne();
};

Sauf si vous rajoutez des membres tableaux, il n'est pas nécessaire de faire un destructeur explicite, en tout cas, je crois.
Ne me dites as que la moyenne de 3 string n'a pas de sens, ce n'est qu'un exemple.

[nikko34]

Sinon des fonctions libres dans un namespace, ça marche aussi très bien.

En fait c'est ce qui est conseillé. Par des gens bien, sisi. Mais après hein, vous faites comme vous voulez, nous on donne juste des conseils.

Perso avec la librairie standard et boost j'ai jamais senti le besoin de faire des fonctions libres pour ajouter des fonctionalités manquante.

[haraelendil]

Oui c'est juste pour donner une impression de classe unie que j'avais fait ça sous forme d'une classe, mais j'avoue que maintenant je ne compte plus vraiment l'utiliser, mais c'est surtout pour comprendre d'où vient le problème.
Parce que maintenant avec une string encapsulée (cf code du premier post), on est d'accord qu'il ne devrait pu y avoir de problème, alors pourquoi j'ai toujours autant de warnings?^^

[JulienDuSud]

Oui c'est juste pour donner une impression de classe unie que j'avais fait ça sous forme d'une classe, mais j'avoue que maintenant je ne compte plus vraiment l'utiliser, mais c'est surtout pour comprendre d'où vient le problème.
Parce que maintenant avec une string encapsulée (cf code du premier post), on est d'accord qu'il ne devrait pu y avoir de problème, alors pourquoi j'ai toujours autant de warnings?^^

Quel compilateur utilises-tu, et quels warnings as-tu ?

avec GCC 4.5, avec cette commande de compilation, je n'ai aucun warning sur le code que tu montres:

Code :

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

g++ -Wall -pedantic -ansi

[haraelendil]

Oh ba ouai, j'ai juste supprimé mon projet codeblock et je l'ai recréé, en rajoutant les mêmes fichiers, j'ai pu d'erreurs maintenant, pourtant j'ai nettoyé et recompilé plusieurs fois, il garde des paramètres en mémoire ou quoi?^^

Enfin, désolé pour tout ça, au final y avait pas de problème lol

[gl]

Hors, après compilation, j'ai toute un flopée de warnings:

warning: will never be executed

...

Enfin, en attendant, je me suis dit que j'allais mettre ma string en membre de ma classe String plutôt que d'en hériter, mais les warnings sont toujours la...

...
PS: je développe sous CodeBlocks avec MinGW

Quel version de gcc ? Si c'est la version 4.4.1 (celle fournie avec Code::Blocks 10.05), le problème vient probablement de là, il y a un bug connu sur la gestion de l'option -Wunreachable-code dans cette version (cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42476)

Oh ba ouai, j'ai juste supprimé mon projet codeblock et je l'ai recréé, en rajoutant les mêmes fichiers, j'ai pu d'erreurs maintenant, pourtant j'ai nettoyé et recompilé plusieurs fois, il garde des paramètres en mémoire ou quoi?^^

Je pense surtout que tu n'utilises pas les mêmes options de compilation dans les deux projets.