Verwirrung in Programiersprachen!Wer schaft mir Klartext?

Knuddlbaer

Die Empfehlung des StringStreams geht aber ein wenig am Ziel vorbei solange nicht bekannt ist was das Ziel genau ist.

Die Convert Klasse könnte z.B. zum .Net Framework gehören und ohne sonderliches hin und her wird man damit nicht glücklich und die Aussage

str() gibt einen string aus, den du dann ganz normal verwenden kannst.

somit nicht richtig.

Der Empfehlung

Also kauf dir ein scheiß Buch und lerne C++ und dessen Standardbibliothek, dann verstehst du auch nachher im Studium was ihr da in Visual C++ einhakt.

möchte ich hier zustimmen. Es sollte jedoch ein gutes C++ Buch sein.

Danach gehören auch solche Vermutungen:

Dann sollte er doch alle Befehle auch in dem anderen Entwicklungsprogramm kennen

der Vergangenheit an.

ghorst

er frug nach c++ und nicht nach c++/.net, daher ist der hinweis auf .net eigentlich hinfällig. wenn man c++ programmieren will und sich nicht an irgendeine plattform, völlig egal ob borland, vc++, vc.net, qt, glib oder sonst etwas binden will, ist der stringstream im moment der einzig gangbare weg. (übrigens in stringstream wird alles klein geschrieben.)

Knuddlbaer

ghorst schrieb:

er frug nach c++

wenn man c++ programmieren will und sich nicht an irgendeine plattform, völlig egal ob borland, vc++, vc.net, qt, glib oder sonst etwas binden will, ist der stringstream im moment der einzig gangbare weg

Das ist Blödsinn. Selbst im reinen C oder C++ gibt es mehrere Wege.
http://fara.cs.uni-potsdam.de/~kaufmann/?page=GenCppFaqs&faq=IntToString#Answ

Darüberhinaus kann die Plattform auch mit etwas arbeiten, das Du nicht durch stringstream werfen kannst.

Nein, hat er nicht. Übrigens heißt es C++/CLI oder managed C++ nicht C++/.Net

ghorst

mir ist offen gestanden völlig egal, wie die ms-.net-variante von c++ heißt. ein IntToString gibt es in der stl und der string-lib nicht. mehr varianten bietet c++ nicht. alles andere ist plattform abhängig.

IntToString ist in einer zusätzlichen lib implementiert. wenn man die einbinden will, so soll man das tun. aber das hat nichts mehr mit dem standard zu tun. wenn es um die funktionalität ginge, würde ich sofort jedem Qt empfehlen...

Knuddlbaer

Hier wurde auch nicht nach dem Standard gefragt. Daher kann stringstream eine mögliche Lösung sein, genauso gut kann es aber eine unmögliche Lösung sein. Erst recht es es aber nicht

der einzig gangbare weg

Das Dir das völlig egal ist hat man an Deinen Posts schon gesehen.

Erhard Henkes

Das ist ein interessanter Thread, der die Problematik der aktuellen Programmierung deutlich aufzeigt. Praktisches Wissen aus einem Feld wird durch die zu hohe Vielfalt ausgebremst. Das Resultat ist tiefe Verunsicherung über den allgemein richtigen Weg.

ghorst

@Knuddlbaer er frug nach c++ und das hat nunmal einen standard. alles andere ist umgebungsabhängig und daher für anfänger nicht sinnvoll. wie ich schon schrieb: ich empfehle jedem qt, wenn er verstanden hat, worum es geht.

ich schreibe hier bewußt aber nur c++03, da es das einzige ist, worauf man sich verlassen kann und gerade, wenn jemand da steht und feststellt, dass die umgebungen unterschiede aufweisen, muss man ihn auf den einzig, allgemein akzeptierten nenner bringen. tolle tricks kann ich dir in quasi jeder umgebung zeigen, nur sie nützen schlicht gar nichts, wenn man sich nicht an diese umgebung binden will.
daher lernt richtig c++ inklusive stl und dem rest der standard library. alles andere ändert sich in ein paar jahren.

da zeigt sich mal wieder, was fürn murks c++ ist :p

Erhard Henkes

C++ ist elegant und wird wie ein Chamäleon alles andere überdauern. In der µP-Programmierung kommt die Zeit von C++ erst noch.

ghorst schrieb:

es gibt keine direkte funktion um einen zahl in einen string umzuwandeln.

die gibt es sehr wohl. sogar mehr als eine. siehe z.b. mein erstes posting.

Erhard Henkes schrieb:

In der µP-Programmierung kommt die Zeit von C++ erst noch

kann ich nicht bestätigen. das einzige was ich in der hinsicht bisher gesehen habe, waren ziemlich missglückte versuche. was ist eigentlich aus deinen C++ experimenten auf dem AVR geworden?

Erhard Henkes

was ist eigentlich aus deinen C++ experimenten auf dem AVR geworden?

Beim ATmega128 habe ich es IMHO erfolgreich realisiert:
http://www.henkessoft.de/Roboter/Nibo.htm
suche dort bitte nach "C++-Programmierung des Nibo" (state pattern design in C++)
http://www.henkessoft.de/Roboter/Nibo.htm#mozTocId872713
Man benötigt eben genügend RAM (dort 4KByte). Das wird die Zeit bringen.
Allerdings pure virtual und new/delete müssen noch "umgebogen" werden.

ghorst

@fricky sprintf ist keine option, sondern eine krankheit. mit viele liebe würde ich noch snprintf akzeptieren. aber auch da stellt sich mir die frage, warum hässlich, wenn man es auch einfach haben kann?

ghorst schrieb:

@fricky sprintf ist keine option, sondern eine krankheit. mit viele liebe würde ich noch snprintf akzeptieren. aber auch da stellt sich mir die frage, warum hässlich, wenn man es auch einfach haben kann?

ghorst schrieb:

std::string ausgabe;
std::stringstream str;
double zahl=12.4.
str << zahl;
ausgabe=str.str();

das soll einfach sein? nein, das ist hässlich.

Erhard Henkes

es gibt keine direkte funktion um einen zahl in einen string umzuwandeln.

Dann schreibt man sich eben selbst eine ..

^^das habe ich schon einfacher gesehen.

ghorst

wenn du jetzt noch erklärst, was an einem stringstream hässlich ist und mittels snprintf eleganter lösbar ist..

sothis_

ghorst schrieb:

wenn du jetzt noch erklärst, was an einem stringstream hässlich ist und mittels snprintf eleganter lösbar ist..

ok, dann wollmer mal ein wenig bashen

1. sprintf ist C und macht es deswegen schon zur ersten wahl
2. es ist schneller
3. ich kann es auch auf µControllern verwenden
3. kennt jeder standardformatierungsstrings und erkennt sofort was, und wie es formatiert wird
4. es ist weniger zu schreiben

ghorst schrieb:

wenn du jetzt noch erklärst, was an einem stringstream hässlich ist und mittels snprintf eleganter lösbar ist..

- dein code benötigt mehrere schritte, sprintf/snprintf nur einen.
- sprintf/snprintf geht in C wie auch C++ (ist standardisiert)
- die anwendung von sprintf/snprintf ist denkbar einfach (von wegen 'eleganz')

Talla

Ich finds lustig wie sich C++ Programmierer gegenseitig praktisch zerfleischen in der Diskussion welche Funktionen nun besser sind m ein Problem zu lösen.

Aber ich denke ihr überseht hier einen Punkt den ich immer persönlich immer wieder mitbekomme: C++ Programmierer verrennen sich gerne in einen Programmiersprachen/Technologie MischMasch Sumpf wo sie mit hängen und würgen gerade so rauskommen.

Ganz am Anfang hat der Fragesteller Convert::ToString() vorgestellt als Lösung die bei ihm anscheinend getan hat. Daraus ist es leicht abzuleiten dass er C++/CLI programmiert mit dem VS 2008. Ob er das nun beabsichtigt oder nicht macht, Lösungen mit stringstream und sprintf nützen ihm kein bisschen! Klar kann man zig mal zwischen verschiedenen Typen hin und her konvertieren um von .Net String auf std:string zu char* zu kommen und wieder zurück, aber was soll das? Bringt doch nichts. Angenommen er würde nicht C++/CLI programmieren wollen, es war ein versehen und doch lieber bei C++ bleiben. Dann soll er auch die C++ Standardlib verwenden und damit std:string, damit ist dann stringstream die zu bevorzugende Lösung, alleine schon weil sprintf mit std:string gar nichts anfangen kann. Wie oben, klar kann man konvertieren aber wozu, hat man doch nur Nachteile.

Wenn man ein Problem in einer Sprache lösen kann, wieso soll ich dann durch Bibliotheken anderer Sprachen wildern? Die Möglichkeit sowas zu tun ist wichtig, um z.B. aus C++ ne C API zu bedienen, aber wenn man laufend alles querbeet mischt schafft man sich nur selber Probleme und schreibt genau solchen Code der Anfänger immer wieder verwirrt.

Man sieht so oft irgendwelches einführendes Material in C++ welches eher C ist statt C++ weil der Autor selber nicht ganz weiß was er nun schreibt. Um sowas zu verhindern ist es wichtig festzustellen welche Sprache gefragt ist und dementsprechen Antworten zu geben. Deshalb halte ich die Vorchläge für stringstream und sprintf für gut gemeint, aber vollkommen am Thema vorbei. Spätestens wenn er C++/CLI programmiert, sich den String in ne Zahl konvertiert hat durch vielleicht C Funktionen und dann diese Zahl wieder in ein .Net String haben möchte, dann sieht man welchen Mist man doch eigentlich verzapft hat die Sprachen zu wechseln.

Vielleicht noch was zum Anfangspost:

Sind es 2 Verschiedene Programierprachen? Und wenn ja wie heißen diese?

Jup. Der Borland Code ist C++ (wahrscheinlich noch aus einer Vor Standard Zeit) mit irgend ner Bibliotheksfunktion die da mitkommt, aber halt C++. Der zweite Code mit dem Convert::String ist wirklich eine andere Sprache: C++/CLI. Sie ist zwar "abwärtskompatibel" zu C++, aber nur zur Interoperabilität, sie ist und bleibt eine .Net Sprache mit ihren Vor- und Nachteilen. Convert:ToString ist aber wiederum nichts C++/CLI spezifisches sondern eine Bibliotheksfunktion von .Net.

Erhard Henkes

Schreibt euch die Funktionen am besten selbst mit C, dann wisst ihr was ihr macht.