Verwirrung in Programiersprachen!Wer schaft mir Klartext?

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.

Tyrdal

Elegant ist doch boost::lexical_cast. Und boost ist sowas wie ein Halb-Standard.

asc

fricky schrieb:

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

Sofern man noch die Boost-Bibliothek hinzunimmt gibt es durchaus kürzere und für kurze Anwendungsfälle IMHO sinnvollere Alternativen.

Aber eins stimmt durchaus:
C++ hat als großen Vorteil seine Vielfalt UND als großen Nachteil seine Vielfalt.

cu André

Talla schrieb:

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.

ist doch beides gut, weil beides standardisiert ist. nur mit diesen spezialfunktionen wie blahblubb.ConvertToString() usw. wird der austausch der entwicklungsumgebung schwierig.

asc schrieb:

fricky schrieb:

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

Sofern man noch die Boost-Bibliothek hinzunimmt gibt es durchaus kürzere und für kurze Anwendungsfälle IMHO sinnvollere Alternativen.

boost-code sieht auch immer hässlich aus. ausserdem steht er damit vorm gleichen problem, wenn boost in der einen entwicklungsumgebung installiert ist und unter der anderen nicht.

asc

fricky schrieb:

boost-code sieht auch immer hässlich aus. ausserdem steht er damit vorm gleichen problem, wenn boost in der einen entwicklungsumgebung installiert ist und unter der anderen nicht.

Wo sieht boost-Code bitte "immer" hässlich aus.
Zudem gibt es Boost für nahezu jede C++ Entwicklungsumgebung (zumindest für die, die einigermaßen Standardkonform sind).

int i = boost::lexical_cast<int>("123");

Dies ist auf jedenfall verständlicher als die C-Variante und die Variante der Standardbibliothek. Zudem entspricht es der bevorzugten Konvertierungssyntax von C++.

cu André

sothis_

asc schrieb:

int i = boost::lexical_cast<int>("123");
Dies ist auf jedenfall verständlicher als die C-Variante und die Variante der Standardbibliothek. Zudem entspricht es der bevorzugten Konvertierungssyntax von C++.

cu André

ich bitte dich. was ist an atoi() unverständlicher?

Tyrdal

Das Ergebnis von atoi("s").

asc

sothis_ schrieb:

ich bitte dich. was ist an atoi() unverständlicher?

1. Muss ich für jeden Zahlentyp eine andere Funktion suchen (Hier ist dies nur ein Templateparameter). Zudem ist es auch umgekeht nutzbar (lexical_caststd::string(1)). Man muss sich nur ein Befehl nicht n merken.
2. Hält es sich an die Notation der C++ Casts (wie static_cast, const_cast, dynamic_cast).
3. Bei Fehlern wird wie unter C++ Üblich mit Exceptions hantiert (Konsistenzfrage).

cu André

sothis_

asc schrieb:

sothis_ schrieb:

ich bitte dich. was ist an atoi() unverständlicher?

1. Muss ich für jeden Zahlentyp eine andere Funktion suchen (Hier ist dies nur ein Templateparameter). Zudem ist es auch umgekeht nutzbar (lexical_caststd::string(1)). Man muss sich nur ein Befehl nicht n merken.
2. Hält es sich an die Notation der C++ Casts (wie static_cast, const_cast, dynamic_cast).
3. Bei Fehlern wird wie unter C++ Üblich mit Exceptions hantiert (Konsistenzfrage).

cu André

das sind vorteile der c++ sprachmittel. das macht es aber nicht minder verständlicher als ein atoi().

sothis_

Tyrdal schrieb:

Das Ergebnis von atoi("s").

ja, omfgwtfbbq. genau das ist es was ich hasse. wenn der programmierer etwas als problematisch ansieht, weil es seine fehler nicht automatisch erkennt, ist es gleich schlecht und unverständlich(!) - lol. diese einstellung hat programmiersprachen wie c# hervorgebracht und ein generation von c#-kiddies, wie sie ihres gleichen sucht. jetzt schimpft sich jeder softwareentwickler, der ein fenster mit schaltern zusammengeklickt hat, mit ein paar fremdwörtern um sich schmeißt, aber überhaupt nicht mehr versteht, wie die maschine auf der alles läuft überhaupt funktioniert. ich persönlich halte das für eine alarmierende entwicklung.

edit: das soll kein flame richtung c# sein, diese sprache bot sich aber aus meiner sicht als gutes beispiel der heutigen entwicklung.