Die Klasse List in Python programmieren

Du hast eine Idee für ein Projekt?
Benutzeravatar
pillmuncher
User
Beiträge: 1268
Registriert: Samstag 21. März 2009, 22:59
Wohnort: München

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
In specifications, Murphy's Law supersedes Ohm's.
LukeNukem
User
Beiträge: 117
Registriert: Mittwoch 19. Mai 2021, 03:40

Dienstag 25. Mai 2021, 05:47

pillmuncher 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
"Premature optimization is the root of all evil." ~ Donald E. Knuth

"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
Benutzeravatar
sparrow
User
Beiträge: 2740
Registriert: Freitag 17. April 2009, 10:28

Dienstag 25. Mai 2021, 18:46

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...
Benutzeravatar
__blackjack__
User
Beiträge: 8827
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

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. 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.
Q: What is the volume of a pizza of radius z and thickness a?
A: pi·z·z·a
LukeNukem
User
Beiträge: 117
Registriert: Mittwoch 19. Mai 2021, 03:40

Mittwoch 26. Mai 2021, 23:13

__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.
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
Du hast ja beispielsweise bei der Ausgabe auch den C++-Weg gewählt statt `printf()` zu verwenden.
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":

Code: Alles auswählen

       text       data        bss      total filename
       621       1803          8       2432 a
      1533       3795        280       5608 b
Nun, die Dateigrößen unterscheiden sich nicht wesentlich, aber die Größen der einzelnen Segmente sehr wohl. Wie gesagt, auf einer richtigen Maschine spielt das keine Rolle, aber in meiner Freizeit spiele ich manchmal auch gerne mit kleinen 8-Bit-SOC wie den Atmel (jetzt Microchip) AVRs, zum Beispiel dem AtTiny13. Der hat maximal 20 MHz Taktfrequenz, gerade mal ein Kilobyte Flash-Speicher für den Code und nur jeweils 64 Bytes RAM und EEPROM. Du kannst Dir sicherlich vorstellen, daß auf so einem winzigen SOC die Größe der Codesegmente eine wichtige Rolle spielt, weswegen man auf etliche schicke Features von C++ leider verzichten und bei anderen sehr genau darauf achten muß, was und wie man es nutzt. Templates gehen ziemlich gut, aber schon die Vererbung krankt bei zeitkritischen Dingen daran, daß sie für Methodenaufrufe auf die interne Virtual Method Table zugreifen muß, was zwar nicht viele, dennoch aber Prozessortakte kostet. Dynamische Sachen wie Exceptions und die STL kannst Du auf so kleinen Dingern natürlich auch knicken... aber wenn man sich auf die "guten Features" beschränkt, ist der optimierte C++-Code nicht größer als ein äquivalenter C-Code. Diese Umstände sind übrigens der Grund dafür, warum es im Forum von Mikrocontroller.net immer noch häufig zu echauffierten Diskussionen zwischen den Verfechtern von Assembler, C und C++ kommt und der Sinn der Objektorientierung oft immer noch ganz grundsätzlich in Frage gestellt und zum Teil sogar rundheraus abgelehnt wird. Daß es in den Neunzigern einige... Scharlatane gegeben hat, die ihrem alten C-Code lediglich ein paar Klassen spendiert und wie die Maikäfer alles vererbt haben, was nicht schnell genug weglaufen konnte, hat allerdings auch nicht unbedingt zur Popularität oder gar Beliebtheit der OOP in diesen Kreisen beigetragen... :-(

Ü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. ;-)
__blackjack__ hat geschrieben:
Dienstag 25. Mai 2021, 20:29
Was wäre denn für Dich ein Grund `malloc()` in C++ zu verwenden?
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! ;-)
Benutzeravatar
__blackjack__
User
Beiträge: 8827
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

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.

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.
Q: What is the volume of a pizza of radius z and thickness a?
A: pi·z·z·a
LukeNukem
User
Beiträge: 117
Registriert: Mittwoch 19. Mai 2021, 03:40

Donnerstag 27. Mai 2021, 06:45

__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.
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
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.
... 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... :-)
Benutzeravatar
__blackjack__
User
Beiträge: 8827
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Donnerstag 27. Mai 2021, 07:15

@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.
Q: What is the volume of a pizza of radius z and thickness a?
A: pi·z·z·a
LukeNukem
User
Beiträge: 117
Registriert: Mittwoch 19. Mai 2021, 03:40

Freitag 28. Mai 2021, 06:53

__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.
Für Dich in Deinem Elfenbeintürmchen vielleicht, für mich aber nicht.
__blackjack__ hat geschrieben:
Donnerstag 27. Mai 2021, 07:15
Es ist hier Deine freie Entscheidung C-Quelltext mit einem C++-Compiler zu übersetzen.
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
Und der einzige Grund ist das Du nicht davon ablassen willst das der Typcast unnötig ist.
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.

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.
LukeNukem
User
Beiträge: 117
Registriert: Mittwoch 19. Mai 2021, 03:40

Freitag 28. Mai 2021, 07:54

__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.
Für Dich in Deinem Elfenbeintürmchen vielleicht, für mich aber nicht.
__blackjack__ hat geschrieben:
Donnerstag 27. Mai 2021, 07:15
Es ist hier Deine freie Entscheidung C-Quelltext mit einem C++-Compiler zu übersetzen.
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
Und der einzige Grund ist das Du nicht davon ablassen willst das der Typcast unnötig ist.
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.

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.
Benutzeravatar
__blackjack__
User
Beiträge: 8827
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Freitag 28. Mai 2021, 10:15

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. 🙂
Q: What is the volume of a pizza of radius z and thickness a?
A: pi·z·z·a
LukeNukem
User
Beiträge: 117
Registriert: Mittwoch 19. Mai 2021, 03:40

Freitag 28. Mai 2021, 12:45

__blackjack__ hat geschrieben:
Freitag 28. Mai 2021, 10:15
Es ist kein Elfenbeinturm wenn man nicht irgendeine Nische zum Massstab nimmt
Robusten und kompatiblen Code zu schreiben ist eine Nische? Lustig. ;-)
Benutzeravatar
__blackjack__
User
Beiträge: 8827
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Freitag 28. Mai 2021, 17:42

@LukeNukem: Ja lustig, habe ich aber nicht behauptet.
Q: What is the volume of a pizza of radius z and thickness a?
A: pi·z·z·a
Antworten