http://tour.golang.org/#22 Auf RUN klicken! Alles OK! Dann beim if if x < 0 { die Klammer mit Return in die nächste Zeile verfrachten if x < 0 { nochmal auf RUN klicken! Schwach oder?! ;-)
Wenn ich die Sprachdefinition richtig verstanden habe greift dort: When the input is broken into tokens, a semicolon is automatically inserted into the token stream at the end of a non-blank line if the line's final token is..., ..., an integer literal. if x < 0 erfüllt das wohl. Nich das ich das übersichtlich finde. Wenn man muss kan man sich da aber sicher dran gewöhnen. Zumal die Fehlermeldung einen da auch nicht im Regen stehen lässt. viel Spass Hauspapa
hauspapa schrieb: > Nich das ich das übersichtlich finde. Wenn man muss kan man sich da aber > sicher dran gewöhnen. Zumal die Fehlermeldung einen da auch nicht im > Regen stehen lässt. Naja, die Fehlermeldung lautet prog.go:9: missing condition in if statement prog.go:9: x < 0 evaluated but not used [process exited with non-zero status] Das man jetzt erst mal die Sprachdefinition heranziehen darf, damit man merkt, dass nicht mal ein Zeilenumbruch in einer Sprache möglich ist die sich anschickt das "bessere C" zu sein ... Was soll ich davon halten?!
Ebenso wozu eine nachgestellte Typinfo var zahl int Welchen Vorteil soll das bringen?
> Was soll ich davon halten?! > Welchen Vorteil soll das bringen? Diese Fragen solltest Du an den Schöpfer dieser Programmiersprache richten - vielleicht ist es auch nur der Versuch sich von C syntaktisch abzusetzen. Ich würde mich nicht über syntaktische Eigentümlichkeiten aufregen ... die Frage ist welche Vorteile dieses Sprachprojekt jetzt genau bringen soll? Ich könnte ja auch das hier verwenden: http://openeuphoria.org/index.wc Bringen diese neuen Sprachen jetzt was gegenüber den etablierten Sprachen?
prg schrieb: > Welchen Vorteil soll das bringen? Da hat man dann was eigenes, wenn die Kinder aus dem Haus sind. (Loriot)
Am [Loriot] Jodeldiplom [/Loriot] soll's nicht scheitern und die Aufregung ist mehr Verwunderung. OK, 5 Minuten reichen wohl nicht um das Konzept hinter go zu verstehen. Im return mehrere Rückgabewerte und anderes hat meine Aufmerksamkeit erweckt .. Wenn go aber tatsächlich so unflexibel in der Klammersetzung ist wäre das schade und ein nogo für mich.
> Bringen diese neuen Sprachen jetzt was gegenüber den etablierten > Sprachen? Das ist die Frage die ich mir auch immer stelle. Nimrod z.B. ist auch so etwas. Sprachen die nicht allzu sehr von C abweichen schaue ich mir aber gelegentlich doch gerne mal an.
> Wenn go aber tatsächlich so unflexibel in der Klammersetzung ist wäre > das schade und ein nogo für mich. es gibt ja genügend Alternativen ... ich sehe auch noch nicht den enormen Vorteil dieser Sprache.
Berlin-Fanclub schrieb: >> Wenn go aber tatsächlich so unflexibel in der Klammersetzung ist wäre >> das schade und ein nogo für mich. > es gibt ja genügend Alternativen ... ich sehe auch noch nicht den > enormen Vorteil dieser Sprache. Vorteile sehe ich auch nicht. Mir gefallen von den Neuentwicklungen der letzten Jahre z.Z. Rust und F# am besten. Sehe mir aber auch andere Entwicklungen wie Scala (auf Coursera läuft gerade ein Kurs zur Sprache von und mit deren Erfinder), Julia oder ATS an. Rust wird bei Mozilla verwendet bzw. soll werden/ist dort die Basis der neuen Layout Engine, F# hat mittlerweile eine recht breite Basis. Go ist dagegen Google und u.a. von Ken Thompson (Unix, B), Rob Pike (Plan 9, Inferno)...
> Vorteile sehe ich auch nicht. Mir gefallen von den Neuentwicklungen der > letzten Jahre z.Z. Rust und F# am besten. Solche Vergleich wurden bereits gezogen. Zu Rust wurde da geschrieben http://www.heise.de/developer/news/foren/S-Re-Rust-hoert-sich-vielversprechender-an/forum-255853/msg-23535291/read/ " Rust ist meiner Meinung nach ähnlich komplex wie C++. Rust hat statt nur einem gleich vier verschiedene Zeigertypen, die dann in Form von &, ~, @, *, &mut, ~str, ~"" und Co. überall im Code ihre Krähenfußabdrücke hinterlassen ... " go will gerade eine EINFACHE Sprache sein, die man leicht versteht und anwenden kann. Das imponiert mir mehr als wenn ich mal wieder noch eine Verkomplizierung von C++ vorgestellt bekomme. > Go ist dagegen Google und u.a. von Ken Thompson (Unix, B), Rob Pike > (Plan 9, Inferno)... Zu Pike: "Pike ist zusammen mit Brian Kernighan Autor von The Practice of Programming und The Unix Programming Environment (deutscher Titel: Der Unix Werkzeugkasten. Programmieren mit Unix). Zusammen mit Ken Thompson ist er auch noch Mitentwickler von UTF-8." Zu Ken Thomson "An der Universität von Kalifornien in Berkeley, Kalifornien absolvierte Thompson ein Studium der Elektrotechnik. 1969 implementierte er zusammen mit seinem Kollegen Dennis Ritchie in den Bell Labs die erste Version des Unix-Betriebssystems[1] in Assemblersprache." Klingt nicht so schlecht, will ich meinen.
prg schrieb: >> Vorteile sehe ich auch nicht. Mir gefallen von den Neuentwicklungen der >> letzten Jahre z.Z. Rust und F# am besten. > > Solche Vergleich wurden bereits gezogen. Zu Rust wurde da geschrieben > > http://www.heise.de/developer/news/foren/S-Re-Rust-hoert-sich-vielversprechender-an/forum-255853/msg-23535291/read/ > > " Rust ist meiner Meinung nach ähnlich komplex wie C++. Rust hat statt > nur einem gleich vier verschiedene Zeigertypen, die dann in Form von > &, ~, @, *, &mut, ~str, ~"" und Co. überall im Code ihre > Krähenfußabdrücke hinterlassen ... " Rust macht dort nur das explizit, was in anderen Sprachen wie eben C oder C++ zu Problemen führen kann. Der Vorteil von Rust an dieser Stelle ist, dass schon der Compiler Fehler finden kann. > go will gerade eine EINFACHE Sprache sein, die man leicht versteht und > anwenden kann. Das imponiert mir mehr als wenn ich mal wieder noch eine > Verkomplizierung von C++ vorgestellt bekomme. Kompliziert empfinde ich das gegenüber C/C++ nicht. Siehe http://static.rust-lang.org/doc/master/tutorial.html#more-on-boxes und den folgenden Abschnit über Referenzen > Klingt nicht so schlecht, will ich meinen. Wer Google mag... Zudem hat Go so einige Macken, die da auch nicht mehr so einfach glattgebügelt werden können. Und obwohl beide Sprachen (Rust und Go) als Systemsprachen angetreten sind, fehlen beiden meiner Meinung nach noch so einige Features, damit sie C/C++ dort wirklich ersetzen können. *) guter Artikel über einige Unterschiede und Ähnlichkeiten von Go und Rust http://lwn.net/Articles/548560/
> Zudem hat Go so einige Macken Das ist wohl wahr. Allein das Beharren auf der öffenden Klammer in der gleichen Zeile gefällt mir nicht. Hab's mal local probiert, Pfade gesetzt, ein paar Testsourcen compiliert. Ging zwar alles, aber gleiches Verhalten. War jetzt meinerseits auch gar nicht beabsichtigt die "Werbetrommel" für go zu rühren. Bin mehr zufällig darüber gestolpert, aufgrund der Heisenews http://www.heise.de/developer/meldung/Was-bringt-Go-1-3-2175838.html und dann war ich halt neugierig. >> go will gerade eine EINFACHE Sprache sein, die man leicht versteht und >> anwenden kann. Das imponiert mir mehr als wenn ich mal wieder noch eine >> Verkomplizierung von C++ vorgestellt bekomme. > Kompliziert empfinde ich das gegenüber C/C++ nicht. Siehe > http://static.rust-lang.org/doc/master/tutorial.ht... > und den folgenden Abschnit über Referenzen Hmm .. was versteht Rust denn unter "owned_box"? Auf dem Heap erzeugte Ressourcen? Kennt das automatisches GC (Mülleinsammeln :)) wie C#/CLR? Sieht auf den ersten Blick eigentlich auch recht "C-heimisch" aus mit Tendenz Richtung ++. Gibt's eigentlich irgendwo eine Übersicht über all die vielen Programmierdialekte-Neuerscheinungen der letzten Jahren, deren Entwicklungsstand und Popularitätswert? Würde mich mal interessieren.
prg schrieb: > Ebenso wozu eine nachgestellte Typinfo > > var zahl int > > Welchen Vorteil soll das bringen? Die ist sinnvoll, allerdings finde ich den trennenden Doppelpunkt von Pascal optisch zweckmäßiger. Bei C hast du nämlich das Problem bei Zeigern:
1 | char* foo, bar, mumble; |
Auch, wenn es auf den ersten Blick anders aussieht: nur “foo” ist ein Zeiger, “bar” und “mumble” dagegen nicht.
:
Bearbeitet durch Moderator
> char* foo, bar, mumble;
das geht, ist aber eine schlechte Schreibweise bzw. schlechter
Programmierstil, sinnvoller ist:
char *foo, bar, mumble;
Damit ist dann auch alles klar.
prg schrieb: > Welchen Vorteil soll das bringen? Die Syntax von Deklarationen in C ist grauenhaft. http://blog.golang.org/gos-declaration-syntax Tragischerweise wurden die Pointer nicht gerade gebogen. Wie dort ebenfalls bedauert wird.
:
Bearbeitet durch User
prg schrieb: > Rust ist meiner Meinung nach ähnlich komplex wie C++. Rust hat statt > nur einem gleich vier verschiedene Zeigertypen, die dann in Form von > &, ~, @, *, &mut, ~str, ~"" und Co. überall im Code ihre > Krähenfußabdrücke hinterlassen ... " Die Information ist doch auch schon veraltet, denn die verschiedenen Zeigertypen wurden in die stdlib verfrachtet. In der Sprache selbst gibt es nur noch den owned pointer. Der GC Zeiger ist nun gc:Gc und der SmartPointer rc:Rc. Nach meiner Meinung die richtige Entscheidung. prg schrieb: > Hmm .. was versteht Rust denn unter "owned_box"? Auf dem Heap erzeugte > Ressourcen? Kennt das automatisches GC (Mülleinsammeln :)) wie C#/CLR? > Sieht auf den ersten Blick eigentlich auch recht "C-heimisch" aus mit > Tendenz Richtung ++. Ja wird auf den Heap angelegt. GC gibt es mit dem gc:Gc Zeiger. Bei Lowlevel und Realtime muss man sich halt mit sowas beschäftigen. Wer sich mit sowas nicht auseinander setzen will, für den ist Java/C#/Go besser geeignet. Rust soll kein Java 2.0 sein, sondern ein besseres sauberes C++.
prg schrieb: > Das man jetzt erst mal die Sprachdefinition heranziehen darf [...] Das haben neue Sprachen so an sich. Gut, heutzutage(TM) scheint es unter der heutigen Jugend(TM) eher üblich zu sein, sich via Trial and Error an eine Programmiersprache anzunähern (vgl. z. B. zahlreiche diesbzgl. Threads alleine in den letzten Tagen), als die zugehörige Dokumentation zu lesen. Naja, ist wohl auch ein Symptom von Facebook, Youtube et al., dass Jeder meint, Alles innerhalb von max. 30 Minuten perfekt beherrschen können zu müssen (d. h. auch alle nur erdenklichen Programmiersprachen); daher kann man da wohl nur bedingt einen Vorwurf machen. > [...] eine(r) Sprache [...] die sich anschickt das "bessere C" zu sein ... "Besser" ist Definitionssache. Wo ist das definiert - und vor allem wie? Ansonsten gilt auch hier wieder der Verweis auf die Sprachdokumentation. > Was soll ich davon halten?! Da kannst Du davon halten, was Du willst - das ist von der Meinungsfreiheit abgedeckt. D. V. schrieb: > Wird Zeit, dass die Osterferien wieder zu Ende gehen. Full ACK.
Patrick (Gast) schrieb: prg schrieb: >> Das man jetzt erst mal die Sprachdefinition heranziehen darf [...] > Das haben neue Sprachen so an sich. > Gut, heutzutage(TM) scheint es unter der heutigen Jugend(TM) eher üblich > zu sein, sich via Trial and Error an eine Programmiersprache anzunähern > (vgl. z. B. zahlreiche diesbzgl. Threads alleine in den letzten Tagen), > als die zugehörige Dokumentation zu lesen. Zuerst einmal Danke für das Zuschreiben von "Jugend". Fühle mich jetzt wieder richtig jung nach solchen lieb gemeinten Äußerungen. :) Wenn du mir jetzt auch noch den Bären aufbinden möchtest, es genüge sich die Dokumentation einer neuen Programmiersprache EINMAL durchzulesen und dann wüsste man alles, dann entgegne ich dir, dass wohl so gut wie keiner dem bei Programmiersprachen wirklich folgt oder solchen Ansprüchen gerecht wird. Sonst hätten wir hier schon lange keine Diskussionen mehr über C/C++ mit seinen leidigen Sprachverwirrungen! Schhließlich steht ALLES irgendwo geschrieben. Man muss es nur finden. Folglich würde sich auch dieses Forum erübrigen. Man könnte bei nahezu jeder Frage dem Fragesteller schließlich den Vorhalt unterbreiten, er habe nur nicht lange genug nach der Lösung seiner Frage gegoogelt. Trail&Error ist durchaus nichts abträgliches. Im Gegenteil, es bringt UNVOREINGENOMMENHEIT beim Ausprobieren mit sich, überwindet also die mentale Hürde etwas zu unternehmen, wovor andere aus falschem Respekt, Ängstlichkeit oder zuviel formalem Hintergrundwissen Abstand nehmen würden. Ich habe mir über die Jahre angewöhnt immer erstmal mir selber einen Eindruck zu verschaffen, bevor ich die Eindrücke anderer (auch die der Buchautoren) auf mich wirken lasse. Wahrscheinlich wäre mir aufgrund des Hinweises im Manual dieses bugbehaftete Verhalten des go Tokenizers gar nicht aufgefallen bzw. ich hätte es für "normal" gehalten, schließlich steht es so beschrieben. Das ist aber nicht "normal". Das ist einfach nur MIST und ich wette, in einer der künftigen Versionen wird man das erkennen und revidieren.
prg schrieb: > Ich habe mir über die Jahre angewöhnt immer erstmal mir selber > einen Eindruck zu verschaffen, bevor ich die Eindrücke anderer (auch die > der Buchautoren) auf mich wirken lasse. Klingt in diesem Zusammenhang leider wie eine a posteriori zurechtgelegte Begründung für notorische Lesefaulheit ;-). Denn Referenzhandbücher von Programmiersprachen dienen nicht der Verbreitung der Meinung von Autoren. Sondern sind eher als formale Dokumente zu betrachten und dienen eher der Grundlage des anschliessenden Ausprobierens, als dessen Vermeidung. Ansonsten aber bin ich irgendwie deiner Meinung. Weil ich nämlich auch dazu neige, mir meinen Eindrücke abseits von TV, Youtube oder auch Schulungen zu bilden (*). Und zwar indem ich mich der verfügbaren sachlichen Literatur zuwende. Also gerade das zuerst lese, was du vorsorglich vermeidest. ;-) *: Was aber im IT-Zusammenhang weniger mit der Vermeidung ausgetretener Pfade zusammenhängt, sondern weil ich sonst entweder bei dem Gelaber einschlafe, oder die Schulung in eine Diskussion zwischen mir und dem Schulungsleiter ausartet. ;-)
:
Bearbeitet durch User
Jörg Wunsch (dl8dtl) (Moderator) schrieb: prg schrieb: >> Ebenso wozu eine nachgestellte Typinfo >> >> var zahl int >> >> Welchen Vorteil soll das bringen? > Die ist sinnvoll, allerdings finde ich den trennenden Doppelpunkt von > Pascal optisch zweckmäßiger. > Bei C hast du nämlich das Problem bei Zeigern: > char* foo, bar, mumble; Nicht wenn man sich an die Schreibweise des K&R (2. Ausgabe) hält. Ich finde dort keine einzige Textstelle, die den Inhaltoperator (*) dem Variablentyp beistellen würde. Im K&R würde folglich stehen char *foo, bar, mumble; und dann wäre auch klar, hier wird ein Zeiger auf eine char Variable und zwei Variablen vom Typ char deklariert. Entsprechend findet sich im K&R auch unter Deklararion von Zeigern auch Beispiele wie int i, *pi, const cpi = &i Da es hier nicht an der Reihenfolge der Variablen liegen kann, um was es sich handelt (Zeiger oder int-Wert) ist die Deklaration identisch mit int *pi, i, const cpi = &i Nach deinem Beispiel Jörg wäre das dann unglücklich geschrieben int* pi, i, const cpi = &i immer noch richtig, aber eher verwirrend. Jedoch nur, wenn man sich nicht an den K&R hält und solche Schreibweisen vermeidet.
prg schrieb: > Nicht wenn man sich an die Schreibweise des K&R (2. Ausgabe) hält. > Ich finde dort keine einzige Textstelle, die den Inhaltoperator (*) dem > Variablentyp beistellen würde. Bei K&R nicht. Aber in C++ findet sich die Schreibeweise "Typ& Var" ausgesprochen häufig. Direkt neben "Typ *Var". ;-)
A. K. (prx) schrieb: prg schrieb: >> Ich habe mir über die Jahre angewöhnt immer erstmal mir selber >> einen Eindruck zu verschaffen, bevor ich die Eindrücke anderer (auch die >> der Buchautoren) auf mich wirken lasse. > Klingt in diesem Zusammenhang leider wie eine a posteriori > zurechtgelegte Begründung für notorische Lesefaulheit ;-). Nö, es ist eher ein sondieren, in was es überhaupt lohnt Zeit, Mühe und Arbeitsaufwand zu stecken. Synonym dazu, bevor ich mich volltexten lasse vom Gebrauchtwagenverkäufer über die ach so tollen Vorzüge mache ich lieber mal eine Probefahrt. Dann merke ich das Elend schneller und der Tag ist gerettet. :) > Denn > Referenzhandbücher von Programmiersprachen dienen nicht der Verbreitung > der Meinung von Autoren. Sondern sind eher als formale Dokumente zu > betrachten und dienen eher der Grundlage des anschliessenden > Ausprobierens, als dessen Vermeidung. Erst wird die eigene Intuition bemüht. Wenn's dann wirklich nicht mehr weitergeht, dann wird in das Handbuch der neuen Waschmaschine oder das Pamphletmanual vom Smartphone hineingeschaut. Mach ich bei Software ebenso. Krude zu bedienende Software kann mir gestohlen bleiben. Zumindest solange es Alternativen gibt. Software auf die sich die Anwender einstellen muss, weil man sämtliche bekannten Bedienkonzepte und Konventionen bricht oder ignoriert lasse ich meistens links liegen. Für jede Regel gibt es natürlich wie immer auch Ausnahmen. > Die Syntax von Deklarationen in C ist grauenhaft. > http://blog.golang.org/gos-declaration-syntax > Tragischerweise wurden die Pointer nicht gerade gebogen. Wie dort > ebenfalls bedauert wird. Danke, werde da mal reinschauen.
A. K. (prx) schrieb: prg schrieb: >> Nicht wenn man sich an die Schreibweise des K&R (2. Ausgabe) hält. >> Ich finde dort keine einzige Textstelle, die den Inhaltoperator (*) dem >> Variablentyp beistellen würde. > Bei K&R nicht. Aber in C++ findet sich die Schreibeweise "Typ& Var" > ausgesprochen häufig. Direkt neben "Typ *Var". ;-) Wie gut dass der Jörg "C" schrieb. ;-)
prg schrieb: > Das ist wohl wahr. Allein das Beharren auf der öffenden Klammer in der > gleichen Zeile gefällt mir nicht. Gefällt mir auch nicht, obwohl mir das noch nicht aufgefallen ist, da ich die öffnende Klammer sowieso immer ans Ende der dem Block vorangehenden Zeile schreibe ;-) Das Weglassendürfen des Semikolons finde ich in Ordnung, aber die Regeln dafür, wann es automatisch eingefügt wird, erzwingen IMHO zu sehr einen bestimmten Schreibstil. Das kann zwar gewollt und von Vorteil sein, dann hätten man aber auch konsequenterweise auch vorschreiben müssen, ob mit Spaces oder Tabs eingerückt wird (und auch noch ein paar andere Dinge). prg schrieb: > Ebenso wozu eine nachgestellte Typinfo > > var zahl int > > Welchen Vorteil soll das bringen? Die Hintergründe dafür wurden schon genannt bzw.verlinkt: http://blog.golang.org/gos-declaration-syntax Tatsächlich ist über die Deklarationssyntax von C schon viel gescholten worden, vor allem von Pascal-Programmierern, die die Reihenfolge andersherum gewohnt sind. Jeder muss für sich entscheiden, welche Form er bevorzugt. Ich komme eigentlich mit beiden gut zurecht.
Yalu X. schrieb: > Tatsächlich ist über die Deklarationssyntax von C schon viel gescholten > worden, vor allem von Pascal-Programmierern, die die Reihenfolge > andersherum gewohnt sind. Das Problem ist nicht links-rechts vs rechts-links. Sondern dass C es mal so mal so hält. Die dadurch entstehende vorrangsbasierte Schachtelung hat in meiner Erfahrung noch jeden irritiert, der damit in Kontakt kam. > Ich komme eigentlich mit beiden gut zurecht. Man gewöhnt sich dran. Man gewöhnt sich auch daran, in seiner Muttersprache im gleichen Text kunterbunt durcheinander 4 verschiedene Schriftsystemen zu verwenden. Nur macht das es nicht praktischer.
:
Bearbeitet durch User
TriHexagon (Gast) schrieb: prg schrieb: >> Rust ist meiner Meinung nach ähnlich komplex wie C++. Rust hat statt >> nur einem gleich vier verschiedene Zeigertypen, die dann in Form von >> &, ~, @, *, &mut, ~str, ~"" und Co. überall im Code ihre >> Krähenfußabdrücke hinterlassen ... " > Die Information ist doch auch schon veraltet, denn die verschiedenen > Zeigertypen wurden in die stdlib verfrachtet. In der Sprache selbst gibt > es nur noch den owned pointer. Der GC Zeiger ist nun gc:Gc und der > SmartPointer rc:Rc. Nach meiner Meinung die richtige Entscheidung. Kann sein, dass das bereits veraltet ist. Der Kommentar war von 2013. Dannke für den Hinweis. prg schrieb: >> Hmm .. was versteht Rust denn unter "owned_box"? Auf dem Heap erzeugte >> Ressourcen? Kennt das automatisches GC (Mülleinsammeln :)) wie C#/CLR? >> Sieht auf den ersten Blick eigentlich auch recht "C-heimisch" aus mit >> Tendenz Richtung ++. > Ja wird auf den Heap angelegt. GC gibt es mit dem gc:Gc Zeiger. > Bei Lowlevel und Realtime muss man sich halt mit sowas beschäftigen. Wer > sich mit sowas nicht auseinander setzen will, für den ist Java/C#/Go > besser geeignet. Rust soll kein Java 2.0 sein, sondern ein besseres > sauberes C++. Ich habe Rust auch nicht zu Java, sondern eher zu sowas wie Nimrod (kam hier letztens im Forum vor) gerechnet. C# finde durchaus großartig. Wenn man mal die gesamte Entwicklung von C# betrachtet hat das einen beachtlichen Stellenwert sich erkämpft. In alten Forenkommentaren findet man noch oft Genöle, das C# Mono keine Forms kann usw. Kann es aber längst. Ich finde die sind weit gekommen mit der Entwicklung (bei MS ist mir das Voranprechen mit WPF usw. eher zu schnell, als das man da noch mithalten könnte). Ich sehe C# (.NET/Mono) auch grundsätzlich nicht als Gegensatz zu reinen Compilersprachen, sondern als gute Ergänzung. Was nutzt einem beispielsweise so ein go rein praktisch, wenn ich ein "echtes" ;) Windows-Programm (mit komfortabler Ein- und Ausgabe) und eben kein Konsolenprogramm haben möchte? Dann greift man letztlich doch eher wieder zu einem der großen Platzhirsche, mit den fetten (öhem, wollte natürlich sagen gut ausgebauten) Frameworks zurück und schaut, dass mans damit irgendwie hinbekommt. Also muss man das ganze Thema Rust, go, Nimrod usw. sowieso ein bisschen mit Abstand betrachten, zwischem reinem Interesse am Neuen und dem Zurückgreifen bekannter (weil eingeübter) Tools. Hinzu kommt, die Zeit die man in neue Programmiersprachen investiert fehlt einem auf der anderen Seite wieder beim pflegen der Sprachen die man halbwegs kann. Programmieren ist leider nicht wie Fahrrad fahren, nach dem Motto, einmal draufsetzen und dann läufts. Wäre schön, wenn' so wäre. ;)
prg schrieb: > Ich habe Rust auch nicht zu Java, sondern eher zu sowas wie Nimrod (kam > hier letztens im Forum vor) gerechnet. C# finde durchaus großartig. Wenn > man mal die gesamte Entwicklung von C# betrachtet hat das einen > beachtlichen Stellenwert sich erkämpft. ... Na da bin ich allerdings deiner Meinung. Habe selbst mit C# angefangen zu programmieren und mir hat es sicherlich nicht geschadet. Der Wechsel zu den nativen Sprachen war da auch kein Problem. Da habe ich dich wohl falsch eingeschätzt, dachte du wärst einer dieser "ich will nicht über den Tellerrand schauen" Java Anhänger. Sorry :).
prg schrieb: >> Bei C hast du nämlich das Problem bei Zeigern: > >> char* foo, bar, mumble; > > Nicht wenn man sich an die Schreibweise des K&R (2. Ausgabe) hält. > Ich finde dort keine einzige Textstelle, die den Inhaltoperator (*) dem > Variablentyp beistellen würde. Es ist an dieser Stelle genausowenig ein Inhaltsoperator wie es ein Multiplikationsoperator ist. > Im K&R würde folglich stehen > > char *foo, bar, mumble; > > und dann wäre auch klar, hier wird ein > Zeiger auf eine char Variable > und zwei Variablen vom Typ char deklariert. Naja... links steht char. Daß sich rechts irgendwo im Namen auf einmal noch ein wichtiger Teil des Typs versteckt, ist nicht gerade intuitiv. Aber darüber hab ich in dem Forum schon öfter diskutiert. A. K. schrieb: > Bei K&R nicht. Aber in C++ findet sich die Schreibeweise "Typ& Var" > ausgesprochen häufig. Direkt neben "Typ *Var". ;-) In C++ ist meiner Erfahung nach eher "Typ* Var" üblich, und wird auch von Stroustrup durchgängig so benutzt.
Rolf Magnus (Gast) schrieb: prg schrieb: >>> Bei C hast du nämlich das Problem bei Zeigern: >> >>> char* foo, bar, mumble; >> >> Nicht wenn man sich an die Schreibweise des K&R (2. Ausgabe) hält. >> Ich finde dort keine einzige Textstelle, die den Inhaltoperator (*) dem >> Variablentyp beistellen würde. > Es ist an dieser Stelle genausowenig ein Inhaltsoperator wie es ein > Multiplikationsoperator ist. Natürlich ist es ein Inhaltsoperator, was sonst?! So ist nun mal die korrekte (eingedeutschte) Bezeichnung für das '*' Symbol im Zusammenhang mit Zeigern. Oder möchtest du es in ein "Pointeroperator" umtaufen? Das Gegenstück dazu '&' heißt übrigens Adressoperator im Zusammenhang mit Zeigerarythmetik. >> Im K&R würde folglich stehen >> >> char *foo, bar, mumble; >> >> und dann wäre auch klar, hier wird ein >> Zeiger auf eine char Variable >> und zwei Variablen vom Typ char deklariert. > Naja... links steht char. Richtig. Char und eben NICHT CharPOINTER! " Char* " in C. > Daß sich rechts irgendwo im Namen auf einmal > noch ein wichtiger Teil des Typs versteckt, ist nicht gerade intuitiv. Das ist kein Argument. An C/C++ ist vieles nicht intuitiv, sondern einfach definiert, dafür aber zweckmäßig und obendrein nützlich, wenn auch nicht immer schön. > Aber darüber hab ich in dem Forum schon öfter diskutiert. Und du fachst die Diskussion hier unnützerweise wieder an! Halten wir uns doch einfach an den K&R. Dann braucht es solche Diskussionen nicht.
prg schrieb: > Natürlich ist es ein Inhaltsoperator, was sonst?! So ist nun mal die > korrekte (eingedeutschte) Bezeichnung für das '*' Symbol im Zusammenhang > mit Zeigern. Oder möchtest du es in ein "Pointeroperator" umtaufen? Nein. Den Inhaltsoperator den du meinst, dereferenziert Zeiger. Also:
1 | *num = 12; |
Der unterscheidet sich aber von der Definition mit * völlig:
1 | int *num; |
TriHexagon (Gast) schrieb: > Nein. Den Inhaltsoperator den du meinst, dereferenziert Zeiger. Also: > *num = 12; > Der unterscheidet sich aber von der Definition mit * völlig: > int *num; Es ist und bleibt dennoch der Inhaltsoperator (solange wir über Zeiger reden). Ob man damit einen Zeiger deklariert oder dereferenziert ändert nichts daran. Es geht hier um den Sprachgebrauch des Symbols und dieser ist so determiniert.
TriHexagon schrieb: > Nein. Den Inhaltsoperator den du meinst, dereferenziert Zeiger. > > Also: > > *num = 12; > > Der unterscheidet sich aber von der Definition mit * völlig: > > int *num; "Völlig" ist ein Bisschen übertrieben :) Die Zeilen
1 | int *num; |
2 | *num = 12; |
können gelesen werden als "Der Inhalt des Zeigers num ist vom Typ int und dem Inhalt des Zeigers num wird 12 zugewiesen." Du siehst, dass *num in beiden Fällen gleich in Prosatext übersetzt wird. Die Idee dieser impliziten Schreibweise ist, für Deklaratoren die gleiche Syntax wie für Ausdrücke zu verwenden.
prg schrieb: >>> und dann wäre auch klar, hier wird ein >>> Zeiger auf eine char Variable >>> und zwei Variablen vom Typ char deklariert. > >> Naja... links steht char. > > Richtig. Char und eben NICHT CharPOINTER! " Char* " in C. Genau das meine ich doch. Es ist ein charPOINTER, was da definiert wird, und eben nicht ein char. Links steht aber nur char, also fehlt dort ein wichtiger Teil des Typs. >> Daß sich rechts irgendwo im Namen auf einmal >> noch ein wichtiger Teil des Typs versteckt, ist nicht gerade intuitiv. > > Das ist kein Argument. An C/C++ ist vieles nicht intuitiv, sondern > einfach definiert, dafür aber zweckmäßig und obendrein nützlich, wenn > auch nicht immer schön. Was soll daran zweckmäßig sein, wenn es nicht intuitiv ist? Das ist doch der einzige Zweck des Ganzen. Ich habe in den letzten fast 20 Jahren aber so viele Fragen in Newsgroups und Foren mit Verständnisproblemen zu dem Thema gelesen, daß ich es für wenig zweckmäßig halte. Auf den ersten Blick wirkt es nämlich intuitiv, aber für das Gesamtverständnis von Zeigern in C ist es eher hinderlich. >> Aber darüber hab ich in dem Forum schon öfter diskutiert. > > Und du fachst die Diskussion hier unnützerweise wieder an! Die Diskussion hast du losgetreten, nicht ich. Ich habe nur daran teilgenommen. > Halten wir uns doch einfach an den K&R. Dann braucht es solche > Diskussionen nicht. Dann halten wir uns in C++ einfach an den Stroustrup. Da der es anders sieht, können wir ja dann darüber diskutieren, ob die C- oder die C++-Konvention besser ist. ;-) Yalu X. schrieb: > Die Zeilen > int *num; > *num = 12; > > können gelesen werden als > > "Der Inhalt des Zeigers num ist vom Typ int und > dem Inhalt des Zeigers num wird 12 zugewiesen." > > Du siehst, dass *num in beiden Fällen gleich in Prosatext übersetzt > wird. Naja, die erste Zeile definiert was. Und was definiert sie? Etwas, das, wenn man es dereferenziert hätte, zu einem int gefüht hätte. Klingt für mich etwas umständlicher, als zu sagen: "Ich definieren einen Zeiger auf int".
Rolf Magnus schrieb: > Yalu X. schrieb: >> Die Zeilen >> int *num; >> *num = 12; >> ... > > Naja, die erste Zeile definiert was. Und was definiert sie? Etwas, das, > wenn man es dereferenziert hätte, zu einem int gefüht hätte. Klingt für > mich etwas umständlicher, als zu sagen: "Ich definieren einen Zeiger auf > int". Auf solche implizite Schreibweisen stößt es auch in anderen Sprachen, wo sie wirklich nützliche Features darstellen. Sie werden üblicherweise gelsesen als: " Wenn man mit V die Aktion A anwenden würde, käme E heraus." Klar klingen solche Sätze umständlicher als die explizite Aussage "V ist A' auf E angewandt." wobei A' die Aktion A anderherum ausgeführt ist. Trotzdem hat die implizite Schreibweise oft Vorteile, auch wenn dieser bei den C-Deklaration nicht arg in Erscheinung tritt. Wenn man sich aber mit solchen Dingen einmal etwas beschäftigt hat, empfindet man auch die C-Deklarationen nicht mehr als unnatürlich. Ein Beispiel in Python: Diese (noch wenig spektakuläre) Anweisung
1 | x = [a, [b, c]] |
weist der Variable x eine Liste mit zwei Elementen zu, von denen das zweite Element wieder eine Liste ist. Interessanterweise ist aber auch folgende Anweisung legal:
1 | [a, [b, c]] = x |
Das sieht zunächst danach aus, als ob auf der linken Seite eine Liste aufgebaut wird, und dann dieser Liste (die ja, um im C-Jargon zu sprechen, ein R-Value ist) der Wert x zugewiesen wird. Tatsächlich ist das aber eine implizite Zuweisung und sagt aus: "Weise den Variablen a, b und c jeweils einen Wert solcherart zu, dass, wenn man aus diesen Variablen die verschachtelte Liste [a, [b, c]] bilden würde, diese gleich x ist." Dieser Satz klingt ähnlich umständlich wie die in Prosa formulierten Pointer-Deklarationen in C. Dort liegt es daran, dass der Typ der definierten Variable nicht direkt benannt wird, und hier sind es eben die den Variablen a, b und c zugewiesenen Werte, die nicht direkt benannt werden. So, wie der Stern in der C-Deklaration die rechts davon stehende Variable nicht dereferenziert, erzeugen die eckigen Klammern in der Python-Anweisung auch keine Liste. Vielmehr bilden in diesem Fall sowohl der Stern als auch die eckigen Klammern zusammen mit den Variablennamen eine Art Muster, das angibt, was mit den Variablen zu tun ist. Der der obigen Anweisung (weitgehend) äquivalente Satz von expliziten Zuweisungen würde so
1 | a = x[0] |
2 | b = x[1][0] |
3 | c = x[1][1] |
aussehen und ist auch für einen Python-Unkundigen sofort verständlich. Trotzdem würde ich in diesem Fall ganz klar die implizite den expliziten Zuweisungen vorziehen, weil sie nicht nur kürzer ist, sondern vor allem auch visuell darstellt, wo die drei Werte aus der verschachtelten Liste x herausgepickt werden. Diese Schreibweise heißt in Python offiziell Iterable Unpacking und ist in stark verallgemeinerter Form auch in funktionalen Sprachen als Pattern Matching zu finden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.