Diese Dinger verursachen am laufenden Band Probleme. Ich habe ja durchaus Spaß daran, wann man auch mal wirklich den eigenen Kopf benutzen muss beim Programmieren, aber Zeiger sind schon eine gewisse Herausforderung.
Edit: Es lag nicht an den Zeigern, sondern daran, dass ich ein paar kleine Fehler in meinem Code hatte, die ich übersehen habe.
c c c ccccc c c c c
Edit: sollte eigentlich nicht scheiße aussehen, hab aber grad kein Bock das zu fixen und ich finde ein kaputter Zeiger in c ist auch ein passendes Symbol hier.
Ich hab das nie so richtig verstanden, warum Zeiger so problematisch sind. Es ist halt eine Referenz auf ein Stück Speicher, über dem ein Datenmodel gespannt liegt. Die einzige Hürde liegt darin, die Verantwortung über das Bestehen dieses Speichers ein wenig zu planen, aber das hat man bei schlauen Zeigern implizit genauso, man muss sie nur nicht selbst wegräumen.
Ich hasse diese Elendigen Dinger halt besonders, wenn ich irgendwas mit
StringsFäden machen will. Es gibt bei der scheiße immer Probleme.Dann wäre vielleicht eine Sprache besser, die echte Fäden unterstützt und nicht nur Zeiger zu Speicher, der halt irgendwann mit
\0
endet.Du meinst die hoffentlich an der richtigen Stelle mit
\0
enden.Hab ich geschrieben. Hat das Markierunter irgendwo versagt?
Ja, behoben. Meinte auch das hoffentlich weil das ja mit C zum Glück nicht garantiert ist. Hab es angepasst um es klarer zu machen.
Ist aber ganz lustig da x86 extra Instruktionen für C Fäden hat.
Fäden
Fäden sind Threads.
Nene, die erkennt man daran, dass sie hingerichtet werden sollen.
String = Faden
Wenn ich die ultimative Quelle allen Wissens und aller Weisheit befrage, scheint der Begriff thread tatsächlich am ehesten dem Faden zu entsprechen, string hingegen der Schnur.
Der Vollständigkeit halber:
yarn = Garn twine = Zwirn rope = Seil
Für Tau finde ich keine Entsprechung im Deutschen, Während cord und cordage ein Oberbegriff für alles Schnurige von Zwirn bis Tauwerk zu sein scheint.
Spanend, wie viele Worte wir für lange, flexible Objekte gaben.
Das hat glaube damit zutun, dass sie auf unterschiedliche Art hergestellt werden. Je nach Endprodukt hat es einen eigenen Namen
Threads sind sowas von Laufmaschen.
Kann mich da nur anschliessen. Wenn es nicht C sein muss, lass es lieber. Klar lernt man viel dabei, aber die Gehirnakrobatik, die man sich dabei aneignet, ist sonst nirgends mehr anwendbar.
Das bösartige an Zeigern ist, dass sie nicht einfach nur ein Datentyp sind. Sondern ein Datentyp der verschiedene Datentypen haben kann. Man kann sie nicht einfach nur auf irgendeinen Speicherplatz zeigen lassen, sondern auf einen Speicherplatz mit einem Inhalt bestimmten Datentyps. Der aber dann implizit definiert ist, damits schwerer zu durchblicken ist.
So gesehen ist das nicht einmal ein Datentyp, sondern einfach ein Ganzzahlwert mit einer von der Architektur abhängigen Bitlänge, der die Adresse des referenzierten Speichers beginnend mit 0x0 angibt. Daran ist nichts bösartig und man lässt sie nicht irgendwo, denn der Zeiger selbst kennt keinerlei Datentyp, auf den er zeigt. Und um das implizite ein wenig zu lindern, existieren ja Macros und Unions.
Edith: *zeigen lassen
Schlaue Zeiger sind auch kein Problem. Das Problem bei rohen Zeigern ist, wie du schon sagtest, das Management. Man muss halt immer im Blick haben wann und ob der Zeiger befreit werden muss.
Wir hatten vorhin auf der Arbeit grad ein Arbeitsspeicherleck, weil in einer Schleife ein Zeiger von einer Bibliothek kam und der Zeiger nicht befreit wurde
Sowas lässt sich ganz gut mit statischer als auch dynamischer Quellcodeanalyse finden. Speicherlecks entdecke ich meist zuverlässig mit valgrind und Rennbedingungen über den Fadenreiniger von gcc.
Selbst in JavaScript beißen mich Objektreferenzen gelegentlich. Ich glaube, das Problem ist darin begründet, dass man – anders als bei einer lokalen Variable – nicht mehr Alleinherrscher über die Daten ist und damit rechnen muss, dass sie andernorts verändert werden.
Oder man geht davon aus, dass eine kopierende Operation die Daten kopiert statt nur einen Zeiger. Dann wundert man sich später, warum Dinge, die unterschiedlich sein sollten, gleich sind.
Du siehst halt lokal nicht wo überall ein Zeiger drauf sein könnte sondern musst den Code durchgucken
void **ptr;
wie wäre es mit Zeiger Zeiger?
void ** (**ptr)();
Wie wäre es mit Zeiger Zeiger auf eine Methode die einen Zeiger Zeiger zurück gibt? Ich liebe C
const char * const (* const foo)[](void *[]);
Ich weiß gar nicht was du meinst. Macht doch Sinn /s
Tatsächlich hat D es geschaft die C Deklarationen ordentlich aufzuräumen ohne den Syntax groß zu ändern wie bspw. Rost. Dafür hat sich D aber leider an anderer Stelle gewaltig das Genick gebrochen.
Nämlich an welcher?
Wenn es nur eine Sprache gäbe, mit der Pointer effizient weg abstrahiert werden, UTF-8 direkt unterstützt wird und die direkt ein Bau und Bibliotheken Management System aus diesem Jahrtausend mit bringt. Ideal wäre natürlich wenn das genauso zu Maschinencode übersetzt wird und damit gleich schnell wie C läuft.
Ist natürlich vollkommen unmöglich, aber man darf träumen.
Zeiger wegabstrahieren heißt Gott spielen. Wer erwartet c++ oder irgendeine andere Sprache löst das Problem, dass Daten im Speicher verteilt sind ist naive. Wer ein Haus in der Stadt kauft kann nicht einfach ein 400m2 Garten DLC herrunterladen.
Fairer Weise, wenn man Zeiger nicht versteht, wird man mit dem Verleih-Prüfer auch nicht klar kommen. Das wird dann auch nur maximal frustrierend sein. Für einen blutigen Anfänger, der sich noch mit Zeigern abmüht ist der gelegentliche Segfault sicher angenehmer, als bei jedem kleinen Fehler, der eventuell aufgrund glücklicher Umstände nicht mal zu Problemen geführt hätte, in Kompilierfehler zu rennen. Als Anfänger hätte ich die wichtige Arbeit des Verleih-Prüfers sicher noch nicht zu schätzen gewusst und wahrscheinlich eher als Gängelung wahrgenommen.
Das gesagt, ich liebe Rost und grade der maschinennahen Programmierung ist es das beste, was ihr seit Ewigkeiten passiert ist. Im
Das gute ist, das der Übersetzter dir hilft statt in C einfach Dinge wegzuoptimieren. Er erklärt warum was nicht erlaubt ist.
Was du prüfst ob der Zeiger null ist. Darf er nicht sein, weg damit. Viel Spaß mit dem Speicherfehler. 👋
Kleiner Trick aus der Industrie, einfach die Entkäfer Version ausliefern. Dann funktioniert sogar mein Code!
Bei uns wird ein Programm mit MS C Compiler 98 übersetzt, weil mit neueren Compiler das Programm nicht mehr läuft.
Denn es wird mit volatile Thread Synchronisierung betrieben. 🥴
Ich weiss heute noch nicht, wie man eine bidirektionale verkettete Liste baut (in sicherem Rost meine ich nicht möglich) oder Referenzen von anderen Objekten in einem Strukt korrekt Lebenszeit annotiert.
Geht halt mit Pointern. Hab ich schon gemacht. Wo es wirklich spannend wird sind intrinsische verkettete listen (also die Listen Heads sind Teil vom struct, nicht das struct selbst).
Problem ist, dass du immer garantieren musst, dass sich die Addresse der Listenobjekte nicht ändert. Dafür gibt’s Pin, Box, und Versprechen auf Ehre.
Dachte gerade du hättest das „u“ mit einem „o“ verwechselt. Dann merkte ich, ich liege falsch
Kommt das snobbische verhalten die rostige Entwicklys im Kernel an den Tag legen mit der Sprache gratis dazu?
Ja, probiers aus, kommt von selbst.
Mit Rost wäre das nicht passiert. 🤷♂️
Vor allem wollen sie nie schuld an irgendwas sein und zeigen immer auf etwas anderes zum verdächtigen.
Blitzzurücks entschlosst.
Kein C, kein Problem. Wenn man das letzte bisschen Performance nicht braucht und nicht durch äußere Umstände gezwungen wird, einfach was anderes nehmen.
Ich will es ja lernen. Es ist ja schön mal was anderes auszuprobieren, aber die Pointer sind schon ein bisschen komplexer als ich es gewohnt bin.
Ich weiß nicht was du schon kennst, aber ich kann Python und Kotlin empfehlen.
Ich verstehe nicht, warum die Schlange immer wieder zum Einstieg empfohlen wird. Klar, das Hallo Welt ist schön einfach und für viele Probleme gibt es schon fertige Bibliotheken.
Ich finde es aber unglaublich frustrierend vor einem Fehler zu sitzen und nicht zu verstehen wo der herkommt. Da helfen gerade Anfängern aber gute Kompilierer die in Python einfach fehlen. Ich habe lieber zwanzig mal “kann A nicht implizit in B umformen” beim Kompilieren, als unter bestimmten Vorrausetzungen beim Laufen einfach falsche Ergebnisse zu haben und nicht sehen zu können warum.
Als Einstieg finde ich Java nicht schlecht. Das man da alles explizit hinschreiben muss erklärt super Datentypen und saubere objektorientierte Programmierung. Für Erfahrene ist das dann aber etwas ätzend.
Ich bin nicht davon ausgegangen, dass man direkt mit C ins Thema Programmierung einsteigt.
Ich will ja bewusst nicht Python nehmen, weil ich mal was komplexeres ausprobieren will.
Sage mir, dass du ein ich_iel Meme im Fediverse bist ohne mir zu sagen, dass du ein ich_iel Meme im Fediverse bist
Warum gibt es eigentlich keine Referenzen oder Schlauzeiger in C? In C++ gelten unnötige Rohzeiger aus gutem Grund als schlechter Stil.
Das Problem mit Schlauzeigern ist, dass sie zwangsläufig versteckten Kontrollfluss mit sich bringen. Das ist a) mit dem C Syntax meiner Meinung nach nicht einfach machbar ohne Pandoras Büchse ähnlich wie C++ und Rost zu öffnen (nicht, dass das zwangsläufig schlecht ist, aber das ist halt nicht C) und b) auch nicht unbedingt wünschenswert. Eine der schönen Sachen an C ist, dass jeglicher Kontrollfluss direkt vor einem liegt und (fast) nichts passiert, was man nicht direkt sieht. Wenn man mal mit größeren C++ Bibliotheken, die die Möglichkeiten von Klassen und Vorlagen wirklich ausschöpfen, gearbeitet hat, merkt man schon was das doch für ein Segen sein kann.