4. c_str

c_str

  • M

    Hallo miteinander,

    char Datum[17+1];
   strcpy(Datum, DateTimeToStr(Now().FormatString("dd'.'mm'.'yy' 'hh':'nn':'ss")).c_str());

    Diese zwei Zeilen hat der C++ Builder 6 immer klaglos übersetzt.
    Im Builder 2009 bekomme ich für die 2. Zeile die folgende Fehlermeldung:

    E2034 Konvertierung von 'wchar_t *' nach 'const char *' nicht möglich

    In den Projektoptionen habe ich _TCHAR entspricht char eingestellt und dachte, damit würde automatisch nur char verwendet.

    Wenns nur die eine Stelle wäre, könnte ich es ja casten. Da ich jedoch viele alte Routinen verwende und das wchar nicht brauche, möchte ich mir das nicht antun.

    Frage: Kann man CodeGear RAD Studio 2009 davon überzeugen sich (am besten immer und überall) auf char zu beschränken?

    0
  • R

    Ja, Hallo,

    da mußte ich auch durch. Was Du tun kannst, steht alles in der BCB2009 Hilfe, oder hier mal danach suchen - das Thema wurde schon oft genug behandelt.

    Gruß Rudi

    0
  • M

    @Rudi
    Wäre es nicht schön, wenn noch mehr Leute von den Ergabnissen Deiner Mühen profitieren könnten ??
    Die BCB Hilfe ist beim Umstieg von Version 6.0 auf 2009 nicht eben besser geworden, oder ??
    Wenn ich nach tagelangem suchen und versuchen eine Lösung gefunden hätte, hätte ich hier nicht gepostet.

    0
  • K

    Mecki schrieb:

    @Rudi
    Wäre es nicht schön, wenn noch mehr Leute von den Ergabnissen Deiner Mühen profitieren könnten ??
    Die BCB Hilfe ist beim Umstieg von Version 6.0 auf 2009 nicht eben besser geworden, oder ??

    Bin auch der Meinung, dass man sich helfen sollte, wozu wäre das Forum sonst gut.
    Allerdings muss man doch unterscheiden, ob es grundlegende Änderungen gegenüber Vorgängerversionen sind
    oder einfach nur Grundlagenkenntnisse, die man eh braucht und sicht echt aneignen muss.
    Ha hilft nur Sufu, BCB-Hilfe, googlen...

    Aber nu ma raus mit der Lösung, sonst machst du es ja wie rudiM 😃

    mfg
    kpeter

    0
  • C

    wchar_t* AnsiToWchar_t(AnsiString Str)
    {
    wchar_t *str = new wchar_t[Str.WideCharBufSize()];
    return Str.WideChar(str, Str.WideCharBufSize());
    }

    Diese Funktion sollte Dir bei der Umwandlung helfen. Wie schon gesagt, muss da wohl Jeder durch. Einfach alles relevante im Quelltext anpassen

    0
  • A

    chrismasterlu schrieb:

    Diese Funktion

    ... ist redundant, fehlerhaft und verursacht gnadenlos Speicherlecks.

    Was spricht gegen String (theAnsiString).c_str () ?

    Edit: Typographie

    0
  • M

    Zum eigentlichen Problem hab ich zwar keine Lösung, aber ist das Konstrukt nicht etwas seltsam? Aus TDateTime mit FormatString einen String machen, dann implizit wieder in TDateTime casten (was nur klappt, wenn der FormatString mit der aktuellen Ländereinstellung zusammenpasst) und mit DateTimeToString wieder in String... Gibt's dafür 'nen Grund?

    0
  • M

    Es geht wie gesagt um bestehende, funktionierende Funktionen, an denen ich nichts ändern möchte, und nicht nur um diese zwei Zeilen, sondern um viele Module, die c_str immer wieder und in unterschiedliche Zusammenhängen verwenden.
    Diese Module in werden mehreren Projektgruppen verwendet.
    Das Merkwürdige ist, dass der Compiler einige Projektgruppen fehlerfrei übersetzen kann und in anderen Projektgruppen den Fehler bringt.
    Ich habe bereits alle Optionen immer wieder 'rauf und 'runter verglichen, kann jedoch die entscheidende Stelle nicht finden.
    KENNT SICH DA WER AUS ??

    0
  • A

    Mecki schrieb:

    Ich habe bereits alle Optionen immer wieder 'rauf und 'runter verglichen, kann jedoch die entscheidende Stelle nicht finden.
    KENNT SICH DA WER AUS ??

    Es gibt eine derartige Option das TCHAR-Mapping in den Projektoptionen -, allerdings ist ihr Wirkungsradius eingeschränkter, als du vielleicht vermutest.

    Generell gilt in C++Builder 2009:
    - String ist jetzt ein typedef auf UnicodeString, nicht mehr AnsiString.
    - String::c_str() -> wchar_t*

    Diese Änderungen lassen sich durch keine Projektoption beeinflussen. Die Gründe dafür, daß Delphi keinen "Unicode-Switch" bekommt, hat Allen Bauer hier ausführlich erläutert; die meisten sind auch auf C++Builder übertragbar. Jedoch gibt es in C++Builder-Projekten den TCHAR-Switch, der das Standard-WinAPI-Binding (*A oder *W) sowie die TCHAR-Mappings in tchar.h beeinflußt. Da in C++Builder-Code üblicherweise explizit AnsiString statt String verwendet wurde, kann es sinnvoll sein, den TCHAR-Switch auf "char" zu belassen, denn AnsiString::c_str() gibt natürlich nach wie vor char* zurück. In jedem Falle muß man aber in Situationen wie

    AnsiString myMsg = "Message";
MessagaeBox (Handle, myMsg.c_str () /* -> char* */, Application->Title.c_str () /* -> wchar_t* */, MB_OK);

    mindestens einen der Stringtypen explizit konvertieren - welcher das ist, hängt vom TCHAR-Mapping ab.

    0
  • R

    hallo audacia,

    mensch Meier, Du kenntst Dich aber gut aus. Ich verlauf mich immer in diesem Gestrüpp. War das noch klar und deutlich, als wir noch Assembler, BASIC oder C programmiert haben (Die Ursache ist ja nicht in einer Programmiersprache begründet.) Nur wegen dieser Globalisierung, weil jeder Chinesenstamm seinen eigen Zeichsatz haben will, müßen wir uns hier abrackern. Muß wirklich alles unter einen Deckel gepackt werden. Ich wäre doch schon froh, wenn meine Programme von Nürnberg nach Fürth die Grenze überschreiten würden.

    Der frustige Rudi.

    0
Anmelden zum Antworten