Welche Videoanleitung, Seiten, Bücher etc. nutzt ihr zum Nachschlagen, wenn es um Expertenthemen geht?
Zum Thema Pointer, -auf Funktionen
z. B. :
Was ist daran "abstract"?
Lern C und hör auf rum zu heulen!
Wenn man C kann, ist das nix Besonderes.
Welche Videoanleitung, Seiten, Bücher etc. nutzt ihr zum Nachschlagen, wenn es um Expertenthemen geht? Zum Thema Pointer, -auf Funktionen
Ich benutze immer https://en.cppreference.com/w/c/language/operator_precedence, wenn ich unsicher bin, ob das Sternchen den Pfeil schlägt ...
LG, Sebastian
unsicher bin, ob das Sternchen den Pfeil schlägt ...
Dann musst du wohl noch etwas mehr lernen.
Dann musst du wohl noch etwas mehr lernen.
Lebenslanges lernen, mein Motto. Aber bei Sternchen und Pfeil hab ich aufgegeben und schlag es lieber jedesmal nach ...
LG, Sebastian
Jedes C-Buch mit Inhalts- und Stichwortverzeichnis ist dazu geeignet. Auch Google und Wikipedia. Dazu ein C-compiler für Kommandozeile oder sonstige niederschwellige Möglichkeit zur Ausgabe. Und einen echten Anwendungsfall
Sowas per Video "auf Vorrat" zu lernen, macht wenig Sinn. Und ein passendes Video zu finden, ist wenig aussichtsreich. Man kann Text und Bilder überfliegen aber nicht Video.
Sowas per Video "auf Vorrat" zu lernen, macht wenig Sinn.
Vermutlich ist der Grund dafür: Wenn jemand besser "auf Vorrat" lernen kann, wird er Jurist. Wenn jemand besser aus seinen Fehlern lernen kann, wird er Entwickler.
Und wenn jemand beides kann, wird er Wissenschaftler.
Max schrieb:
Welche Videoanleitung, Seiten, Bücher etc. nutzt ihr zum Nachschlagen, wenn es um Expertenthemen geht? Zum Thema Pointer, -auf Funktionen
Ich benutze immer https://en.cppreference.com/w/c/language/operator_precedence, wenn ich unsicher bin, ob das Sternchen den Pfeil schlägt ...
LG, Sebastian
Danke das verstehe ich unter Austauschen
Was ist daran "abstract"?
Lern C und hör auf rum zu heulen!
Wenn man C kann, ist das nix Besonderes.
Das verstehe ich nicht unter s. o., jeder gute Mod sollte den Beitrag und den Account mal eine Pause zur Besinnung schenken.
Wenn für die Quadrate auch Rechtecke sein können, finde ich das toll. Vielleicht solltest Du Dir mal richtigen C-Code anschauen, da gibt es halt etwas mehr als aus den 0815 Büchern, die das gefühlte kleine ein mal eins haben.
Ich hoffe, dass das Forum nicht weiterhin missbraucht wird, für Menschen mit einer Persönlichkeit, die als Sie aufbaufähig war, vernachlässigt wurde.
Jedes C-Buch mit Inhalts- und Stichwortverzeichnis ist dazu geeignet. Auch Google und Wikipedia. Dazu ein C-compiler für Kommandozeile oder sonstige niederschwellige Möglichkeit zur Ausgabe. Und einen echten Anwendungsfall
Sowas per Video "auf Vorrat" zu lernen, macht wenig Sinn. Und ein passendes Video zu finden, ist wenig aussichtsreich. Man kann Text und Bilder überfliegen aber nicht Video.
Das sehe ich mal ähnlich, jedoch finde ich das Thema Funktionszeiger in vielen Lehrquellen zu schwach behandelt.
Und C ohne Zeiger, ist wie Kochen ohne Wasser.
Und C ohne Zeiger, ist wie Kochen ohne Wasser.
Dazu müsstest du aber erstmal verstehen, was ein Zeiger (aka Pointer) überhaupt ist. Der ganze Rest erschlösse sich dann automatisch.
Wenn man deine Beiträge hier verfolgt, entsteht aber eher der Eindruck, daß du ein Copy&Paste-Artist mit ADHS-Syndrom bist, der auf der Suche nach einer Programmiersprache ist, die dir das selber denken abnimmt.
Du solltest dich daher besser nach einer Beschäftigung umschauen, die besser zu dir passt - Programmieren ist das jedenfalls sicher nicht.
Das sehe ich mal ähnlich, jedoch finde ich das Thema Funktionszeiger in vielen Lehrquellen zu schwach behandelt.
Deshalb die Einschränkung:
mit Inhalts- und Stichwortverzeichnis
Max schrieb:
Und C ohne Zeiger, ist wie Kochen ohne Wasser.
Richtig mit Wasser kann man Kochen und in der Küche die Uhr hat mehr als zwei Zeiger, welche in eine Richtung zeigen, für dich nämlich ins Bett, mein Jung.
der auf der Suche nach einer Programmiersprache ist, die dir das selber denken abnimmt.
Gutes Stichwort.
Eine KI, die aus einer umgangssprachlichen diffusen Anforderung ein Programm generiert ist zur Zeit das das Thema überhaupt. Microsoft, Amazon, OpenAI usw. stecken da zig Milliarden in die Entwicklung.
Und wir unterhalten uns immer noch darüber, wie wir uns in ein 50 Jahre altes Konzept einarbeiten.
Gast
#7538929
Und wir unterhalten uns immer noch darüber, wie wir uns in ein 50 Jahre altes Konzept einarbeiten.
Das wird noch länger Bestand haben als Du glaubst. Menschliche Kreativität ist so schnell durch nichts zu ersetzen, vor allem nicht durch KI-Nachahmung.
Menschliche Kreativität ist so schnell durch nichts zu ersetzen
Hmmm... "Die Qualität der Entwickler ist in den letzten 20 Jahren so gesunken, das eigene Kreativität bei denen kontraproduktiv ist."
https://www.danisch.de/blog/2021/09/26/stack-heap-fuer-mich-heut-sushi/
Zweifelslos - die Kreativen, die an den KI-Tools arbeiten, lassen sich nicht durch KI ersetzen. Aber die anderen 99,9% klicken sowieso nur Nullachtfünfzehn Anwendungen aus bestehende Libraries zusammen.
Gast
#7538951
Die Qualität der Entwickler ist in den letzten 20 Jahren so gesunken, das eigene Kreativität bei denen kontraproduktiv ist
Mag ja schick sein sich über seine Kollegen (?) so herabzulassen. Entwickler-Qualitäten sind heute eher /andere/.
Aber die anderen 99,9% klicken sowieso nur Nullachtfünfzehn Anwendungen aus bestehende Libraries zusammen.
ZusammenklickenKönnen bedeutet mehr Produktivität und BeherrschbarMachen immer größerer Software-Bauwerke. Die Libraries wiederum fallen nicht vom Himmel.
ZusammenklickenKönnen bedeutet mehr Produktivität und BeherrschbarMachen immer größerer Software-Bauwerke.
Auf den ersten Blick mag das stimmen, aber auf den zweiten Blick schon nicht mehr. Beherrschbar ist so ein aus irgendwelchen irgendwoher "gezogenen" Libraries zusammengeklicktes Produkt nämlich überhaupt nicht, denn dazu müsste der Zusammenklicker ja verstehen, was exakt die "gezogene" Library tut, und nicht nur, was sie nach außen hin tun soll.
Wenn dann die Library selbst wiederum ihre Abhängigkeiten "zieht", versteht der Softwarezusammenklicker erst recht nicht mehr, wozu die jeweils da sind.
Am Ende entsteht ein Moloch, der oberflächlich das tut, was er tun soll, aber bei dem hinter den Kulissen komplett "terra incognita" ist. Schick ist das, wenn ein Fehler auftritt, und der Softwarezusammenklicker damit konfrontriert wird, "seinen" Code zu debuggen.
Es ist halt ein Unterschied, auf einem Computer mit einem Betriebssystem ein Programm perfekt bedienen zu können (sei es MineCraft, Excel oder auch Blender), oder in der Lage zu sein, den Computer selbst zu bauen und das Betriebssystem selbst zu schreiben.
Der erste entspricht jemandem, der verdammt gut auf der Schreibmaschine schreiben kann, der zweite hingegen jemandem, der Schreibmaschinen bauen kann.
In der aktuellen "agilen" CI/CD-Welt des munteren Wir-Klicken-Libraries-zusammen und der dazu passenden "Klicken-nach-Zahlen"-Tutorials entstehend sicher bewundernswert gute Schreibmaschinenschreiber, keine Frage. Die braucht man ja auch, irgendwie.
Wenn jemand besser "auf Vorrat" lernen kann, wird er Jurist.
Wenn er sich außerdem flüssig und ohne Logikfehler zwischen abstrakt und konkret hin und herbewegen kann. Wenn er NUR auswendig lernen kann, wird er Geschichts- oder notfalls Erdkundelehrer. (Was hab ich dieses dämliche Auswendiglernen gehasst. Hat mich fast das Abitur gekostet. Nur meine Noten in Physik und Mathematik und der Respekt meines Deutschlehrers haben mich ganz knapp gerettet.)
Der erste entspricht jemandem, der verdammt gut auf der Schreibmaschine schreiben kann, der zweite hingegen jemandem, der Schreibmaschinen bauen kann.
Der erste kann nur flott tippen. Danach kommt zunächst mal der, der gut denken und einen entsprechenden Text verfassen kann. Dafür muss er kein Techniker sein. Tatsächlich gibt es auf der Welt auch ganz andere Fachgebiete ...
Tatsächlich gibt es auf der Welt auch ganz andere Fachgebiete ...
Das hat ja auch niemand bestritten. Nur sind diejenigen nicht unbedingt dazu geeignet, Software zu entwickeln. Ein Kollege von mir, sollte damals während des Studiums auch was programmieren und hat sich Sachen aus dem Netzu zusammengesammelt. Funktioniert hat das dann aber auch nicht wirklich. Er ist aber ein guter Konstrukteur.
Eine KI, die aus einer umgangssprachlichen diffusen Anforderung ein Programm generiert ist zur Zeit das das Thema überhaupt. Microsoft, Amazon, OpenAI usw. stecken da zig Milliarden in die Entwicklung.
Was genau ist "ein Programm"? Ist das etwas, dessen Funktion verstehbar und beherrschbar und nicht nur beobachtbar ist? Ist das etwas, dessen Funktion man testen (Spec = diffus, ähemm) oder sogar debuggen kann?
Und wir unterhalten uns immer noch darüber, wie wir uns in ein 50 Jahre altes Konzept einarbeiten.
Tja, die Leutchen, die alles Neue per se für überlegen halten.
Auch wenn es leicht OT ist: Ich kenne Konzepte, von denen heute kaum jemand noch den Namen kennt, in die aber alle Großen auf Verdacht viel Geld reingepumpt haben. Vor 30 Jahren waren z. B. sämtliche Computerzeitschriften voll vom Thema "Fuzzy-Logik" - und wer programmiert (außer im Gebiet Regelungstechnik) heute so? Ähnlich war es vor 50 Jahren mit "Forth", einer damals angeblich bald alles überrollende Revolution beim Programmieren.
Das, was die generative KI (OpenAI) heute ist, ist jedenfalls weiter nichts als reines Jonglieren mit im Netz gefundene Fragmenten unter Nutzung von Statistik. Mit Bedeutungen/Inhalten/Intelligenz hat das null Komma nichts zu tun. Das sagen die Schöpfer ja selbst auch, nur lässt sich Lieschen Müller von plakativen Resultaten blenden.
Fakt ist, dass KI als Input Datenmaterial aus dem Internet nutzt. Nicht nur, dass dieses Material schon immer unzuverlässig war, nein, es wird noch unzuverlässiger werden, weil immer mehr KI-Resultate ins Netz gelangen und ihrerseits als Input für KI genutzt werden. Soo toll ist dieses Konzept nun wirklich nicht. Dem könnte man nur entgegenwirken, wenn genügend Input von echten kompetenten Menschen genutzt würde. Mal abgesehen von der Manipulations-Möglichkeit: Wo kommen denn diese Menschen in genügender Anzahl her und wer sucht die aus? Am Ende landen wir womöglich wieder im Mittelalter, da war Schreiber ein geachteter Beruf. Zum Schreiber ging man hin und bezahlte fürs Vorlesen oder für ein Stück beschriebenes Papier. Die Masse konnte weder Lesen noch Schreiben, und sie brauchte das für ihren Alltag auch nicht.
Gast
#7539084
Ich habe den Eindruck, das wir bei der Komplexität unserer Software vielfach an Grenzen gestoßen sind. Das Risiko, außer Kontrolle zu geraten, ist vielfach erkennbar. Sehr viele Firmen machen trotzdem so weiter und riskieren viel, weil das der aktuelle Trend im Markt ist.
Ich denke, das wird sich noch einige Jahre so fortsetzen, bis signifikant viele Menschen sich vor Software fürchten und dadurch ein Umdenken stattfindet.
Möglicherweise werden autonome Autos dabei ausschlaggebend sein.
"Back to the roots" wird irgendwann kommen. Ich bin gespannt, ob ich das noch miterleben werde.
Ich habe den Eindruck, das wir bei der Komplexität unserer Software vielfach an Grenzen gestoßen sind.
Das liegt aber nicht per se an dem, was die Software machen soll, sondern an der Art, wie sie mittlerweile gebaut wird.
Sieh Dir mal den "Markt" der Programmiersprachen an. Jede Woche wird eine neue bunte Sau durchs Dorf getrieben, und es gibt immer mehr Programmierer, die ganz wunderbar mit ihrer persönlichen Programmiersprache klarkommen. Und viele dieser Programmiersprachen erfinden munter lustige neue Begriffe für Dinge, die es in anderen Programmiersprachen oder Entwicklungssystemen auch schon gibt.
Und dann hast Du fünf erfahrene Programmierer in einem Raum sitzen, die sich gegenseitig nicht mehr verstehen, weil ihnen gemeinsame Grundlagen fehlen, ja, schon ein gemeinames Vokabular.
Das Risiko, außer Kontrolle zu geraten, ist vielfach erkennbar.
O ja. Babel lässt grüßen.
Gast
#7539123
Sieh Dir mal den "Markt" der Programmiersprachen an. Jede Woche wird eine neue bunte Sau durchs Dorf getrieben, und es gibt immer mehr Programmierer, die ganz wunderbar mit ihrer persönlichen Programmiersprache klarkommen.
Dafuer sollten ja Standards entwickelt werden: Schon 1960(!) wurde COBOL vom amerikanischen Verteidigungsministerium zum Standard gemacht um betriebswirtschaftliche Ablaeufe (vulgo Buchhaltung) standardisiert zu verarbeiten.
Und das wurde in Ausschreibungen gefordert und Cobol wird heute noch benutzt (im Jahr 2023).
Heute hat man Frameworks die eine Lebensdauer in Monaten haben (OK, die Compiler sind standardisiert, hilft Dir aber nichts wenn Du verneunftige Ausgabe hast)
Gast
#7539130
Das liegt aber nicht per se an dem, was die Software machen soll, sondern an der Art, wie sie mittlerweile gebaut wird.
Ja primär schon.
Aber der komplexe Funktionsumfang erfordert eine Verteilung der Entwicklung auf viele Leute, die nicht direkt in einem Team zusammen arbeiten. Wenn das Werk vieler unabhängiger Teams kombiniert wird, besteht halt wieder das große Risiko, nicht alles beachtet zu haben, was wichtig gewesen wäre.
Denke nur mal zurück an das Adobe Flash Plugin (falls du die Zeit mit erlebt hast). Das Plugin erkrankte an seinem ständig wachsenden Funktionsumfang. Es riss ein Fass ohne Boden an Sicherheitslücken und funktionalen Problemen auf. Viele Leute fragten sich damals, warum ein reiner Text-Betrachter (genau das waren Internet Browser damals) überhaupt Videos abspielen und Programme ausführen soll.
Wenn man eierlegende Wollmilchsäue haben will, muss man sich auch mit deren Schwachpunkten auseinander setzen. Wir sind heute so weit, dass viele Menschen gar keine Wahl mehr haben. Sie müssen den Kram benutzen, um in dieser Gesellschaft leben zu können.
Dafuer sollten ja Standards entwickelt werden:
Das haben die Hersteller der bunten Säue auch verstanden, die erfinden im Jahrestakt neue "Standards" für ihre Sprachen.
Gast
#7539184
Beherrschbar ist so ein aus irgendwelchen irgendwoher "gezogenen" Libraries zusammengeklicktes Produkt nämlich überhaupt nicht
Am Ende entsteht ein Moloch, der oberflächlich das tut, was er tun soll, aber bei dem hinter den Kulissen komplett "terra incognita" ist.
Nun das klingt jetzt nicht danach daß heute Software mit billiarden Codezeilen doch erstaunlich zuverlässig das Leben beherrscht. Mit der Komplexität haben sich selbstverständlich auch die Werkzeuge zu ihrer Beherrschung weiterentwickelt. Daß dabei Fehler passieren dürfte niemanden erstaunen. Gerade die brauchts sogar und die sind regelrecht Bedingung für noch mehr Zuverlässigkeit, um es noch besser machen zu können. Das beweist heute so gut wie jedes Flugzeug am Himmel. Beispielsweise.
Ich habe den Eindruck, das wir bei der Komplexität unserer Software vielfach an Grenzen gestoßen sind
Man stößt bei der Weiterentwicklung immer wieder an Grenzen- und verschiebt sie.
Erlenkötter-C K&R und https://crypto.stanford.edu/~blynn/c/intro.html oder https://bellard.org/tcc/
decken viel ab.
Den Rest muss man durch Coden, Fehler machen, Testen, Sourcecodes lesen usw. selber in Erfahrung bringen. Man könnte sich auch merken, dass C eine Zeigersprache ist. Das allein reicht aber nicht, C zu verstehen. Sorcecodes sind allerdings auch nicht immer gleich. Man wird selber ein "Gefühl" dafür entwickeln müssen, was für einen selbst hilfreicher ist, und was nicht. K&R ist immer eine hervorragende Referenz.
Bei Mikrocontrollern gelten noch ein paar andere Regeln - da kann man auch mit einem netten MC-Buch einsteigen. Die notwendigen Hintergründe werden meistens ganz gut vermittelt. Früher gab es auch noch viel Beispielcode auf Kassetten, oder Disketten, oder CDs oder aktuell, eine gewisse Zeit im Netz. Hängt auch von der Seite ab. Die Beispielcodes hier sind sehr zuverlässig hinsichtlich ihrer Verfügbarkeit.
Mit dem Programmieren ist es wie beim Malen, Handwerken, Kochen, etc. Es ist nicht schwer. Jeder kann es. Aber man muss sich halt dafür begeistern können, und es machen, dran bleiben, damit man gut darin wird. Das braucht viel Zeit.
K&R ist immer eine hervorragende Referenz.
Wenn man die zweite Ausgabe von 1989 verwendet, und nicht die ältere.
Dann aber kommen auch wieder Leute angeheult, daß C89 ja ein so veralteter Sprachstandard wäre, daß man damit gar nicht anständig programmieren könne.
Ich benutze gelegentlich fremden Sourcecode, und begegne in dem nur sehr selten C89-Inkompatibilitäten (meist geht es um den Ort einer Variablendefinition). Die großartigen Neuerungen der verschiedenen C-Standards sind wohl jenseits der akademischen Hallen gar nicht so besonders ... wichtig.
(Von so etwas wie standardisierten Typen à la uint8_t rede ich hier nicht, die lassen sich problemlos auch mit einem C89-Compiler nutzen, man muss ja nicht alle Fortschritte verdammen)
Zum Thema Pointer, -auf Funktionen
Chapter 10 in A TUTORIAL ON POINTERS AND ARRAYS IN C by Ted Jensen https://pdos.csail.mit.edu/6.828/2018/readings/pointers.pdf
Hallo
Den Rest muss man durch Coden, Fehler machen, Testen, Sourcecodes lesen usw. selber in Erfahrung bringen.
Bei Mikrocontrollern gelten noch ein paar andere Regeln - da kann man auch mit einem netten MC-Buch einsteigen.
Leider hast du vollkommen Recht - C kann man leider nicht wirklich per Buch lernen, insbesondere wenn man sich auf den µC Bereich konzentriert wo es irgendwie keinerlei "C für Dummies und Einsteiger" Bücher, Videos oder andersartiges Lehrmaterial gibt. Leute die auf Hobbyniveau in verständlicher Sprache direkt "C-für den µC" lernen wollen (und keinerlei Interesse an das typische "C für den PC" mit den ewig gleichen Hello World und Kundendatenbankentutorials haben) stehen dumm und sehr einsam da...
Die zwei zitierten Teilsätze sollten eigentlich in jeden Lehrbuch (Tutorial, Video,...) als erstes zu lesen sein, bzw. vorgetragen werden - was natürlich abschreckt aber eben sehr treffend die Realität beschreibt.
An gewisse Personen sei gesagt, melde Dich hier bitte ab, danke schön!
Die großartigen Neuerungen der verschiedenen C-Standards sind wohl jenseits der akademischen Hallen gar nicht so besonders ... wichtig.
Nur, weil du sie nicht kennst?
Immerhin, benannte Felder in struct-Initialisierungen haben es inzwischen sogar (mit einiger Verspätung) in den C++-Standard geschafft. Klar kann man das in C++ auch per Konstruktor lösen, aber die C-Lösung ist simpel, gut überschaubar und ein deutlicher Fortschritt zum vorangegangenen "die Initialisierung muss sich auf die Reihenfolge der Deklaration verlassen" Zustand.
stdint.h hast du schon genannt, klar kann man die auch auf C89 drauf setzen, aber da muss man es manuell machen. Ab C99 ist es nur noch ein #include dazu.
Boolean genauso, ab C99 nur noch ein #include, und es gibt eine saubere Implementierung dafür. (Da diese intern auf _Bool abbildet, geht die auch nicht 1:1 auf einen C89-Compiler drauf.)
Deklaration von Variablen an den Stellen, wo man sie wirklich braucht, ist auch ein nettes Feature, inklusive von for-loop-only-Variablen. Gleichermaßen sind //-Kommentare zuweilen ganz praktisch. Beides Dinge, die ein C89-Compiler nicht kennt.
Die neue Attribut-Syntax für C23 kommt leider arg spät und ist nicht mit der bisherigen GCC-Implementierung kompatibel, aber längst überfällig war sowas.
Das sind jetzt nur mal ein paar Dinge, die mir so einfallen.
Nur, weil du sie nicht kennst?
Ich kenne sie, nur sehe ich sehr wenig Code, der sie auch nutzt.
Praktisch begegnet ist mir nur die Deklaration von Variablen an anderen Stellen als am Blockanfang. Ändert man das, schluckt auch mein (aus verschiedenen Gründen verwendeter) C89-Compiler den Code.
Die netten /designated initializers/ werden zumindest in der Praxis des Codes, der mir im Rahmen meiner Arbeit über den Weg läuft, nicht verwendet.
Gleichermaßen sind //-Kommentare zuweilen ganz praktisch. Beides Dinge, die ein C89-Compiler nicht kennt.
Wenn er sich analretentiv an den Standard hält; das haben die von mir verwendeten Compiler schon vor 30 Jahren nicht gemacht und // munter akzeptiert.
Gast
#7539459
Dazu müsstest du aber erstmal verstehen, was ein Zeiger (aka Pointer) überhaupt ist.
Oder alternativ eine Sprache verwenden, die sowas wie Pointer nicht braucht.
Die netten /designated initializers/ werden zumindest in der Praxis des Codes, der mir im Rahmen meiner Arbeit über den Weg läuft, nicht verwendet.
Dann kennst du nur einen ziemlich bescheidenen Subset. Ich benutze sie selbst außerordentlich gern (weil sie viel sicherer sind als das Verlassen auf irgendeine Reihenfolge), und sie sind mir auch schon an vielen anderen Stellen begegnet.
Gleiches für stdbool.h. Einfach true und false verwenden, wie man sich das schon immer gewünscht hätte.
Flexible array members sind auch etwas, was ich schon vor C99 (dann noch als Erweiterung von GCC) gern benutzt habe.
die C-Lösung [designated Initializers] ist simpel, gut überschaubar und ein deutlicher Fortschritt zum vorangegangenen "die Initialisierung muss sich auf die Reihenfolge der Deklaration verlassen" Zustand.
Wobei das für C++ immer noch gilt: Die benannten Felder im Initializer müssen so angeordnet sein wie im Objekt, siehe zum Beispiel AVR-LibC #898.
Designated Initializers dienen also "nur" dazu, dass Änderungen am Objekt auch im Initializer auffallen und angepasst werden.
Designated Initializers dienen also "nur" dazu, dass Änderungen am Objekt auch im Initializer auffallen und angepasst werden.
Besser als nichts, wenngleich ich nicht verstehe, warum sie das in C++ so halbherzig übernommen haben.
In Clang hat ja sich nun auch der mikrosoftsche Wachhund gegen Mehrfacheinbindung der Header "#pragma once" eingefunden. Gibt es den auch in den OSS_Compilern, oder hat Kleinweich da ein Patent darauf?
mfg
Was für tolle Informationen!
In Clang hat ja sich nun auch der mikrosoftsche Wachhund gegen Mehrfacheinbindung der Header "#pragma once" eingefunden. Gibt es den auch in den OSS_Compilern, oder hat Kleinweich da ein Patent darauf?
mfg
https://en.m.wikipedia.org/wiki/Pragma_once
Oliver
Flexible array members sind auch etwas, was ich schon vor C99 (dann noch als Erweiterung von GCC) gern benutzt habe.
Sowas fasse ich nicht ohne Not an. sizeof(struktur) liefert nicht mehr die reale Datensatzgröße. Damit erforderlich: Noch mehr Obacht mit memcpy() usw. Und der Compiler kann einen nicht warnen. Natürlich gibts in C keinen Copy Konstruktor, welcher das immer korrekt abhandeln könnte.
Gibt es den auch in den OSS_Compilern,
Der GCC kann #pragma seit min 10 Jahren.
Besser als nichts, wenngleich ich nicht verstehe, warum sie das in C++ so halbherzig übernommen haben.
Mein Glaskugel sagt: In C++ ist die Konstruktion von struct/class erheblich komplexer. Durchaus häufiger von der richtigen Reihenfolge abhängig. In C hat man es dagegen eher mit primitiven Datentypen zu tun, die sich nicht selber konstruieren.
Sehr praktisch sind auch 0b für Binärzahlen und Bereiche für switch/case.
1 |
|
2 |
|
Das 0b Prefix wurde mit C23 standardisiert. Ranges und "#Pragma once" sind weiterhin Extensions und sollten vermieden werden.
Designated Initializers dienen also "nur" dazu, dass Änderungen am Objekt auch im Initializer auffallen und angepasst werden.
Besser als nichts, wenngleich ich nicht verstehe, warum sie das in C++ so halbherzig übernommen haben.
In C++, members are destroyed in reverse construction order and the elements of an initializer list are evaluated in lexical order, so field initializers must be specified in order.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf
Flexible array members sind auch etwas, was ich schon vor C99 (dann noch als Erweiterung von GCC) gern benutzt habe.
Sowas fasse ich nicht ohne Not an. sizeof(struktur) liefert nicht mehr die reale Datensatzgröße.
Es liefert halt die Größe ohne das flexible array, also mit einem leeren Array, genau so, wie es auch hingeschrieben wird. Immer noch besser als der zuvor oft anzutreffende Hack (der aber eigentlich natürlich UB war), dass man das "flexible" Array mit der Länge 1 angegeben hat und dann dessen Größe (nach vorheriger dynamischer Allozierung) hemmungslos überschrieben hat. Und natürlich in vielen Fällen auch viel besser, als wenn man einfach nur massig Speicher "auf Vorrat" allozieren müsste, der einerseits verschwendet, andererseits u.U. dann doch unzureichend war.
Ja, C ist da ein bisschen unbeholfen.... Und es endet sofort, wenn man 2 solcher Arrays in einer Struktur haben möchte.
Siehe dazu auch: RAII
Arduino F. schrieb:
Flexible array members sind auch etwas, was ich schon vor C99 (dann noch als Erweiterung von GCC) gern benutzt habe.
Sowas fasse ich nicht ohne Not an. sizeof(struktur) liefert nicht mehr die reale Datensatzgröße.
Es liefert halt die Größe ohne das flexible array, also mit einem leeren Array, genau so, wie es auch hingeschrieben wird.
Ich berechne den Start der Daten meist selbst manuell, statt flexible array zu nehmen.
Was ich praktisch finden würde, wären VM struct typen: https://godbolt.org/z/fWjzjWKzE Syntaktisch ist ist das gültiges C, aber semantisch ist es in C nicht erlaubt. Nur GCC hat es trotzdem als Extension eingebaut.
Und es endet sofort, wenn man 2 solcher Arrays in einer Struktur haben möchte.
Klar, das geht nicht. Du kannst natürlich nun zwei Zeiger drin unterbringen und den Speicherplatz dafür am Ende allozieren, ist mir aber noch nicht übern Weg gelaufen.
Mit VMTs wäre es möglich gewesen: https://godbolt.org/z/n56fzxYMc
Sehr praktisch sind auch 0b für Binärzahlen und Bereiche für switch/case.
1 |
|
2 |
|
Wobei die "0b" Präfix erst mit einer weiteren Neuerung zu lesbarem Code führt: Dem ' als Zifferntrenner:
1 |
|
oder
1 |
|
ist m.E. besser lesbar als:
1 |
|
Leider werden solche Literale vom Assembler (Binutils v2.40) nicht akzeptiert.
Zu den duzenden bunten Saeuen, welche pro Monat neu durch's Dorf getrieben werden ..
Daß dabei Fehler passieren dürfte niemanden erstaunen. Gerade die brauchts sogar und die sind regelrecht Bedingung für noch mehr Zuverlässigkeit, um es noch besser machen zu können. Das beweist heute so gut wie jedes Flugzeug am Himmel. Beispielsweise.
Nicht ganz. Aviatik ist eine spezielle Sache. Da wird auf Sicherheit optimiert. Resp mit maximaler Sicherheit begonnen. Das letzte Mal als ich hinschaute, mit ADA. Da ist jede herausgegebene Compilerversion zertifiziert, musste ein umfangreiches Test Programm durchlaufen. Jede einzelne Codezeile einer Anwendung wird reviewed, wird gerechtfertigt, weshalb sie ist, wie sie ist. Da ist nichts mit Update naechste Woche, naechsten Monat. Die Entwicklungszyklen sind lang.
Beitrag #7540106 wurde von einem Moderator gelöscht.
Beitrag #7540116 wurde von einem Moderator gelöscht.
Was haltet ihr von c von a bis z von Jürgen Wolf?
Mit dem Programmieren ist es wie beim Malen, Handwerken, Kochen, etc. Es ist nicht schwer. Jeder kann es.
Oh nein, nicht jeder kann es. Malen, Handwerken, Kochen - das geht mit dem, was ich immer gern "Auswendiglernen von Telefonbüchern" nenne. Dafür muss man ja weder kreativ sein, noch logisch oder gar abstrakt denken können. "Wenn ein Wasserrohr tropft, kann man es auswechseln, das geht in folgenden Schritten: ..."
Aber erklär mal jemandem etwas ziemlich Einfaches, das man nicht unmittelbar mit den Augen sehen kann, da stößt du sehr schnell an grundlegende Verständnisgrenzen. Elektrischer Strom, Atome, Software, ... - alles Bahnhof.
Fritz: "Ich erkläre dir jetzt mal, was Wahrscheinlichkeit ist. Angenommen, man wirft einen Würfel 5000-mal und zählt dann, wie oft die '3' gekommen ist ..." - und Kevin sofort: "Das geht ja gar nicht. Niemand kann 5000-mal am Stück würfeln!"
Aber man muss sich halt dafür begeistern können, und es machen, dran bleiben, damit man gut darin wird.
Nicht jeder KANN das, weil ihm seine Persönlichkeit im Weg steht. Selbst die meisten Musikliebhaber lernen kein Instrument, obwohl sie es könnten. Sie setzten sich lieber "romantisch" in den Konzertsaal und hinterher in ein Weinlokal - das ist bequemer. Würde man sie z. B. zu Klavierstunden zwingen, würden viele von denen todunglücklich und würden es nie wirklich lernen.
Nicht jeder KANN
Manche können den Komparativ nicht. "Prinzipiell KÖNNTE es jeder..." (vorrausgesetzt, alle haben die selben Anfangsbedingungen. Und da geht es schon los: Ich kann keine Kinder gebären, weil mit die notwendigen Organe fehlen).
Daniel A. schrieb:
Mit dem Programmieren ist es wie beim Malen, Handwerken, Kochen, etc. Es ist nicht schwer. Jeder kann es.
Oh nein, nicht jeder kann es. Malen, Handwerken, Kochen - das geht mit dem, was ich immer gern "Auswendiglernen von Telefonbüchern" nenne. Dafür muss man ja weder kreativ sein, noch logisch oder gar abstrakt denken können. "Wenn ein Wasserrohr tropft, kann man es auswechseln, das geht in folgenden Schritten: ..."
Klar kann ein Maler bestehende Bilder und Styles nachahmen, kann ein Handwerker bestehendes nachbauen und Reparieren, und kann ein Koch nach Rezept kochen.
Aber ich denke, man kann das Handwerk erst wirklich, wenn man Selbst etwas Neuartiges hervorbringen kann. Ein eigenes Bild mit eigenem Thema und eigenem Style. Ein eigenes Möbel oder Gerät. Ein eigenes Rezept.
Auch beim Programmieren habe ich schon solche gesehen, die es irgendwie schaffen, sich Programme zusammenzukopieren, sogar schon vor den LLM, die man dann aber fragen konnte, was der Code macht, und sie es nicht sagen konnten.
Aber ich denke, man kann das Handwerk erst wirklich, wenn man Selbst etwas Neuartiges hervorbringen kann.
Nö. Es gibt auch Leute, die Dinge anderer Leute super reparieren können. Die müssen nicht erst ein Auto gebaut haben, um eins wieder zum Laufen zu bringen. Andersrum wird doch ein Schuh draus: Ich kann das Handwerk und nutze es, um etwas neues zu schaffen. Ansonsten wird es teuerer Pfusch.
Nicht jeder KANN
Manche können den Komparativ nicht.
Und manche blamieren sich mit falschen Fremdwörtern und falscher Semantik.
"Prinzipiell KÖNNTE es jeder..." (vorrausgesetzt, alle haben die selben Anfangsbedingungen.
Da diese Voraussetzung im entsprechenden Alter prinzipiell nicht gegeben ist, KANN es eben nicht jeder.
Aber ich denke, man kann das Handwerk erst wirklich, wenn man Selbst etwas Neuartiges hervorbringen kann
Dann benutzt du das Wort "Handwerk" nicht in dem Sinne, in dem es der normalgebildete Sprecher versteht.
Ein Handwerker repariert Altes oder erschafft Neues, aber er erschafft im Normalfall nichts Neuartiges. Letzteres gehört gar nicht zur Ausbildung.
Der Architekt erschafft die Gestalt eines Bauwerks, der Bauingenieur arbeitet die technischen Details aus und der Maurer errichtet nach Anweisungen der anderen beiden die Mauern.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.