Faire cohabiter wxString et std::string

Le
Fabien LE LEZ
Bonjour,

Il semble que faire cohabiter dans un même projet une bibliothèque
utilisant std::string et une autre utilisant une autre classe "chaîne"
(par exemple, wxWidgets qui utilise sa propre classe wxString) soit
courant.
Mais quelle est la meilleure méthode pour faire ça sans douleur ?

Note : je suppose qu'on a déjà des fonctions de conversion explicite
std::string W2S (wxString const&);
wxString S2W (std::string const&);
(Elles sont assez simples à implémenter de toutes façons).

Par exemple, si on a une fonction

void g (std::string const&);

et une variable wxs de classe wxString, comment passer ce wxs à g ?
Faut-il écrire explicitement à chaque fois g (W2S (wxs)); ?

Vaut-il mieux faire un wrapper "une fois pour toutes", mais pour
chaque fonction ?
void g (wxString const& w) { g (W2S (w)); }
Solution certes élégante, mais passablement fastidieuse si on a 132
fonctions de ce style

De plus, comment faire quand la fonction g est le constructeur d'une
classe ?

class C
{
public: C (std::string const&);
};

i.e. comment construire (élégamment) un objet de classe C à partir
d'un wxString ?

Y a-t-il des outils qui sont capables de pondre automatiquement de
tels wrappers ?

Merci d'avance pour vos idées, suggestions et expériences


--
schtroumpf schtroumpf
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Luc Hermitte
Le #776937
Fabien LE LEZ news::

Merci d'avance pour vos idées, suggestions et expériences...


A l'install, j'avais vu des options qui permettaient de faire en sorte
que la classe de wxWidget descende de std::string.

Je n'ai par contre pas encore eu le temps de m'y plonger sérieusement.

Sinon, j'étais tombé sur une réflexion & solution générale au problème
des bibliothèques différentes qui définissent le même genre de types, par
le gars qui s'occupe de STLsoft, probablement dans ses articles sur CUJ
(efficient integer to string convertions).

HTH,

--
Luc Hermitte FAQ de Dejanews :
Fabien LE LEZ
Le #772204
On Fri, 02 Jul 2004 00:28:05 +0200, Luc Hermitte

A l'install, j'avais vu des options qui permettaient de faire en sorte
que la classe de wxWidget descende de std::string.


Je crois bien qu'ici même on m'avait déconseillé de dériver de
std::vector<>, à cause de l'absence de destructeur virtuel. L'argument
ne vaut pas pour std::string ?


--
schtroumpf schtroumpf

Luc Hermitte
Le #794894
Fabien LE LEZ news::

On Fri, 02 Jul 2004 00:28:05 +0200, Luc Hermitte

A l'install, j'avais vu des options qui permettaient de faire en sorte
que la classe de wxWidget descende de std::string.


Je crois bien qu'ici même on m'avait déconseillé de dériver de
std::vector<>, à cause de l'absence de destructeur virtuel. L'argument
ne vaut pas pour std::string ?


Oui et non.
Pour le destructeur, il faut savoir qu'il ne faudra jamais écrire :
std::string * s = new wxString("toto");
Déjà en ce qui me concerne gérer dynamiquement (std::string * ps =
new...) une std::string est limite une hérésie.

Ensuite, il reste le problème qu'il ne faut pas masquer des fonctions
héritées. On pourrait croire qu'elles soient redéfinies, mais non. Tout
ce que l'on peut faire, c'est les masquer.
Il faudrait que je revois le code de wxString, je ne sais plus si ils
font ce genre de choses ou non. Dans mes souvenirs, ce n'est pas le cas.

Ce genre de problème se poserait plutôt si on tentait de dériver
publiquement les vecteurs histoire de les spécialiser pour la
manipulation de pointeurs bruts.



--
Luc Hermitte FAQ de Dejanews :

Fabien LE LEZ
Le #809275
On Tue, 03 Aug 2004 15:58:39 +0200, Luc Hermitte

Déjà en ce qui me concerne gérer dynamiquement (std::string * ps =
new...) une std::string est limite une hérésie.


En général, oui -- car std::string a sans conteste une sémantique de
valeur.
Mais justement, le but ici est de dériver std::string, et d'utiliser
le polymorphisme d'héritage, pour pouvoir mélanger allègrement
std::string et machinString sans bouger les oreilles. De là à
l'allocation dynamique, il n'y a qu'un pas...


--
;-)

Fabien LE LEZ
Le #809274
On Thu, 01 Jul 2004 22:00:40 +0200, Fabien LE LEZ

Il semble que faire cohabiter dans un même projet une bibliothèque
utilisant std::string et une autre utilisant une autre classe "chaîne"
(par exemple, wxWidgets qui utilise sa propre classe wxString) soit
courant.
Mais quelle est la meilleure méthode pour faire ça sans douleur ?


Que penser de la méthode toute simple qui consiste à utiliser partout
dans mon code, une classe MyString du style

class MyString
{
public:
MyString (wxString const&);
operator wxString& ();
operator wxString const& () const;
MyString (std::string const&);
operator std::string& ();
operator std::string const& () const;
};

?

--
;-)

Luc Hermitte
Le #797590
Salut,

Fabien LE LEZ news::

Il semble que faire cohabiter dans un même projet une bibliothèque
utilisant std::string et une autre utilisant une autre classe "chaîne"
(par exemple, wxWidgets qui utilise sa propre classe wxString) soit
courant. Mais quelle est la meilleure méthode pour faire ça sans
douleur ?


Que penser de la méthode toute simple qui consiste à utiliser partout
dans mon code, une classe MyString du style


Pas du bien.

class MyString
{
public:
MyString (wxString const&);
operator wxString& ();
operator wxString const& () const;
MyString (std::string const&);
operator std::string& ();
operator std::string const& () const;
};


std::string & s = tastring;
s += "toto";
assert(match(tastring, "toto$"));


Je pense que dans ce cas (wxstring et std::string) vu le lien possible
(héritage) entre les deux depuis les versions "récentes" de wxWidgets,
c'est se compliquer la vie pour rien.

Sinon de mémoire, le mainteneur de STLSoft (il a écrit divers articles
pour le C/C++ Users Journal) a proposé tout un arsenal de trucs qui
s'apparentent vaguement à des proxies, et permettent de faire dialoguer
se qui provient de la bibliothèque standard du C++ avec divers frameworks
dont les MFC. Je pense que les mécanismes mis en oeuvre sont extensibles
à wxWidget.

--
Luc Hermitte FAQ de Dejanews :

Poster une réponse
Anonyme