Compilation et link Unicode

Bonjour à tous,

J'aurai aimé un peu plus d'explications sur la compilation avec ou sans Unicode. Par exemple, WxWidget propose un tas de mode de compilation différent parmi les suivants :

• Release
• Release DLL
• Release Unicode
• Release DLL Unicode
• etc....

Au final, à part la CRT, qu'est-ce que ça change? Est-ce que plusieurs bibliothèques avec des modes de compilation différents, ça pose problème pour la compilation? Pour l'édition des liens?

Je sais jamais quel mode choisir, je constate juste que certains sont compatibles avec le reste de mon appli, mais sans vraiment comprendre pourquoi, donc... :aie:
En gros, c'est mieux, moins bien? Plus compatible, plus portable? Parce que les std::wstring c'est chiant à la longue...
Je vous remercie pour toute aide qui éclairerait ma lanterne...

:merci:

D'après ce que tu dis, je comprends que WxWidget peut se linker de plusieurs manières :

- Link statique avec un gros .lib WxWidget
- Link dynamique avec un plus petit .lib WxWidget et une (ou plusieurs DLL) WxWidget nécessaires au fonctionnement
- Link en mode Unicode
- Link en mode Multi Bytes (non unicode).

Unicode est maintenant le mode natif pour Microsoft Windows, donc pour des raisons de performances, utilise le mode Unicode. Sinon, toutes tes strings Multi Byte devront être transformées par le système en Unicode lors des appels systèmes (avec une baisse de performances à la clé)

Après le mode DLL ou link statique pour WxWidget, c'est un choix personnel.

En mode Link dynamique, ton appli est plus petite mais tu dois installer et peut être enregistrer ces DLL lors de l'installation. La mise à jour de WxWidget se fait simlplement en remplacant les DLL.

En mode Link statique, ton binaire est plus gros (beaucoup plus gros ?) mais par contre, tu es indépendant de l'install de WxWidget. Tu es sûr que tu ne sera pas embêté avec.

Le mode Link dynamique (avec DLL) me semble plus dans la philosophie Windows mais c'est une question de goût, donc cela ne se discute pas :)

D'accord, je savais pas que pour Windows c'était le mode par "défaut".

Merci beaucoup pour ton explication, c'est bien plus clair pour moi à présent.
Bonne continuation,

Poukill

Citation:

---

Envoyé par poukill

D'accord, je savais pas que pour Windows c'était le mode par "défaut".

---

Je ne dirais par "par défaut" mais plutôt "natif".

Un mode "par défaut" peut se modifier/changer alors qu'un mode "natif" ne peut pas se changer.

Euh je viens de réfléchir plus longuement... Ça veut dire qu'il faut que j'utilise dans tout mon projet (30 000 lignes) des std::wstring à la place des std::string, etc... ?
Si c'est le cas, non merci ! :aie: :aie:

Effectivement, ce n'est pas facile de passer un projet conséquent d'un mode à l'autre (Unicode vers Multi bytes ou l'inverse), il faut tout revalider.

Je pense que le mode (Unicode ou Multi bytes) est un choix à prendre à la création du projet. Ce choix est ensuite difficile (mais pas impossible) à remettre en cause.

Citation:

---

Envoyé par poukill

Euh je viens de réfléchir plus longuement... Ça veut dire qu'il faut que j'utilise dans tout mon projet (30 000 lignes) des std::wstring à la place des std::string, etc... ?
Si c'est le cas, non merci ! :aie: :aie:

---

Sous Windows, je conseillerais plutôt des std::basic_string< TCHAR > (ou du moins un typedef dessus), car ça permet de passer assez facilement du multi-byte à l'Unicode et inversement.

Ou bien, tout développer en unicode dès le début...

Ok merci à tous. Du coup j'hésite, transformer en wide quand j'en ai besoin avec: (FAQ C++)

Code:

---

1 2 3 4 5 6 7 8

std::wstring widen(const std::string& s) { std::wstring res(s); // Ne compile pas Erreur ICI std::locale loc("english"); std::use_facet< std::ctype<wchar_t> >(loc).widen(&s[0], &s[s.length()], &res[0]);   return res; }

---

ou bien tout mettre en unicode... :koi:

Questions :

1. La gestion des fichiers ne pose pas de problèmes en Unicode?
2. Unix supporte pleinement l'Unicode?

Encore merci. :king:

Au passage, ce code de la FAQ C++ ne compile pas sous Visual 2005... :?

EDIT : remettre la FAQ à jour ? ;)

Normal, &res[0] donne un pointeur const (l'opérateur [] de std::string donne une référence const, sans doute pour reproduire le fait que c_str() retourne un pointeur const).

Cela rend les std::string impossibles à modifier autrement que par les fonctions membres, comme Visual ne donne jamais un pointeur ou une référence non-const sur le contenu de la chaîne. Dommage que ce soit apparemment non-standard...

C'est pas ça qui compile pas... :aie:
Ce code compile par contre:

Code:

---

1 2 3 4 5 6 7 8

std::string narrow(const std::wstring& ws) { std::string res(ws.begin(), ws.end()); std::locale loc("english"); std::use_facet< std::ctype<wchar_t> >(loc).narrow(&ws[0], &ws[ws.length()], '?', &res[0]);   return res; }

---

Bon j'ai passé tout mon code en unicode....:pan:
(une bonne chose de faite)... Par contre, je rencontre depuis d'autres problèmes...
Genre les std::wcout par exemple. Ce code ne fonctionne plus:

Code:

---

1 2	m_text=new wxTextCtrl(this,-1, wxT(""),wxDefaultPosition,wxDefaultSize,wxHSCROLL|wxTE_MULTILINE|wxTE_READONLY|wxTE_RICH|wxTE_NOHIDESEL ); std::cout.rdbuf(m_text);

---

et celui là ne compile pas:

Code:

---

1 2 3

m_text=new wxTextCtrl(this,-1, wxT(""),wxDefaultPosition,wxDefaultSize,wxHSCROLL|wxTE_MULTILINE|wxTE_READONLY|wxTE_RICH|wxTE_NOHIDESEL ); std::wcout.rdbuf(m_text);

---

Ce qui est dommage quand on est en unicode... :aie:

Une idée? :koi:

Bizarre, il me semble pourtant que wcout marche sous Visual... (contrairement à MinGW).

Oui std::wcout marche, mais là c'est pas Visual.... Je pense que c'est WxWiget...:aie:

Citation:

---

MainFrame.cpp
.\frames\MainFrame.cpp(91) : error C2664: 'std::basic_streambuf<_Elem,_Traits> *std::basic_ios<_Elem,_Traits>::rdbuf(std::basic_streambuf<_Elem,_Traits> *)' : impossible de convertir le paramètre 1 de 'wxTextCtrl *' en 'std::basic_streambuf<_Elem,_Traits> *'
with
[
_Elem=wchar_t,
_Traits=std::char_traits
]
Les types pointés n'ont aucun rapport entre eux ; conversion nécessitant reinterpret_cast, cast de style C ou cast de style fonction

---

Peux-tu poster la déclaration de la classe WxTextCtrl quand tu compiles en unicode?
Surtout ses opérateurs de conversion...

Les surcharges d'insertions de flux :

Code:

---

1 2 3 4 5 6

wxTextCtrl& operator<<(const wxString& s); wxTextCtrl& operator<<(int i); wxTextCtrl& operator<<(long i); wxTextCtrl& operator<<(float f); wxTextCtrl& operator<<(double d); wxTextCtrl& operator<<(const wxChar c);

---

La class wxTextCtrl est une frame contenant du texte...

Citation:

---

wxTextCtrl::wxTextCtrl ( wxWindow * parent,
wxWindowID id,
const wxString & value = "",
const wxPoint & pos = wxDefaultPosition,
const wxSize & size = wxDefaultSize,
long style = 0,
const wxValidator & validator = wxDefaultValidator,
const wxString & name = wxTextCtrlNameStr
)

Constructor, creating and showing a text control.

Parameters:
parent Parent window. Should not be NULL.
id Control identifier. A value of -1 denotes a default value.
value Default text value.
pos Text control position.
size Text control size.
style Window style. See wxTextCtrl.
validator Window validator.
name Window name.

---

Bon vu tous les problèmes que j'ai avec l'unicode, je crois que je vais revenir à l'ancienne version.... :aie:

Je parlais surtout d'opérateur de conversion vers std::basic_streambuf< ? >...
À moins que la classe elle-même hérite de streambuf...

Je crois qu'elle hérite.... je vais vérifier.

Effectivement, il y a bien héritage:

Code:

---

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

class WXDLLEXPORT wxTextCtrlBase : public wxControl #if wxHAS_TEXT_WINDOW_STREAM , public wxSTD streambuf #endif   { public: // creation // --------   wxTextCtrlBase(){} virtual ~wxTextCtrlBase(){}   // accessors // --------- ...

---

Avec un

Code:

---

#define wxSTD std::

---

Ca devrait être OK non ?

Ben non c'est pas OK, car apparemment wxTextCtrlBase est uniquement non-wide, et hérite seulement de basic_streambuf< char >.
Tu ne peux donc pas utiliser cela sur un wostream. Le problème vient bel et bien de WxWidgets...