Verwirrung in Programiersprachen!Wer schaft mir Klartext?
-
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.
-
asc@ausgeloggt schrieb:
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.
vielleicht sehe ich es auch zu steif aus der meiner sicht. wenn man lange mit standard-c bibliotheken programmiert, ist ein atoi() eben genau so selbstverständlich, wie ein if-else-konstrukt oder switch-block. man sieht sofort was es macht, und, wenn man sich die mühe macht auch den quellcode der crt/libc zu analysieren, wie es dies macht. von daher ist es für mich eben genau so verständlich, wie für dich ein lexical_cast.
-
Erhard Henkes schrieb:
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.das wäre die kurzfassung
-
sothis_ schrieb:
vielleicht sehe ich es auch zu steif aus der meiner sicht. wenn man lange mit standard-c bibliotheken programmiert, ist ein atoi() eben genau so selbstverständlich,
wie geht nochmal ein wide string zu float (nicht double)?
atof zB ist lustigerweise nicht nach float sondern nach double und a bedeutet zwar string aber eben nur normalen ascii string. also wie würde die funktion wide string to float denn heissen?
wstrtof? ne, nicht wirklich, weil f ja für double steht.
kann man es lernen und ist es verwendbar? ja.
ist es sinnvoll designed? nein.
-
Shade Of Mine schrieb:
ist es sinnvoll designed?
wieder eines dieser neumodischen fremdwörter
sinnvoll ist das, was jeder für sich selbst als sinnvoll erachtet. übrigens kann float unter umständen gleich breit wie double sein, von daher mach deine namensbashing argumentation keinen sinn
-
Nein, es ist noch lange nicht sonnvoll, solange man es nur für sich für sinnvoll erachtet. Der Witz ist, das es auch sowas wie Projekte gibt, die in Teamarbeit gelöst werden müssen. Und dann ist die einzige egomanische Sichtweise nur noch für den A-Punkt! Genau deshalb sind Namen auf den ersten Blick Schall und Rauch. Beim zweiten Blick, muß ich dann doch wieder einen sinnvollen Namen "designen" damit ihn jeder versteht, der im Team dabei ist oder später mal das Zeug pflegen muß.
Ihr arbeitet wohl nur an Einmann-Projekten, die anscheinend nur von kurzer Lebensdauer sind. Aber geht mal an ein Projekt mit mehreren Leuten das mehr als ein Jahrzehnt gepflegt wird. Dann wollen wir mal weiter sehen, wie weit ihr mit eurer Ego-Perspektive kommt.
lexical_cast ist schon eine sehr aussagefähige Sache, der Template-Parameter gibt den Rest für ein besseres Verständnis.
-
Gröhler schrieb:
Nein, es ist noch lange nicht sonnvoll, solange man es nur für sich für sinnvoll erachtet. Der Witz ist, das es auch sowas wie Projekte gibt, die in Teamarbeit gelöst werden müssen. Und dann ist die einzige egomanische Sichtweise nur noch für den A-Punkt! Genau deshalb sind Namen auf den ersten Blick Schall und Rauch. Beim zweiten Blick, muß ich dann doch wieder einen sinnvollen Namen "designen" damit ihn jeder versteht, der im Team dabei ist oder später mal das Zeug pflegen muß.
vielleicht, aber auch das hängt vom einzelnen ab, wie gut er mit gegebenen umständen umgehen kann. ein vielseitiger programmierer kann mit lexical_cast, so wie mit funktionen der crt/libc umgehen und weiß wie er seine schnittstellen entsprechend anzupassen hat.
Gröhler schrieb:
Ihr arbeitet wohl nur an Einmann-Projekten, die anscheinend nur von kurzer Lebensdauer sind. Aber geht mal an ein Projekt mit mehreren Leuten das mehr als ein Jahrzehnt gepflegt wird. Dann wollen wir mal weiter sehen, wie weit ihr mit eurer Ego-Perspektive kommt.
unterstellungen, über die wir ja wohl nicht weiter diskutieren zu brauchen.
Gröhler schrieb:
lexical_cast ist schon eine sehr aussagefähige Sache, der Template-Parameter gibt den Rest für ein besseres Verständnis.
das hat hier nie jemand bestritten.
-
Gröhler schrieb:
Nein, es ist noch lange nicht sonnvoll, solange man es nur für sich für sinnvoll erachtet. Der Witz ist, das es auch sowas wie Projekte gibt, die in Teamarbeit gelöst werden müssen.
Und das heißt automatisch, dass man boost benutzen muss? Ich würd mich totlachen, wenns nicht so traurig wär. Der Witz ist, dass es auch Projekte gibt, in denen man einer von vielen ist und nicht mal einfach so irgendeine tolle Lib einbinden kann, nur um einen tollen Cast zu haben, den n-1 Teammitglieder noch nie gesehen haben. atof dagegen kennt jeder.
Ihr arbeitet wohl nur an Einmann-Projekten, die anscheinend nur von kurzer Lebensdauer sind. Aber geht mal an ein Projekt mit mehreren Leuten das mehr als ein Jahrzehnt gepflegt wird. Dann wollen wir mal weiter sehen, wie weit ihr mit eurer Ego-Perspektive kommt.
BTDT.
-
sothis_ schrieb:
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.
wieso alarmierend? nicht jeder muss alles können und wissen. z.b. ein programmierknecht für visual-bräsig, c#, php, etc. braucht keine assembler-kenntnisse, weil sowas in seinem aufgabenbereich nie dran vorkommt.
demzufolge haben die auch luxuriöse ansprüche wie z.b. eine programmiersprache, die gewisse fehler erst gar nicht zulässt, eine laufzeitumgebung die fehlertolerant ist und grobe fehler abfängt ohne dass das system abschmiert, riesige standardbibliotheken, die einem alles abnehmen, usw. kann man zwar drüber lästern, aber das zeug hat seine berechtigung. auch weil es die wirtschaft gut anfeuert, ganze industrien und neue berufszweige gschaffen hat usw.