To whom it may concern:
“I made up the term ‘object-oriented’, and I can tell you I didn’t have C++ in mind.” ~ Alan Kay
“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.” ~ Alan Kay
Die Klasse List in Python programmieren
- pillmuncher
- User
- Beiträge: 1484
- Registriert: Samstag 21. März 2009, 22:59
- Wohnort: Pfaffenwinkel
In specifications, Murphy's Law supersedes Ohm's.
"Premature optimization is the root of all evil." ~ Donald E. Knuthpillmuncher hat geschrieben: ↑Dienstag 25. Mai 2021, 02:41 To whom it may concern:
“I made up the term ‘object-oriented’, and I can tell you I didn’t have C++ in mind.” ~ Alan Kay
“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.” ~ Alan Kay
"Our job is to remind us that there are more contexts than the one that we’re in — the one that we think is reality." ~ Alan Kay
Ich mag ja immer mir vorzustellen, wie solche Fälle wohl außerhalb dieses Forums passieren würden.
Da kommt ein Mensch mit seinem Auto in die Werkstatt und sagt: "Hey, ich habe mir hier mal einer eigenen Kolben gebaut, geht das so? Ich habe früher nur an Motorrädern geschraubt und vielleicht kann hier mal jemand drauf schauen?"
Und weil alle Motorräder und Autos kennen, ist das Thema schnell erledigt und alle sind glücklich.
Und dann kommt 3 Monate später jemand mit einer Dampfmaschine durch die Tür und will es damit noch einmal erklären...
Da kommt ein Mensch mit seinem Auto in die Werkstatt und sagt: "Hey, ich habe mir hier mal einer eigenen Kolben gebaut, geht das so? Ich habe früher nur an Motorrädern geschraubt und vielleicht kann hier mal jemand drauf schauen?"
Und weil alle Motorräder und Autos kennen, ist das Thema schnell erledigt und alle sind glücklich.
Und dann kommt 3 Monate später jemand mit einer Dampfmaschine durch die Tür und will es damit noch einmal erklären...
- __blackjack__
- User
- Beiträge: 13112
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@LukeNukem: Die C-Standardbibliothek in der C++-Standardbibliothek ist teilweise überflüssig, ja. Nämlich da wo die C++ als Sprache oder die C++-Standardbibliothek eigenes hat was das gleiche macht. Du hast ja beispielsweise bei der Ausgabe auch den C++-Weg gewählt statt `printf()` zu verwenden.
Was wäre denn für Dich ein Grund `malloc()` in C++ zu verwenden? Und warum trifft der in diesem Beispiel zu? Hast Du beim Beispiel in C++ dann ja auch nicht gemacht.
Was wäre denn für Dich ein Grund `malloc()` in C++ zu verwenden? Und warum trifft der in diesem Beispiel zu? Hast Du beim Beispiel in C++ dann ja auch nicht gemacht.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Das ist zweifellos nicht ganz flashc, man hätte einige der alten Zöpfe abschneiden können. Allerdings war die Abwärtskompatibilität zu C eines der wesentlichen Designziele von C++ und ist bis heute zweifellos einer der wichtigsten Gründe, warum C++ so erfolgreich ist. Und dann...__blackjack__ hat geschrieben: ↑Dienstag 25. Mai 2021, 20:29 @LukeNukem: Die C-Standardbibliothek in der C++-Standardbibliothek ist teilweise überflüssig, ja. Nämlich da wo die C++ als Sprache oder die C++-Standardbibliothek eigenes hat was das gleiche macht.
Ja, weil mein Beispielcode auf einem fetten Eisen läuft. Denn auch mit Optimierung mit -Os und strip(1) ist das C++-Binary laut size(1) wesentlich größer, das C-Binary ist hier "a" und das C++-Binary "b":__blackjack__ hat geschrieben: ↑Dienstag 25. Mai 2021, 20:29 Du hast ja beispielsweise bei der Ausgabe auch den C++-Weg gewählt statt `printf()` zu verwenden.
Code: Alles auswählen
text data bss total filename
621 1803 8 2432 a
1533 3795 280 5608 b
Übrigens, für den Fall, daß jemand von Euch sich mal in dem anderen Forum umsehen möchte: Python ist dort von der Moderation und vielen Anwendern zwar wohlgelitten und oft auch gerne gesehen, allerdings gibt es dort noch eine sehr hartnäckige Fraktion, für die Python pures Teufelszeug ist. Die Syntax mit dem Whitespace, das ist ja wie Fortran77, und überhaupt ist Python viel zu langsam und zu bloaty und zu unverstanden und alle, die Python mögen, sind irgendwelche pickeligen Skriptkiddies, die es nicht besser können und ihren Code sowieso nur zusammenkopieren, ohne ihn zu verstehen. Okay, das wird dort auch gerne über Arduino und Co. gesagt, und, ach ja: Micropython ist natürlich eine Ausgeburt der Hölle! Nur daß Ihr Bescheid wißt, nicht daß es hinterher heißt, ich hätte Euch nicht gewarnt.
Hier? Weil ich's kann -- und weil ich etwas zeigen wollte, nämlich die Idee hinter der Objektorientierung. Da wollte ich nicht, daß der Code zu weit von einander abweicht, um halbwegs vergleichbar zu bleiben. Auf einem AtTiny gehen natürlich auch Funktionen wie (s)printf() nicht so wirklich, das Parsen des Formatstrings und die Verarbeitung von varargs sind viel zu teuer -- deswegen muß man auf größeren AVRs dann auch derlei Funktionen mit eigenen Compilerschaltern ausdrücklich aktivieren. Ähnliches gilt für malloc()... bei 64 Byte (nicht KByte, Byte!) RAM kannst Du dynamische Speicherallokation und Ähnliches gepflegt knicken, und auch auf größeren AVRs ist das eine ziemlich riskante Nummer. Nicht selten steht der Entwickler in solchen Fällen dann vor der Aufgabe, externen Arbeitsspeicher anzubinden und bestimmte Codesegmente mit eigenen Linkerskripten in diesen externen Speicher zu verschieben, siehe dazu beispielsweise auch: https://www.nongnu.org/avr-libc/user-manual/malloc.html -- HF!__blackjack__ hat geschrieben: ↑Dienstag 25. Mai 2021, 20:29 Was wäre denn für Dich ein Grund `malloc()` in C++ zu verwenden?
- __blackjack__
- User
- Beiträge: 13112
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@LukeNukem: Du hast hier doch aber gar kein `malloc()` in C++ verwendet, sondern in C. Der Code verwendet nichts was C++ erfordert. Da jetzt ohne Not einen C++-Compiler statt einen C-Compiler zu verwenden, nur um behaupten zu können der Typcast ist nicht überflüssig, wäre ziemlich sinnlos.
Ebenso das Zielsystem auf etwas zu beschränken was überhaupt nichts mit dem zu tun hat, was Du mit Deinem Code zeigen wolltest und wo man oft gar nicht mit C oder C++ auskommt, sondern auf Nicht-Standarderweiterungen angewiesen ist, und nicht alle Eigenschaften der Sprache und/oder Standardbibliothek sinnvoll nutzen kann.
Ebenso das Zielsystem auf etwas zu beschränken was überhaupt nichts mit dem zu tun hat, was Du mit Deinem Code zeigen wolltest und wo man oft gar nicht mit C oder C++ auskommt, sondern auf Nicht-Standarderweiterungen angewiesen ist, und nicht alle Eigenschaften der Sprache und/oder Standardbibliothek sinnvoll nutzen kann.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Das wäre ziemlich sinnlos, da hast Du Recht. Bedauerlicherweise sind Entwickler im professionellen Umfeld aber nicht selten an bestimmte Werkzeuge gebunden. Das habe ich Dir schon einmal zu erklären versucht, aber zu meinem Bedauern ist das leider nicht angekommen.__blackjack__ hat geschrieben: ↑Donnerstag 27. Mai 2021, 06:35 @LukeNukem: Du hast hier doch aber gar kein `malloc()` in C++ verwendet, sondern in C. Der Code verwendet nichts was C++ erfordert. Da jetzt ohne Not einen C++-Compiler statt einen C-Compiler zu verwenden, nur um behaupten zu können der Typcast ist nicht überflüssig, wäre ziemlich sinnlos.
... und wenn Du mal groß bist, Frau Oberlehrin, verstehst Du bestimmt auch irgendwann, was der Unterschied zwischen einer Erklärung und echtem Code ist. Ist ja nicht schlimm, daß das noch eine Weile dauern wird...__blackjack__ hat geschrieben: ↑Donnerstag 27. Mai 2021, 06:35 Ebenso das Zielsystem auf etwas zu beschränken was überhaupt nichts mit dem zu tun hat, was Du mit Deinem Code zeigen wolltest und wo man oft gar nicht mit C oder C++ auskommt, sondern auf Nicht-Standarderweiterungen angewiesen ist, und nicht alle Eigenschaften der Sprache und/oder Standardbibliothek sinnvoll nutzen kann.
- __blackjack__
- User
- Beiträge: 13112
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@LukeNukem: Das Entwickler in anderen Kontexten an bestimmte Werkzeuge gebunden sind, ist hier völlig irrelevant. Es ist hier Deine freie Entscheidung C-Quelltext mit einem C++-Compiler zu übersetzen. Und der einzige Grund ist das Du nicht davon ablassen willst das der Typcast unnötig ist.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Für Dich in Deinem Elfenbeintürmchen vielleicht, für mich aber nicht.__blackjack__ hat geschrieben: ↑Donnerstag 27. Mai 2021, 07:15 @LukeNukem: Das Entwickler in anderen Kontexten an bestimmte Werkzeuge gebunden sind, ist hier völlig irrelevant.
Korrekt, und das werde ich auch weiterhin so machen. Denn sogar die C-FAQ sagt ja, es sei eine Frage des Stils ("a matter of style"). Da ich nicht in einem Elfenbeintürmchen sitze, sondern robusten und kompatibel Code entwickle, der auf ganz verschiedenen Systemen übersetzt werden und laufen muß, ist und bleibt es mein Style, das Ergebnis von malloc(3) zu casten. Der Compiler meckert es übrigens auch nicht einmal mit -Wall -Wextra und -Wpedantic an und das erzeugte Binary funktioniert ganz wunderbar. Ansonsten, was "Modern C" und ähnliche Empfehlungen angeht... ach Gottchen, ich mach' dieses Programmierzeugs ja schon ein bisschen länger und weiß daher, daß übermorgen ein "Supermodern C" herauskommt, das den Cast wieder empfiehlt.__blackjack__ hat geschrieben: ↑Donnerstag 27. Mai 2021, 07:15 Es ist hier Deine freie Entscheidung C-Quelltext mit einem C++-Compiler zu übersetzen.
Wie gesagt, hängt das vom Compiler ab. Und in meiner Welt, wo Compiler manchmal eine Menge Geld kosten und trotzdem nicht fehlerfrei sind, gibt es tatsächlich Kunden und Umgebungen, in denen es nur einen C++-Compiler gibt, weil man sich die Lizenzkosten sowie die Deployment- und Pflegeaufwände für einen C-Compiler sparen wollte. Mein Code ist daher maximal kompatibel und kann fehlerfrei und ohne Änderungen mit einem C- oder eben auch mit einem C++-Compiler übersetzt werden, und deswegen ist der Cast keinesfalls überflüssig, sondern sinnvoll -- und ob Du das verstehen oder lieber doof finden willst, ist dabei völlig unerheblich.__blackjack__ hat geschrieben: ↑Donnerstag 27. Mai 2021, 07:15 Und der einzige Grund ist das Du nicht davon ablassen willst das der Typcast unnötig ist.
Nebenbei sind wir hier im Forum zu einer anderen Sprache, zu deren Zen (PEP20) auch der Leitsatz "Explicit is better than implicit" gehört. Und ich finde, das ist ein ganz guter Leitsatz nicht nur für Python, sondern auch für andere Sprachen. Das kannst Du ja gerne anders sehen, aber das ist dann eben Deine Sache und für mich eher unerheblich. Ansonsten hielte ich es allerdings für ausgesprochen wünschenswert, wenn Du zukünftig auch mal ausnahmsweise auf die Fragen der TOs eingehen könntest, anstatt unser aller Zeit mit überflüssigen (und in diesem Fall sogar unsinnigen) Off-Topic-Klugscheißereien zu vergeuden. Obwohl ich noch gar nicht so lange hier bin, ist das jetzt schon der zweite Thread, den Du mit diesem Kinderkram zerstörst. Wie schade, daß Du mit Deiner Freizeit wirklich nichts Konstruktiveres anzufangen weißt.
Für Dich in Deinem Elfenbeintürmchen vielleicht, für mich aber nicht.__blackjack__ hat geschrieben: ↑Donnerstag 27. Mai 2021, 07:15 @LukeNukem: Das Entwickler in anderen Kontexten an bestimmte Werkzeuge gebunden sind, ist hier völlig irrelevant.
Korrekt, und das werde ich auch weiterhin so machen. Denn sogar die C-FAQ sagt ja, es sei eine Frage des Stils ("a matter of style"). Da ich nicht in einem Elfenbeintürmchen sitze, sondern robusten und kompatiblen Code entwickle, der auf ganz verschiedenen Systemen übersetzt werden und laufen muß, ist und bleibt es mein Style, das Ergebnis von malloc(3) zu casten. Der Compiler meckert es übrigens auch nicht einmal mit -Wall -Wextra und -Wpedantic an und das erzeugte Binary funktioniert ganz wunderbar. Ansonsten, was "Modern C" und ähnliche Empfehlungen angeht... ach Gottchen, ich mach' dieses Programmierzeugs ja schon ein bisschen länger und weiß daher, daß übermorgen ein "Supermodern C" herauskommt, das den Cast wieder empfiehlt.__blackjack__ hat geschrieben: ↑Donnerstag 27. Mai 2021, 07:15 Es ist hier Deine freie Entscheidung C-Quelltext mit einem C++-Compiler zu übersetzen.
Wie gesagt, hängt das vom Compiler ab. Und in meiner Welt, wo Compiler manchmal eine Menge Geld kosten und trotzdem nicht fehlerfrei sind, gibt es tatsächlich Kunden und Umgebungen, in denen es nur einen C++-Compiler gibt, weil man sich die Lizenzkosten sowie die Deployment- und Pflegeaufwände für einen C-Compiler sparen wollte. Mein Code ist daher maximal kompatibel und kann fehlerfrei und ohne Änderungen mit einem C- oder eben auch mit einem C++-Compiler übersetzt werden, und deswegen ist der Cast keinesfalls überflüssig, sondern sinnvoll -- und ob Du das verstehen oder lieber doof finden willst, ist dabei völlig unerheblich.__blackjack__ hat geschrieben: ↑Donnerstag 27. Mai 2021, 07:15 Und der einzige Grund ist das Du nicht davon ablassen willst das der Typcast unnötig ist.
Nebenbei sind wir hier im Forum zu einer anderen Sprache, zu deren Zen (PEP20) auch der Leitsatz "Explicit is better than implicit" gehört. Und ich finde, das ist ein ganz guter Leitsatz nicht nur für Python, sondern auch für andere Sprachen. Das kannst Du ja gerne anders sehen, aber das ist dann eben Deine Sache und für mich eher unerheblich. Ansonsten hielte ich es allerdings für ausgesprochen wünschenswert, wenn Du zukünftig auch mal ausnahmsweise auf die Fragen der TOs eingehen könntest, anstatt unser aller Zeit mit überflüssigen (und in diesem Fall sogar unsinnigen) Off-Topic-Klugscheißereien zu vergeuden. Obwohl ich noch gar nicht so lange hier bin, ist das jetzt schon der zweite Thread, den Du mit diesem Kinderkram zerstörst. Wie schade, daß Du mit Deiner Freizeit wirklich nichts Konstruktiveres anzufangen weißt.
- __blackjack__
- User
- Beiträge: 13112
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
Die „explizit is better“-Zen-Zeile ist sicher nicht als Begründung für unnötige Redundanz gedacht. Analog würde man damit sonst auch etwas wie ``name = str("Paul")`` oder ``answer = int(42)`` begründen können. Der Datentyp steht in dem C-Quelltext bereits einmal explizit da, es gibt also keinen sinnvollen Grund den noch zwei mal unnötig in der Zeile zu wiederholen.
Es ist kein Elfenbeinturm wenn man nicht irgendeine Nische zum Massstab nimmt, sondern die üblichen C-Compiler. Welche C-Compiler brauchen an der Stelle einen cast? Ich kenne da nur welche die kein ``void*`` unterstützen, und wo `malloc()` deshalb ein Ergebnis vom Typ ``char*`` liefert. Ist mir selbst schon über den Weg gelaufen — auf dem C64. Das ist kein sinnvoller Grund C grundsätzlich so zu schreiben, dass der heute noch auf einem K&R C-Compiler auf einem C64 übersetzbar wäre.
Ich habe echt herzlich über den Inhalt des letzten Absatzes gelacht. Danke dafür. Und nun bitte einmal in den Spiegel schauen und die eigenen Ratschläge beherzigen. Danke.
Es ist kein Elfenbeinturm wenn man nicht irgendeine Nische zum Massstab nimmt, sondern die üblichen C-Compiler. Welche C-Compiler brauchen an der Stelle einen cast? Ich kenne da nur welche die kein ``void*`` unterstützen, und wo `malloc()` deshalb ein Ergebnis vom Typ ``char*`` liefert. Ist mir selbst schon über den Weg gelaufen — auf dem C64. Das ist kein sinnvoller Grund C grundsätzlich so zu schreiben, dass der heute noch auf einem K&R C-Compiler auf einem C64 übersetzbar wäre.
Ich habe echt herzlich über den Inhalt des letzten Absatzes gelacht. Danke dafür. Und nun bitte einmal in den Spiegel schauen und die eigenen Ratschläge beherzigen. Danke.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Robusten und kompatiblen Code zu schreiben ist eine Nische? Lustig.__blackjack__ hat geschrieben: ↑Freitag 28. Mai 2021, 10:15 Es ist kein Elfenbeinturm wenn man nicht irgendeine Nische zum Massstab nimmt
- __blackjack__
- User
- Beiträge: 13112
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@LukeNukem: Ja lustig, habe ich aber nicht behauptet.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman