Verwirrung in Programiersprachen!Wer schaft mir Klartext?
-
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.
-
fricky schrieb:
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.
auch das stimmt, aber ich persönlich bezweifle, das dies zukünftig der qualität von software zugute kommt. zudem hardwarehersteller sich mehr und mehr and den status quo heutiger softwareschittstellen richten. schau dir an, was aus der x86 architektur geworden ist. erweiterungen über erweiterungen, nicht um abwärtskompatibilität zu gewährleisten, sondern um zu verhindern das grundlegende änderungen am betriebssystem notwendig wären. neue architekturen verkaufen sich einfach nicht, schau dir die intel itanium architektur an. im umkehrschluss interessieren sich zunehmend immer weniger für systemprogrammierung, da es auch nicht notwendig erscheint. also konzentrieren sich mehr und mehr auf abstraktion und noch mehr abstraktion, aber eigentliche innovationen im softwarebereich bleiben aus. ich sehe da eine deutliche verschiebung des wissenskapitals, und denke das deswegen softwarequalität und innovationsquantität so langsam aber sicher stagniert.
edit: oh sorry, ich wollte den thread nicht so derart offtopic schieben
-
sothis_ schrieb:
schau dir an, was aus der x86 architektur geworden ist. erweiterungen über erweiterungen, nicht um abwärtskompatibilität zu gewährleisten, sondern um zu verhindern das grundlegende änderungen am betriebssystem notwendig wären.
klar, x86er-systeme sind übelstes flickwerk. das fing ja schon an, als sie den 8086-adressbus aufgebohrt haben.
sothis_ schrieb:
neue architekturen verkaufen sich einfach nicht, schau dir die intel itanium architektur an. im umkehrschluss interessieren sich zunehmend immer weniger für systemprogrammierung, da es auch nicht notwendig erscheint.
nicht im pc-bereich, aber sonst schon. es gibt prozessoren für alle anwendungsfälle, die sich gut verkaufen. tendenz steigend, siehe z.b. hier: http://www.esacademy.com/automation/faq/primer/3.htm
und dafür braucht man auch programmierer, die noch mit bits und bytes 'per du' sind. tendenz ebenfalls steigend. die leute, die sich für systemprogrammierung interessieren, fangen heute bloss anders an, als damals. damals musste ja jeder, um seiner kiste speed zu entlocken, in assembler coden und wurde zwangsweise zum low-level freak.sothis_ schrieb:
also konzentrieren sich mehr und mehr auf abstraktion und noch mehr abstraktion, aber eigentliche innovationen im softwarebereich bleiben aus
naja, heute fummeln sich sich die 'great game coder' was mit c++, directx und boost hin, alles zig-fach hinter abstraction layern versteckt. das programm ist dann zwar etliche megabytes gross, frisst taktzyklen ohne ende aber tuts trotzdem ausreichend gut, weil die hardware so viel power hat. trotzdem gibts auch auf'm highlevel-sektor innovationen. vielleicht weniger bei den c++-fummlern, die schon seit jahren auf ihren neuen standard warten, aber z.b. im web-bereich gibts ja seit je her ständig neue ideen.