Die Klasse List in Python programmieren

Du hast eine Idee für ein Projekt?
Benutzeravatar
__blackjack__
User
Beiträge: 12984
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.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
LukeNukem
User
Beiträge: 232
Registriert: Mittwoch 19. Mai 2021, 03:40

__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: 12984
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.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
LukeNukem
User
Beiträge: 232
Registriert: Mittwoch 19. Mai 2021, 03:40

__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: 232
Registriert: Mittwoch 19. Mai 2021, 03:40

__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: 12984
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. 🙂
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
LukeNukem
User
Beiträge: 232
Registriert: Mittwoch 19. Mai 2021, 03:40

__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: 12984
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@LukeNukem: Ja lustig, habe ich aber nicht behauptet.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Antworten