Migration C++ Builder 6 versus C++ Builder 2009 & AnsiString

Bonjour

j'ai lu les diff�rentes contributions sur ce sujet sans toujours faire les m�mes constatations que mes pr�d�cesseurs. Je rapporte ici un cas surprenant de divergences de comportement du m�me code entre deux projets diff�rents que j�appellerai ANCIEN et NOUVEAU. la raison est que ANCIEN est un projet existant d�velopp� sous C++6 tandis que nouveau a �t� cr�� sous C++9. Les deux projets sont cependant execut�s sous C++9. L'ANCIEN a donc �t� converti automatiquement par le RAD.

Je pr�cise que j'ai bien s�r essay� de faire varier la fameuse option "Mappage du _TCHAR" sans que cela fasse varier les observations suivantes :

Prenons le code inoffensif et fonctionnel sous C++ Builder 6

Code:

---

1 2 3 4

MessageBox(Application->Handle, (Format("%s ",ARRAYOFCONST(("Toto")))).c_str(), "Erreur", MB_OK | MB_ICONERROR);

---

il ne se compile pas sous C++Builder 9 � cause du c_str(). Je le remplace donc par :

Code:

---

1 2 3 4

MessageBox(Application->Handle, (Format("%s ",ARRAYOFCONST(("Toto")))).t_str(), "Erreur", MB_OK | MB_ICONERROR);

---

La compilation passe ... mais � l�ex�cution :

le projet NOUVEAU affiche

Citation:

---

Toto

---

le projet ANCIEN affiche

Citation:

---

????

---

Je pr�sume que l'ouverture/conversion d'un projet C++6 sous C++9 entra�ne quelques choix d'options qui expliqueraient ce comportement. N�anmoins je ne vois pas lesquelles ?

Apr�s quelques recherches sur le forum je tente

Code:

---

1 2 3 4

MessageBox(Application->Handle, AnsiString().Format("%s ",ARRAYOFCONST(("Toto"))).c_str(), "Erreur", MB_OK | MB_ICONERROR);

---

qui fonctionne depuis les deux projets.

Je pense � la lecture de la doc) que la fonction Format est surcharg�e, et que par cons�quent ce n'est pas le m�me code qui est compil� dans les deux projets. Mais comment savoir quelle d�clinaison est employ�e ?

D'ordinaire la discrimination de fonctions surcharg�es se fait par les param�tres d'appel. Mais ici ce sont les m�mes. Je pense aussi � l'inclusion automatique si elle se fait sur les composants visuels, elle n'a pas lieu sur de simples fonctions m�me de classe... ?

NB : j'ai r��dit� ce message apr�s relecture car j'ai constat� apr�s une nuit de sommeil qu'il �tait incompr�hensible en l'�tat. D�sol� pour ceux qui l'ont lu avant la mise � jour...

MessageBox, quelle id�e !
O� je travailles, ils ont fait pareil par m�connaissance de l'outil C++ Builder !

Format peut importe le mappage fonctionne en String Delphi !
Donc AnsiString en D6 et UnicodeString en D2009 tout comme en XE2

Format est la fonction Delphi
AnsiString().Format est la m�thode d'encapsulation dans l'objet C++ de la fonction Delphi

Ce n'est pas une histoire de surcharge mais une question de port�e (Fonction ou M�thode) et de d'unit� (~namespace) SysUtils.pas ou dstring.h
Il existe aussi la fonction Format dans System.AnsiStrings

Le Mappage ne concerne que les API Windows (MessageBoxA en l'occurence) et le type _TCHAR ou la macro _TEXT

Deplus, t_str est la pire erreur d'Embarcadero !
Migre au plus vite en XE2 car 2009 est, je pense, � consid�rer comme la version b�ta pour l'Unicode !
t_str n'a pas v�cu longtemps, apparu en 2009 et d�pr�ci� en 2010 :mouarf::aie:
Ton code n'aura pas le m�me comportement entre 2009 et XE2 avec t_str !

Il existe une fonction pr�vu pour cela dans la RTL\VCL : MessageDlg

Code:

---

1 2 3

MessageDlg( Format("%s ", ARRAYOFCONST(("Toto"))), mtError, TMsgDlgButtons() << mbOK, 0);

---

Un conseil �vite le plus que possible d'utiliser c_str(), tu ne devrais y avoir besoin uniquement lors d'utilisation d'API Windows !
Avant v�rifie si il n'existe pas dans la RTL une encapsulation comme TIniFile ou TRegistry
Je te dis �a parce que le code que je maintiens m�lange ces objets et les API, du coup du char* et c_str() partout tr�s p�nible � maintenir

Avec une bonne encapsulation, ton code ne devrait jamais appel� l'API directement mais passer par un Wrapper ou une Classe, ainsi tu peux plus facilement g�r� et centralis� les appels !