3. char* zu string

char* zu string

  • N

    string zu char* kein problem, aber umgekehrt? kennt da jemand was außer:

    string str;
char * array = new char[100];
// array füllen;
for (int i=0; i < strlen (array); i++)
    str += array[i];
    0
  • C
     

    char * array = new char[100];
string str(arry);
    0
  • B
     

    char * pc ...

// 1. Direkt Konstruktion:
string str(pc);

// 2. Zuweisung:
string str;
str = pc;
    0
  • N

    ja, schön wärs, aber des funzt irgendwie net. der originalcode ist:

    string str;
string temp;

int iLength = GetWindowTextLength (edText);
char * pText = new char[iLength+1];
GetWindowText (edText, (LPTSTR) &pText, iLength);

str = pText;
    0
  • M

    N00Bie schrieb:

    GetWindowText (edText, (LPTSTR) &pText, iLength);

    Das kommt dabei raus, wenn man versucht, Compilerfehlermeldungen durch Casts loszuwerden. Mach das & weg, dann brauchst du auch den Cast nicht mehr

    0
  • R

    Wobei das auch "unsauber" ist ....
    char * != LPTSTR !

    Besser !

    typedef std::basic_string<TCHAR> tstring;
tstring str; 
tstring temp; 

int iLength = GetWindowTextLength (edText); 
LPTSTR pText = new TCHAR[iLength+1]; 
GetWindowText (edText, pText, iLength); 

str = pText;

    Du arbeitest mit ASCII_Strings, obwohl du TSrings (Zwitter) hast. Solange Dir niemand das Project auf unicode umstellt, sollte es aber funzen ... Warum ned gleich richtig machen.

    Strings (char 😉 brauch ich unter windows nur noch, wenn lowlevel C Funktionen aufrufen muss, oder die iostream lib benutze. Intern ist in Windows eh alles TCHAR.

    Windows API und STL ist eh nen Schlechtes Beispiel dafuer, wie man Libs zusammenpresst, die unterschiedliche Philosophien folgen. Fuer die Performance ist das absolut toedlich, ein der Ursachen fuer das Geruecht, das die STL lahm ist.
    Statt std::string zu benutzen, such dir lieber nen Passenden C string wrapper, falls du ned unbedingt wirklich den std::string brauchst. Ich glaub ich hab mal was gelesen, das man CString auch ohne die MFC einsetzen kann. Oder schreib dir selber einen.

    Ciao ...

    0
  • N

    Thx, für den tipp, MFK, das hat geholfen.
    Könntest du das nochmal genauer erläutern, RHBaum, warum das die Performance runterzieht? Das würde, denke ich, nicht nur mich interessieren. 🙂

    Nach dem dritten Durchlesen deines Beitrags fiel mir auf:
    "oder die iostream lib benutze"
    Ich benutze fstream, so brauche ich char, oder?

    0
  • R

    warum das die Performance runterzieht?

    ganz einfach ...

    int iLength = GetWindowTextLength (edText); 
char * pText = new char[iLength+1];  // hier legst nen Puffer an
GetWindowText (edText, (LPTSTR) &pText, iLength); // hier kopierst in den Puffer
str = pText; // hier kopierst in den std::string, ist auch ein kopieren
// irgendwo loeschst den puffer wieder, hoffentlich

    Um aus einem Control den string rauszuholen kopierst den 2 mal. 1 mal mehr als eigentlich noetig.
    besser waere sowas wie :

    // achtung funzt natuerlich nicht ... 
tstring test;
int iLength = GetWindowTextLength (edText); 
test.resize(iLength +1 );
GetWindowText (edText, test.data(), iLength); // hier fehler, aus mehreren gruenden

    funktioniert eben mit std:string ´s ned. du darfst ned in den buffer "schreiben lassen".
    Die Lib eigenen Wrapper sind da halt besser geeignet.

    Und ja, fuer iostream (fstream inclusive) brauchst char * 's ... TCHAR ist halt kein Standard. Standard C++ Textdateien sind auch ned unicode faehig 😃
    Du hasst halt 2 sachen, die ned 100% zusammenpassen ... die "alte" STL, und die Win API.
    Aternativen :

    - du bleibst bei c++ I/O also std::cin und std::cout ! 😃
    - du nimmst die auf die Win32 zugeschnitte Api MFC oder BCC(glaub so hiessen doch die Borland klassen) ... etc.
    - du vergisst auch die iostream geschichten der STL und arbeitest auf CLib ebene ...
    Ich denk mal ist alles keine wirkliche option, in deinem fall sicher besser die unnoetige kopie in kauf zu nehmen ....

    Ciao ....

    0
  • N

    thx, RHBaum, das war wirklich hilfreich! 🙂

    0
Anmelden zum Antworten