Discussion :

[poukill]

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

[ram-0000]

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

[poukill]

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

[ram-0000]

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.

[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 !

[ram-0000]

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.

[Médinoc]

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 !

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