Integer to String ???

Bones

Nein ist kein CString, nur normaler String. Wobei mir die Lösung mit CString schon mal gesagt wurde, aber mein Compiler kennt das irgendwie nicht. Wenn ich schreibe
CString mystr;
Dann meint er das gäbs nicht, muss ich da noch was includen?
Oder gibts auch ne Möglichkeit das mit normales Strings zu machen?

hustbaer

void OhneMfc()
{
    int n = 123;
    char buffer[32]; // bzw. TCHAR buffer[32];
    sprintf(buffer, "%d", n); // bzw. _stprintf(buffer, _T("%d"), n);

    LVITEM lvItem = {};
    lvItem.mask = LVIF_TEXT;
    lvItem.iItem = INT_MAX;
    lvItem.pszText = buffer;

    ::SendMessage(hWndControl, LVM_INSERTITEM, 0, (LPARAM)(&lvItem));
}

void MitMfc()
{
    int n = 123;
    char buffer[32]; // bzw. TCHAR buffer[32];
    sprintf(buffer, "%d", n); // bzw. _stprintf(buffer, _T("%d"), n);

    listCtrl.InsertItem(INT_MAX, buffer);
}

Martin Richter

_stprintf nicht mehr verwenden!
Besser _sntprintf bzw. _snprintf, damit kann kein Buffer overflow ausgelöst werden.

EXDW

ich kenn als neues

_stprintf_s

Martin Richter

Jo! Das ist die "sichere" Variante!

Es wurde aber auch der alte CRT Funktionssatz erweitert um eine Funktion die die Länge des Puffers aufnimmt.

Bones

Hey danke Leute, von allein wär ich darauf wohl in jahren noch nit drauf gekommen, echt thX. Aber Ich hab da noch ein Problem, bzw. es tut sich dabei eins auf ^^ die Umwandlung funktioniert, also der compiler meckert mal nicht, aber ich kann dann den neuen string nicht in eine Listview schreiben. weiso nicht?

Hier mal mein Code:

char c[32], d[32];
	sprintf(c, "%d", a);  
	sprintf(d, "%d", b);

	List->Items->Add("installed", 0);
		List->Items[a]->SubItems->Add(c);
		List->Items[a]->SubItems->Add(c);
		List->Items[a]->Group = List->Groups[0];
	List->Items->Add("not installed", 0);
		List->Items[b]->SubItems->Add(d);
		List->Items[b]->SubItems->Add(d);
		List->Items[b]->Group = List->Groups[1];

	a = a+2;
	b = b+2;

Die Variablen a und b sind 2 Globale int Variablen und werden bei Start des Programms auf a=1 und b=2 gesetzt. Wie man sieht sollen die Buffer c und d einfach als Item hinzugefügt werden, was aber nicht so richtig klappt.
Die Listview ist auf Report_Style falls das von nützen ist.

Hallo

Hast du nicht gesagt, dass du eine WinForm-Projekt hast? Dann wärst du nämlich wieder im falschen Subforum. Du solltest dir eventuell mal die kurzen Erläuterungen zu den einzelnen Foren durchlesen. dazu sind sie da.

chrische

Bones

Wie jetzt? ^^ja da stand Windows Forms Anwendung, is das etwa immernoch falsch? ^^ ahhhhh ich bin so verwirrt, so viele verschiedene sachen...^^

wo muss ich denn da hin?

Aber kurz zu meiner Frage zurück: hat sich erledigt, habe was gefunden, habe es so gemacht:

String ^c, ^d;
c = String::Format("{0}", a);
d = String::Format("{0}", b);

Das funktioniert, jetzt müsste ich nurnoch rausfinden wie ich das umkehren kann, also aus string ne integer machen. Aber das kann ich ja dann die Fragen die im entsprechenden Forum sind ^^ sry leute

C++ Forumbot

Dieser Thread wurde von Moderator/in CStoll aus dem Forum MFC (Visual C++) in das Forum C++/CLI mit .NET verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Hallo

Lies halt einfach die Beschreibung, die unter den Namen einzelnen Subforen steht.

chrische

Helium

int foo = 42;

String ^ bar = foo.ToString();  // int in einen String umwandeln

int baz = System::Int32::Parse(bar);  // string in ein int umwandeln

Bones

cool danke, dacht nit dass das so einfach geht ^^

hab jetzt folgendes geschrieben:

String ^c, ^d;
c = a.ToString();  
d = b.ToString();

int zahl = System::Int32::Parse(a);

a ist 0 und b ist 1, das wandeln von zahl nach string geht, aber den string dann wieder in ne zahl geht irgendwie nicht. der Compiler schreibt:
error C2665: "System::Int32::Parse": Durch keine der 4 Überladungen konnten alle Argumenttypen konvertiert werden.

Woran kann das liegen???

LordJaxom

Bones schrieb:

Woran kann das liegen???

Evtl. daran dass Du versuchst eine Zahl in eine Zahl zu konvertieren?

Bones

MIST xD

Sorry hab anstatt die String Variable ausversehen die Int Variable reingesteckt, es geht jetzt ^^ danke nochmal

Ich würde das so machen, dadurch hast Du alles auf dem Verwalteteb Heap.
In dem anderen Listing hast Du managed und unmanaged Code.
Natürlich können Programme aus einer Mischung von managed und unmanaged Code bestehen, dass gehört dann zum Guten oder Schlechten Programmierstil.
Der Unterschied besteht darin, dass die eine Variable auf dem Stack landet und die andere auf dem verwalteten Heap.
Die eine wird von der Garbage Collection verwaltet die andere nicht.
Hier nun mein Vorschlag.

{
    Int32 foo = 42; 

    String^ bar = Convert::ToString(foo);  // int in einen String umwandeln 

    Int32 baz = Convert::ToInt32(bar);  // string in ein int umwandeln 
}

System:: kannst Du weglassen, da das doch sicherlich als namespace vereinbart wurde.
Lässt sich so besser lesen.

Gruß Melle

LordJaxom

Ein Int auf dem verwalteten Heap? Nur wegen der Konsistenz, oder was soll das für Vorteile haben?!

Helium

Wo liegt denn da bitte ein int auf dem verwalteten Heap?

LordJaxom

Melle hat dies behauptet, nicht ich

Aber es stimmt natürlich, dass Int32 ein Werttyp ist. Insofern sehe ich zwischen dem vorherigen Beispiel keinen Unterschied zu dem hier, oder resultiert die Verwendung von builtin-Datentypen wie int automatisch in der Generierung von Unmanaged Code? (Ich verwende C++/CLI so selten)

Der int liegt auf dem Stack und ist unmanaged.
Der Int16; Int32 oder Int64 liegt auf dem verwaltetn Heap.
So hat mir das mein Dozent reingehämmert.
Ich hab ihn damit richtig genervt.
Der int ist ISO C++ und die anderen 3 sind C++/CLI

Gruß Melle

Melle schrieb:

Der int liegt auf dem Stack und ist unmanaged.
Der Int16; Int32 oder Int64 liegt auf dem verwaltetn Heap.
So hat mir das mein Dozent reingehämmert.
Ich hab ihn damit richtig genervt.
Der int ist ISO C++ und die anderen 3 sind C++/CLI
Da der String^ in C++/CLI nur auf dem verwaltetn Heap abgelegt werden kann.
Das ist leicht zumerken, durch das Zeichen Dach ^.
Dadurch werden auch Zeiger auf den verwalteten Heap abgelegt und werden automatisch mit nullptr initialisiert.
Das hat den Vorteil, dass die durch die Garbage Collection (Müllabfuhr) verwalteten werde.
Das heißt, sobald der Zeiger nicht mehr benötigt wird, wird der Speicher wieder automatisch freigegeben und muss nicht mit delete selber Freigegeben werden.
Der Arbeitsspeicher kann auch fragmentieren.
Wie schon gesagt, dass ist der persönliche Stil.
Ich bervorzuge die Garbage Collection nicht weil die neu ist.
Ich finde die Freigabe des Arbeitsspeichers sehr nützlich, die gibt es nämlich in ISO C++ so nicht.
Die Garbage Collection soll auch wirklich funzen.

Musste mich selber Zitieren wollt noch ein bischen mehr schreiben.

Gruß Melle