c_str() AnsiString w_str() UnicodeString - konwersja

[lukagrom]

Temat był wałkowany kilkakrotnie, sprowadzał się do tego, że wraz z nowszymi wersjami wymógł tekstowy w środowisku poszedł na UnicodeString, a zmienne char, sukcesywnie są wymienione, na rzecz wchar_t. Jednakże przetrwało kilka starszych funkcji (np procesy), które nijak nie da się zaprzązć pod działanie pary - wchar_t - w_str(), a jakiś zamiennik do nowych typów dotychczas nie powstał. Jednak naprzeciw wychodzi liberalne podejście środowiska do zamiany pomiędzy nowszymi i starszymi typami znakowymi i tekstowymi. Przez przypadek doszedłem do takich "dziwactw?", najłatwiej będzie pokazać za pomocą kopiowania.

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

wchar_t wtab1[64],wtab2[64];
char tab1[64],tab2[64];
wcscpy(wtab1,Edit1->Text.w_str());
 

Kopiować również można z c_str(), bo w nowszym śródowisku (nie wiedzieć czemu) zwraca *wchar_t. Czyli:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 wcscpy(wtab2,Edit1->Text.c_str());
 

Jednakże już na type char takie coś nie przejdzie:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 strcpy(tab1,Edit1->Text.c_str());
 

Co zrobić gdy właśność tekstu z komponentu przekiopować do tablicy char? Prosty zabieg z użyciem AnsiString:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 AnsiString temp_A;
 temp_A=Edit1->Text;
 strcpy(tab1,temp_A.c_str());
 

Po drugiej stronie równania, także środowisko zapewnia dowolność konwersji:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

  Label1->Caption=AnsiString(wtab1);
  Label2->Caption=UnicodeString(wtab1);
  Label3->Caption=AnsiString(tab1);
  Label4->Caption=UnicodeString(tab1);
 

Tak więc o ile ktoś potrzebuje na siłę wcisnąć jakiś kod bazujący na starszych typach, ściągnąć jakaś archaiczną funkcję z C bazującą na char, to idzie to jakoś w miarę łatwo w nowszej wersji dokonać.

[polymorphism]

Nie widzę pytania. To wątek z poradą?

[lukagrom]

Rzeczywiście zabrakło pytania. W sumie można retorycznie tylko zapytać, że dobrze, że występują ułatwienia i funkcję wewnętrzne typu w_str() (zapożyczone z Delphi), które znacząco skracają i ułatwiają "zabawe" z typem wchar_t, jak i dają możliwość przeskakiwania w zależności od sytuacji, do miejsc gdzie nagle potrzebna jest para -char - str().
Ze strony referencyjnej C++, gdyby trzeba było przypisać String do wchar_t to wygląda to dużo karkołomniej z swprintf:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

String t_Label=Label1->Caption;
 const size_t width=t_Label.Length()+1;
 wchar_t *buff_W=new wchar_t[width];
 swprintf(buff_W,width,L"%s",t_Label.c_str());
 Edit3->Text=String(buff_W);

 

U mnie buff_W jest dynamiczne, na stronie z przykładem - wchar_t buff_W[width] - chyba gestia kompilatora, bo mój wywala wtedy błąd - [Constant expression required.
Reasumując. Czy pochodzące od Embarcadero w_str() i inne podobne wynazlazki są dobre? Wszystko wskazuje na to, że jak najbardziej.

[polymorphism]

(...) na stronie z przykładem - wchar_t buff_W[width] - chyba gestia kompilatora, bo mój wywala wtedy błąd - [Constant expression required.

W C++ VLA są niedozwolone, dlatego width nie może być zmienną - to jest słuszny powód błędu.

g++ dopuszcza VLA, ale to jest niezgodne ze standardem C++ i taki kod jest nieprzenośny (i niebezpieczny).

Czy pochodzące od Embarcadero w_str() i inne podobne wynazlazki są dobre?

Przy takiej konwersji wide narrow trzeba pamiętać, że nie wszystkie znaki da się przekonwertować, dlatego zawsze warto poszukać unikodowych wersji funkcji.

wchar_t *buff_W=new wchar_t[width];

Nie zwalniasz tej pamięci nigdzie. Z uporem maniaka po raz n-ty powtórzę: ręczne zarządzanie pamięcią w C++ to w 90% przypadków błąd projektowy.

[mateusznowakpl]

Zgadzam się z tym co napisał polymorphism - nie powinno się w C++ zarządzać pamięcią ręcznie! Zwolnij pamięc.