Verwirrung in Programiersprachen!Wer schaft mir Klartext?
-
^^das habe ich schon einfacher gesehen.
-
wenn du jetzt noch erklärst, was an einem stringstream hässlich ist und mittels snprintf eleganter lösbar ist..
-
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')
-
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.
-
Schreibt euch die Funktionen am besten selbst mit C, dann wisst ihr was ihr macht.
-
Elegant ist doch boost::lexical_cast. Und boost ist sowas wie ein Halb-Standard.
-
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.
-
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é
-
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?
-
Das Ergebnis von atoi("s").
-
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é
-
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().
-
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.
-
Mag ja sein, daß du diese Entwicklung hasst. Meine Erfahrungen von früher sagen mir aber, daß die Leute damals auch nicht besser waren und alles alle Nase lang abgekackt ist.
-
Tyrdal schrieb:
Mag ja sein, daß du diese Entwicklung hasst. Meine Erfahrungen von früher sagen mir aber, daß die Leute damals auch nicht besser waren
das stimmt, aber ich bin der meinung das daraus viele gute programmierer hervorgegangen sind. ich bin einfach mal nur gespannt wie es in 10, 15 Jahren aussieht. ich persönlich bezweifle, dass die qualität der software zunehmen wird.
-
Richtige Softwareentwickler haben früher in Assembler programmiert. Die wussten noch, was die CPU in jedem Schritt wirklich macht und was sich in den Speichern abspielt.
Auf der anderen Seite sollte man bei allem Komfort bei der GUI-Programmierung noch in der Lage sein, sich auch "under the hood" zumindest zurecht zu finden. Dies hängt insgesamt von der Aufgabenstellung ab.
-
sothis_ schrieb:
das sind vorteile der c++ sprachmittel. das macht es aber nicht minder verständlicher als ein atoi().
Warum sollte ich die Vorteile nicht ins Boot bringen.
Ganz davon Abgesehen: was soll an atoi verständlich sein? Mit ein bischen Fantasie kann ich noch ein "a to i" rauslesen, aber was ist bitte a und was i. Beim lexical_cast sehe ich wenigstens an dem Templateargument was dieser Cast ausspucken sollte. Ich lese dem Namen ab das es sich um einen Cast, also eine Umwandlung handelt, und mit dem lexical könnte man noch Schrift in Verbindung bringen.
Sicher, verständlicher zu lesen fände ich noch ein:
int i = convertTo<int>("1");Da würde man zumindestens tatsächlich lesen was gemeint ist. Eine Konvertierung zu einem int-Wert (convert to int...).
cu André
-
Entscheidend ist vermutlich, dass man sich zu helfen weiß. Das ist alles, was wirklich zählt.
Der Rest ist blanke Theorie. Namen von Funktionen sind Schall und Rauch.