Bei einigen .c-Dateien in einem Projekt zeigte sich eine Dateigröße von mehreren MB und mehrere zehntausend Zeilen Länge. Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße und Zeilenanzahl?
Also für handgeschriebenen Code ist das eindeutig zu viel. Eine feste Vorgabe wie z.B. max 500 Zeilen sind erlaubt ist nicht sinnvoll. Aber man sollte Aufgaben schon in kleine sinnvolle Teile zerlegen und entsprechend in Dateien unterteilen.
> schon in kleine sinnvolle Teile zerlegen
Es spricht auch nichts dagegen, dass nicht zu tun.
Sempfdazugeber schrieb: >> schon in kleine sinnvolle Teile zerlegen > > Es spricht auch nichts dagegen, dass nicht zu tun. Naja, die Übersichtlichkeit die darunter leidet, spricht schon dagegen... EDIT: Willst du nur deinem Namen gerecht werden? ;)
:
Bearbeitet durch User
Erwin M. schrieb: > Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße > und Zeilenanzahl? Eine mögliche Größe geben Tools wie Eclipse vor, die bei großen Files die Komfortfunktionen einschränken. Bei meinem Eclipse hier ist der Indexer auf .c Files <8MB eingeschränkt, und ab 50.000 Zeilen wird auf "Scalability mode" geschaltet.
Erwin M. schrieb: > Bei einigen .c-Dateien in einem Projekt zeigte sich eine > Dateigröße von > mehreren MB und mehrere zehntausend Zeilen Länge. > Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße > und Zeilenanzahl? Es gilt das Limit des jeweiligen Filesystems.
Es hängt vom Codeumfang ab. Auch Zeilen je File sind in etwa pareto-verteilt. Bei 1 Mio Codezeilen ist es okay, wenn 2-3 zwischen 20- und 50.000 Zeilen liegen. Wenn diese Files wirklich thematisch in sich geschlossen sind, lohnt sich oft, hier über automatisierten Code nachzudenken. Ein einfaches Auseinanderreißen hingegen ist Quatsch. Du liest Files ja nicht wie ein Buch, sondern navigierst mit der IDE. Und sobald beim zerreißen neue Header notwendig werden oder Fragmente kopiert werden: Vorsicht.
Erwin M. schrieb: > Bei einigen .c-Dateien in einem Projekt zeigte sich eine Dateigröße von > mehreren MB und mehrere zehntausend Zeilen Länge. Achim S. schrieb: > Es hängt vom Codeumfag ab. LOCs, Kommentar & eingebettete Doku oder ins Programm eingebettete Daten?
Neben den offensichtlichen Grenzen (Dateisystemgröße, maximale Dateigröße, Lesbarkeit) gibt es auch compilerinterne Beschränkungen, die teilweise bekannt und teilweise nicht bekannt sind. Ich bin bei (älteren) Compilern (ARM bzw. Norcroft ADS) schon zweimal an solch eine Grenze gestoßen, allerdings nicht mit handgeschriebenem, sondern werkzeuggeneriertem Quellcode: 1. Der C-Compiler mochte keine switches mit mehr als 512 Cases. 2. Bei der Übersetzung einer ca. 20MB großen Quellcodedatei gab es keinerlei Probleme im ARM-Modus. Im Thumb-Modus sah es aber so aus, als würde sich der Compiler aufhängen und nur noch CPU-Zeit konsumieren. Als der Hersteller dieses Problem untersuchte, stellte er fest, dass der Compiler gar nicht hing, sondern ein Optimierungsalgorithmus sehr schlecht skalierte und somit der Compiler wohl nach nur wenigen Wochen damit fertig gewesen wäre. Dieses Problem konnte der Hersteller aber sehr schnell beheben.
Dass sich für eine Sourcedatei mit "mehreren zehntausend Zeilen" keine sinnvolle Einteilung nach Funktion finden lässt, ist schwer zu glauben - das müsste schon ein absoluter Meister des Spaghetti-Codes verbrochen haben, der noch nie etwas von strukturierter Programmierung gehört hat. Nicht die Länge an sich gehört verboten, sondern der chaotische Aufbau, der zu der Länge geführt hat. Es ist schon eine Weile her, dass Unterprogramme erfunden wurden, und so mancher ist sogar auf die Idee gekommen, dass man so etwas wiederverwenden könnte. Georg
georg schrieb: > Nicht die Länge an sich gehört verboten, sondern der chaotische Aufbau, > der zu der Länge geführt hat. Bei automatisch generiertem Code handelt es sich nicht zwangsweise um einen chaotischen Aufbau, sondern meist um sehr gut strukturierten Code. Mögliche Anwendungsfälle sind z.B. Zustandsautomaten, die in komplett ausgerolltem Zustand eben sehr groß werden können, siehe z.B. die oben erwähnte 512-Case-Beschränkung. Ebenso kann man im C-Quellcode auch z.B. Fremdcode als char-Array unterbringen, z.B. Fonts, Grafiken, Dateisystemabbilder, usw.. Um diesen Fremdcode nicht mit eigenem handgeschriebenen Code zu vermischen, kann es sinnvoll sein, eine Art Containerdatei dafür anzulegen. Um die globale Sichtbarkeit der dabei erzeugten Symbole zu begrenzen, kann es sinnvoll sein, als einziges nichtlokales Symbol eine Tabelle mit den Inhalten dort unterzubringen. Eine derartige Vorgehensweise ist z.B. gebräuchlich bei kleinen Embedded-Webservern, deren statische Inhalte auf diese Art und Weise abgelegt werden. Natürlich kann man manche dieser Anwendungsfälle auch durch extern gelinkte Binärdateien umsetzen, aber ggf. muss man sich dann in die Tiefen der Linkerskripte und der Umsetzung von Symbolnamen begeben, was aber die Portabilität nicht unbedingt verbessert.
Erwin M. schrieb: > einem Projekt zeigte sich eine Dateigröße von > mehreren MB und mehrere zehntausend Zeilen Länge Das sollte der Software Architekt mal dringend über eine Refactoring nachdenken, Mir kann keiner Erzählen das er erstens bei so großen Dateien noch den überblickt hat und das es da nichts gibt das sich als Thematisch auslagern lasst um da vielleicht eine Libary draus zu machen. IHMO ist eine feste grenze wie max 1000 Zeilen sinnlos. Als weiche grenze kann man sagen alles was ausgedruckt 5 Blatt Din A4 übersteigt, braucht ein Moment bis jemand frisches Das durchsteigen kann. Und ja mir ist bewusst das mit modernen IDE der Wunsch Code zu drucken um Ihn zu verstehen stark nachgelassen hat. Aber wie gesagt eine weiche Regel wie viel Code pro Datei finde ich dennoch sinnvoll. Bei Projekten welche mehrere zehntausend Zeilen pro Dateien haben, ist die Wahrscheinlichkeit groß das es sich um Historisch gewachsene Strukturen handelt. Ich persönlich habe die Erfahrung gemacht, das solche Walls of Text besonders Anfällig sind für, Toten Code, Code Dopplung und alle möglichen damit zusammenhängende Probleme.
Erwin M. schrieb: > Bei einigen .c-Dateien in einem Projekt zeigte sich eine > Dateigröße von mehreren MB und mehrere zehntausend Zeilen Länge. > Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße > und Zeilenanzahl? Es gibt Compiler, die grosse Dateien nicht mehr schaffen, oft weil der Speicher bei der Codeoptimierung ausgeht. Dann muss man die Datei halt kleiner machen. Auch brauchen manche Compiler oder Editore länger, manche Diff-Programme können so grosses nicht. Ansonsten gibt es keinen wirklichen fachlichen Grund, die Übersicht einer grossen Datei durch den unübersichtlichen Verhau vieler kleiner Dateien zu ersetzen.
Die Wahrheit ist wie immer fließend ... Ich bin allerdings kein Freund von switches mit hunderten von case fällen. Je optimierungsverhalten des compilers kommt da sehr unperformanter Code raus. Da sollte man immer ein Auge drauf haben.
MaWin schrieb: > die Übersicht > einer grossen Datei durch den unübersichtlichen Verhau vieler kleiner > Dateien zu ersetzen. Da hast Du recht, das will man sicher nicht. Aber man könnte sie stattdessen durch eine übersichtliche und wohlgeordnete Anzahl vieler kleiner Dateien ersetzen.
:
Bearbeitet durch User
Meine Grenze liegt bei 500 Zeilen, aber das ist für mich auch keine harte Grenze sondern eher ein Richtwert. Ohne Codefolding würds aber auch nicht gehen. Ivo
Bernd K. schrieb: > Aber man könnte sie stattdessen durch eine übersichtliche und > wohlgeordnete Anzahl vieler kleiner Dateien ersetzen Wenn das möglich ist, sollte man es tun. Wobei "übersichtlich" und "viel" halt im Auge des Betrachters liegt. Es ist wie so oft im Leben: Eine Datei von 100.000 Zeilen ist vermutlich ein Müllhaufen und hat vermutlich (wie jedes SW) Verbesserungspotential. Das ändert aber nichts daran, dass es Quelldateien dieser Größe gibt, bei denen aufteilen die Komplexität nicht mindert und die Überschaubarkeit (per IDE) nicht erhöht. Dann sollte man es auch lassen. Und das Argument unzureichender Compiler oder IDEs: Ja, dann muss man wohl oder übel Abstriche beim Code machen.
Ivo Z. schrieb: > Meine Grenze liegt bei 500 Zeilen Bei Treibern sicher ok, also bei einer Ansammlung von vielen, einander unabhängigen Funktionalitäten. Dann sind 2000 Dateien je 500 Zeilen OK, mit je einer öffentlichen Header. Bei einem autarken embedded Projekt mit gleicher Codezeilen-Zahl, ist oft schon die sinnvolle Benamung der Dateien ein Problem. Und wenn dann thematische Zusammenhänge auf 10-20 solcher Mini-Dateien verteilt werden und zusätzliche Header notwendig sind, dann wird die eigentliche Problematik sichtbar.
Marc schrieb: > Je optimierungsverhalten des compilers kommt da sehr unperformanter Code > raus. Das läuft meist auf eine Look-Up-Table heraus, wenn der Compiler nicht ganz schlecht ist. Unda dazu würde ich sogar sagen, dass dann meist sehr guter Code erzeugt wird.
imonbln schrieb: > Bei Projekten welche mehrere zehntausend Zeilen pro Dateien haben, ist > die Wahrscheinlichkeit groß das es sich um Historisch gewachsene > Strukturen handelt. Sehe ich auch so. Meist ist das über viele Jahre so geworden, und zwischendurch hat sich nie einer Gedanken darüber gemacht, die Struktur an die Veränderungen anzupassen. Dementsprechend unübersichtlich ist sowas dann. MaWin schrieb: > Ansonsten gibt es keinen wirklichen fachlichen Grund, die Übersicht > einer grossen Datei Alles in eine so große Datei zu stopfen, finde ich nicht besonders übersichtlich. > durch den unübersichtlichen Verhau vieler kleiner Dateien zu ersetzen. Die Idee ist ja auch, es nicht unübersichtlich zu machen.
Maximale Größe einer Sourcecodedatei? Unter ZFS sind es exakt: 1,844674407371e19 Byte
Walter K. schrieb: > Maximale Größe einer Sourcecodedatei? > Unter ZFS sind es exakt: > 1,844674407371e19 Byte Na dann fang lieber schonmal an zu schreiben. Das wird diese Woche nicht mehr fertig.
Walter K. schrieb: > Maximale Größe einer Sourcecodedatei? > Unter ZFS sind es exakt: > 1,844674407371e19 Byte Aha. Hast du denn auch einen Texteditor, mit dem du eine so große Datei bearbeiten kannst? Und wieviel RAM braucht dein Compiler typischerweise zum Übersetzen so einer Datei?
Achim S. schrieb: > Wenn diese Files wirklich thematisch in sich geschlossen sind, lohnt > sich oft, hier über automatisierten Code nachzudenken. Dann könnte man auch den Linux-Kernel in eine .c-Datei, weil es ja nur den Linux-Kernel betrifft und damit thematisch in sich geschlossen ist. Das wären ja nur wenig mehr als 20 Mio Zeilen.
Achim S. schrieb: > Ivo Z. schrieb: >> Meine Grenze liegt bei 500 Zeilen > > Bei Treibern sicher ok, also bei einer Ansammlung von vielen, einander > unabhängigen Funktionalitäten. Dann sind 2000 Dateien je 500 Zeilen OK, > mit je einer öffentlichen Header. > > Bei einem autarken embedded Projekt mit gleicher Codezeilen-Zahl, ist > oft schon die sinnvolle Benamung der Dateien ein Problem. Und wenn dann > thematische Zusammenhänge auf 10-20 solcher Mini-Dateien verteilt werden > und zusätzliche Header notwendig sind, dann wird die eigentliche > Problematik sichtbar. Ich hab bisher nur alleine Hobbyprojekte gemacht, über 1000 Zeilen war ich nie nennenswert drüber, von daher habe ich mich mit solchen Dimensionen noch nicht beschäftigt. Ivo
MaWin schrieb: > Ansonsten gibt es keinen wirklichen fachlichen Grund, die Übersicht > einer grossen Datei durch den unübersichtlichen Verhau vieler kleiner > Dateien zu ersetzen. Bei C# scheint dies aber bei vielen Programmierern genau der Trend zu sein. Ich arbeite zeitweise an einem größeren WPF-Projekt mit und der Kollege mit dem ich da zusammenarbeiten muß ist auch ein Verfechter vieler kleiner Dateien. Da gibt es dann Sourcefiles wo nur eine Methode drin steht die nichts weiter macht, als auf eine andere Methode zu verweisen, welche ihrerseits auf die nächste Methode verweist. Der Code liest sich komplett beschissen und man kann sich dann nur sehr schwer in seine Logik einarbeiten. Er, der Kollege, findet das aber toll und ist der Meinung das sei guter Programmierstil und ist von dieser Arbeitsweise nicht abzubringen. Ich persönlich halte es so, daß ich das was logisch zu einer bestimmten Funktionalität gehört in eine Datei schreibe.
Erwin M. schrieb: > Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße > und Zeilenanzahl? Das kommt darauf an welchen Editor du verwendest, Der Windows Notepad macht schon bei wenigen MB schlapp. Richtige Editoren wie z.B. emacs können gigabyteweise auf die Festplatte swappen wenn es nötig ist.
Ich suche immer mal wieder Antworten auf Fragen in den seriösen Foren. Heute auch wieder - ich hatte dieselbe Frage wie am Anfang: Maximale Größe Quelldatei". Hut ab vor soviel Text mit NULL hilfreicher Information. Das hätte ich nur bei Facebook erwartet.
Rudolf S. schrieb: > Ich suche immer mal wieder Antworten auf Fragen in den seriösen Foren. > Heute auch wieder - ich hatte dieselbe Frage wie am Anfang: Maximale > Größe Quelldatei". > > Hut ab vor soviel Text mit NULL hilfreicher Information. Das hätte ich > nur bei Facebook erwartet. Wenn du einfache Antworten auf schwer entscheidbare Fragen suchst: schließ' dich irgendeiner Religion oder meinetwegen auch der AfD an. All diese Organisationen sind darauf spezialisiert, denjenigen, die arm im Geiste sind, genau so was zu liefern... Alle anderen machen sich die Mühe, selber zu denken. Was unmittelbar dazu führt, das man so'n Schwachsinn erst garnicht fragt, weil man, schon mit minimaler Eigenintelligenz ausgestattet, vollkommen mühelos selber erkennen kann: "it depends..."
Rudolf S. schrieb: > Hut ab vor soviel Text mit NULL hilfreicher Information. Das hätte ich > nur bei Facebook erwartet. Das wird daran liegen, dass schon die Frage nicht sonderlich sinnvoll ist. Wenn du eine Quellcode-Datei öffnen willst, die so groß ist, dass sie ein normaler Editor nicht handhaben kann, machst du was falsch.
Im Wireshark-Quellcode gibt es einige C-Quelldateien mit mehreren 10.000 Zeilen. Die ganz großen mit 50-200k Zeilen sind jedoch automatisch aus einer ASN.1 Beschreibung generiert. Ich finde mit 10.000 Zeilen in einer Datei lässt sich noch relativ gut arbeiten, wenn die Funktionensnamen sinnvoll vergeben sind, damit sich in einem Navigationsbaum des Editors diese schnell lokalisieren lassen. Wobei das bei Wireshark auch etwas speziell ist, weil jedes Protokoll üblicherweise aus nur 1-2 Quelldateien besteht, und es trotzdem knapp 2000 Dateien gibt. Wenn man da anfangen würde die Quelldateien noch weiter zu unterteilen, würde es vermutlich unübersichtlicher.
Thomas W. schrieb: > Im Wireshark-Quellcode gibt es einige C-Quelldateien mit mehreren 10.000 > Zeilen. Die ganz großen mit 50-200k Zeilen sind jedoch automatisch aus > einer ASN.1 Beschreibung generiert. Aber die wird man dann in der Regel nicht von Hand bearbeiten müssen.
Da C Compiler grottig langsam sind und auch die Fehler oft nicht die "echte" Stelle zeigen, sind lange Quelltexte Selbstgeißelung. Wer sich einen Gefallen tun will, macht viele kleine Quelltextdateien. Es braucht dann nur das durch den Übersetzer, was auch geändert wurde.
nur ungern C Programmierer schrieb: > Da C Compiler grottig langsam sind und auch die Fehler oft nicht die > "echte" Stelle zeigen, sind lange Quelltexte Selbstgeißelung. Naja, meist trifft halt der erste Fehler. > Wer sich einen Gefallen tun will, macht viele kleine Quelltextdateien. + entsprechenden Overhead, sprich Header-Dateien > Es braucht dann nur das durch den Übersetzer, was auch geändert wurde. naja, einzelne Dateien von 100kLOC brauchen jetzt ja nicht länger als ne Sekunde oder so. Und Änderungen in Headern können deutlich teurer sein.
nur ungern C Programmierer schrieb: > Da C Compiler grottig langsam sind Ca. 14000 Zeilen/s (clang -O2) bzw. 12500 Zeilen/s (gcc -O2) (mit -O3 kaum langsamer) für ein reales Beispiel (epan/proto.c aus Wireshark) auf einem mäßig schnellen Laptop würde ich jetzt nicht als "grottig langsam" bezeichnen. Welchen Compiler, der so grottig langsam ist, benutzt denn du? > und auch die Fehler oft nicht die "echte" Stelle zeigen, sind lange > Quelltexte Selbstgeißelung. Zum einen lernt man mit der Zeit, die Fehlermeldungen richtig zu interpretieren, zum anderen haben die Meldungen (zuerst bei Clang, dann denn auch bei GCC) in des letzten Jahren sehr viel an Aussagekraft gewonnen. Vielleicht hast du von dieser ENtwicklung nur noch nichts mitbekommen.
nur ungern C Programmierer schrieb: > Da C Compiler grottig langsam sind und auch die Fehler oft nicht die > "echte" Stelle zeigen, sind lange Quelltexte Selbstgeißelung. Du redest von C++-Compilern und kompliziertem, generischem Quellcode. Die meisten C-Compiler sind erstaunlich schnell (für die Qualität des erzeugten Codes).
Programmiersprachentheaterintendant schrieb: > Handgeschriebener oder Maschinengenerierter .c-Quellcode? oder einfach nur präprozessor cpp output um die includes pfadsicher einzubinden. https://linux.die.net/man/1/cpp
Yalu X. schrieb: > Zum einen lernt man mit der Zeit, die Fehlermeldungen richtig zu > interpretieren Na super! Auf der einen Seite geht es heute um KI und so ein popeliges Tool gibt Fehlermeldungen aus, deren Interpretation erlernt werden muss. :-<<< Sorry, das Zeugs ist von gestern!
nur ungern C Programmierer schrieb: > Na super! Auf der einen Seite geht es heute um KI und > so ein popeliges Tool gibt Fehlermeldungen aus, > deren Interpretation erlernt werden muss. Tja, auch KI muss auch lernen. Lernt sie besser als du, bist wegen Doofheit raus. Und wenn ein Tool wegen deiner eigenen Dummheit nicht funktioniert, dann ist deine eigene Dummheit schuld, nicht das Tool.
nur ungern C Programmierer schrieb: > Yalu X. schrieb: >> Zum einen lernt man mit der Zeit, die Fehlermeldungen richtig zu >> interpretieren > > Na super! Auf der einen Seite geht es heute um KI und so ein popeliges > Tool gibt Fehlermeldungen aus, deren Interpretation erlernt werden muss. > :-<<< > > Sorry, das Zeugs ist von gestern! Einerseits beschwerst du dich, dass die Compiler angeblich "grottig langsam" seien, andererseits willst du da eine KI drin haben, die dir die Warnungen erzeugt. Das passt nicht zusammen.
S. R. schrieb: > Und wenn ein Tool wegen deiner eigenen Dummheit nicht funktioniert, dann > ist deine eigene Dummheit schuld, nicht das Tool. Wie immer: Reicht es fachlich nicht, wird man persönlich. Armer Tropf. > Einerseits beschwerst du dich, dass die Compiler angeblich "grottig > langsam" seien, andererseits willst du da eine KI drin haben, die dir > die Warnungen erzeugt. Das passt nicht zusammen. Wo schrieb ich, dass ich mir einen Compiler mit KI wünsche? Warum schreibst du solche falschen Behauptungen? Der C Compiler soll nur- wie viele andere Compiler es machen - die echte Fehlerstelle benennen. Er soll nicht hoffen, dass noch alles gut wird und ein fehlendes ; 30 Zeilen tiefer mit ( erwartet melden. Das ist Steinzeit. [Mod: Einer sachlichen Diskussion entgegenstehende Symbole gelöscht]
:
Bearbeitet durch Moderator
nur ungern C Programmierer schrieb: > Auf der einen Seite geht es heute um KI Wenn es an NI fehlt ist Hopfen und Malz verloren :-)
Johann J. schrieb: > nur ungern C Programmierer schrieb: >> Auf der einen Seite geht es heute um KI > > Wenn es an NI fehlt ist Hopfen und Malz verloren :-) Nur Fachidioten hier? Es gibt auch ein Leben - mit und ohne KI - weit weg vom grottigen C Compiler.
ungern C Programmierer schrieb: >> Wenn es an NI fehlt ist Hopfen und Malz verloren :-) > > Nur Fachidioten hier? Es gibt auch ein Leben - mit und ohne KI - weit > weg vom grottigen C Compiler. Sag ich doch.
nur ungern C Programmierer schrieb: > Wo schrieb ich, dass ich mir einen Compiler mit KI wünsche? Du hattest doch geschrieben, dass du dir bessere Compilerwarnungen wünschst, weil es heute KI gibt. Wenn du damit was anderes meintest, solltest du vielleicht mal erklären, wo du überhaupt den Zusammenhang zwischen Compilerwarnungen und KI siehst. nur ungern C Programmierer schrieb: > Der C Compiler soll nur- wie viele andere Compiler es machen - die echte > Fehlerstelle benennen. Was die echte Fehlerstelle ist, ist Ansichtssache. Solange der Code einen Sinn ergeben kann, ist für den Compiler ja erstmal nichts auffälliges dran. Erst wenn der Code keinen Sinn mehr ergibt, gibt er auf und bricht ab. Aus Sicht der Sprache ist das dann die echte Fehlerstelle.
nur ungern C Programmierer schrieb: > Yalu X. schrieb: >> Zum einen lernt man mit der Zeit, die Fehlermeldungen richtig zu >> interpretieren > > Na super! Auf der einen Seite geht es heute um KI und so ein popeliges > Tool gibt Fehlermeldungen aus, deren Interpretation erlernt werden muss. Schön, dass auch du inzwischen eingesehen hast, dass C-Compiler nicht grottig langsam sind. Was die Fehlermeldungen betrifft: Kennst du eine Programmiersprache mit einem Compiler, der immer den wahren Fehler anzeigt? Wenn ja: Warum zeigt er ihn dann überhaupt an und korrigiert ihn nicht gleich selbst? nur ungern C Programmierer schrieb: > Der C Compiler soll nur- wie viele andere Compiler es machen - die echte > Fehlerstelle benennen. Er soll nicht hoffen, dass noch alles gut wird > und ein fehlendes ; 30 Zeilen tiefer mit ( erwartet melden. Das ist > Steinzeit. Zeig mir ein vernünftiges (nicht konstruiertes) Beispiel, wo ein fehlendes Semikolon erst 30 Zeilen später als Fehler erkannt wird.
Rolf M. schrieb: > Du hattest doch geschrieben, dass du dir bessere Compilerwarnungen > wünschst, weil es heute KI gibt. Es gibt KI und C Compiler sind auf dem Stand von Dampfmaschinen. Jetzt kapiert? Yalu X. schrieb: > Schön, dass auch du inzwischen eingesehen hast, dass C-Compiler nicht > grottig langsam sind. ??? Nö, das sind die größten Schnarchnasen unter den (heute, von Vielen benutzte) Compiler. Yalu X. schrieb: > Wenn ja: Warum zeigt er ihn dann überhaupt an und korrigiert ihn nicht > gleich selbst? Sorry, aber wie blöd stelltst du dich hier dar? Wenn eine Abweichung festgestellt wird, bitte Hinweis auf Zeile und Zeichen, fertig. Der grottige C Compiler macht das nur beim Supergau. Yalu X. schrieb: > Zeig mir ein vernünftiges (nicht konstruiertes) Beispiel, wo ein > fehlendes Semikolon erst 30 Zeilen später als Fehler erkannt wird. Ich bin ja C Kumnmer gewohnt und greife daher nicht mehr so oft ins C Compiler Fettnäpfchen. Das Ganze erinnert mich an die Diskussionen "nur AVR, bloß kein ARM!". Und die damaligen ARM-Hater rühren heute die ARM Werbetrommel und verfluchen die AVR.
nur ungern C Programmierer schrieb: > Yalu X. schrieb: >> Zeig mir ein vernünftiges (nicht konstruiertes) Beispiel, wo ein >> fehlendes Semikolon erst 30 Zeilen später als Fehler erkannt wird. > Ich bin ja C Kumnmer gewohnt und greife daher nicht mehr so oft ins C > Compiler Fettnäpfchen. Mach dir deswegen keine Sorgen. Im Fettnäpfchen steckst du ja schon seit deinem allerersten Beitrag in diesem Thread. Am besten belassen wir es dabei, bevor du noch weiter darin einsinkst.
Yalu X. schrieb: > Mach dir deswegen keine Sorgen. Im Fettnäpfchen steckst du ja schon seit > deinem allerersten Beitrag in diesem Thread. Nö, der Beitrag passt schon.
nur ungern C Programmierer schrieb: > Yalu X. schrieb: >> Zum einen lernt man mit der Zeit, die Fehlermeldungen richtig zu >> interpretieren > > Na super! Auf der einen Seite geht es heute um KI und so ein popeliges > Tool gibt Fehlermeldungen aus, deren Interpretation erlernt werden muss. > :-<<< > > Sorry, das Zeugs ist von gestern! Sorry, aber das ist doch Kindergarten und Bauchvermutungen von unbeteiligten Außenstehenden. Sobald man genug Erfahrung (mit welcher Sprache auch immer) hat um anzufangen ernsthafte Sachen damit zu machen hat man jede Fehlermeldung die vorkommen kann schon mehrmals gesehen und weiß ganz genau was sie bedeutet und wo man nach seinem Fehler zu suchen hat. Und in 99% der Fälle wird man sogar direkt mit der Nase auf die betreffende Codezeile gestoßen. Das ist in der Praxis(!) also überhaupt kein Problem, da verliert man überhaupt keine Worte mehr drüber.
Erwin M. schrieb: > Bei einigen .c-Dateien in einem Projekt zeigte sich eine Dateigröße von > mehreren MB und mehrere zehntausend Zeilen Länge. > Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße > und Zeilenanzahl? Aus der Sicht von Clean Code würde ich jedes File, das mehr als 1000 Zeilen enthält, als potentiell zu groß bezeichnen. Aus technischer Sicht gelten Limitierungen vom jeweiligen Compiler und/oder Betriebs- bzw. Filesystem. merciless
Dirk K. schrieb: > Aus der Sicht von Clean Code würde ich jedes File, > das mehr als 1000 Zeilen enthält, als potentiell > zu groß bezeichnen. Du hältst es also für wesentlich sauberer, als Array eingebettete Tabellen, Binärdateno.ä. in etliche Häppchen zu zerteilen und ggf. einen Haufen Code zu schreiben, der diese Tabellenstücke entweder zur Laufzeit oder durch obskure Präprozessoranweisungen zur Kompilierzeit wieder zusammensetzt? Oder eben den wenig portablen und aus Quellcodesicht verborgenen Weg über den Linker zu gehen? Das kann man so machen, aber dann wird es scheiße. BTDT
Dirk K. schrieb: > Aus der Sicht von Clean Code würde ich jedes File, > das mehr als 1000 Zeilen enthält, als potentiell > zu groß bezeichnen. Und was ist dann die sinnvolle Vorgehensweise wenn ein Hardwaretreiber zum Beispiel 1200 Zeilen enthält und es beim besten Willen keine vernünftige(!) Trennlinie mehr zu ziehen ist welchen Teil man in ein separates eigenständiges Untermodul auslagern könnte weil all das bereits längst geschehen ist und jetzt echt nur noch das drin ist was wirklich dort reingehört (und nirgends anderswohin), weil man auch mit Gewalt nichts mehr refactorn könnte ohne es komplett zu vermurksen, und es sind immer noch 200 Zeilen zuviel? Oder 300? Oder 500? Was machst Du dann?
:
Bearbeitet durch User
Andreas S. schrieb: > Dirk K. schrieb: > Aus der Sicht von Clean Code würde ich jedes File, > das mehr als 1000 Zeilen enthält, als potentiell > zu groß bezeichnen. > > Du hältst es also für wesentlich sauberer, als Array eingebettete > Tabellen, Binärdateno.ä. in etliche Häppchen zu zerteilen und ggf. einen > Haufen Code zu schreiben, der diese Tabellenstücke entweder zur Laufzeit > oder durch obskure Präprozessoranweisungen zur Kompilierzeit wieder > zusammensetzt? Oder eben den wenig portablen und aus Quellcodesicht > verborgenen Weg über den Linker zu gehen? Das kann man so machen, aber > dann wird es scheiße. BTDT Stell dich doch nicht dümmer, als du bist! Du weißt genau, wie er das gemeint hat.
Soweit mir bekannt ist gibt es keine maximale Quellcodegröße mehr. Das heißt aber nicht, dass man seinen Quellcode unter Ausschluss von Hirn schreiben soll (Masochisten mal ausgenommen). Für mich hat das Wort: Übersichtlichkeit einen sehr hohen Stellenwert. Also was Zusammengehört sollte auch zusammen stehen. Aber nicht mehr. Schon die Fehlersuche ist bei Endloscode ein Problem, da die Fehlermeldung fast immer an der falschen Stelle ausgegeben wird. Auch wenn die heutigen Compiler relativ schnell sind unterstützt das Aufteilen in sinnvolle Brocken den gesamten Build Process, da üblicherweise nur die Teile neu übersetzt werden, an denen auch rumgefummelt wurde.
Erwin M. schrieb: > Bei einigen .c-Dateien in einem Projekt zeigte sich eine Dateigröße von > mehreren MB und mehrere zehntausend Zeilen Länge. Obwohl man nicht nur nach der länge gehen kann, die C Dateien sind definitiv zu lang. Die Kunst ist es, verschiedenes sinnvoll aufzuteilen. Eventuell hilft es, sich zu fragen: 1) Braucht es den Code überhaupt? 2) Wozu gehört etwas? 3) Wovon hängt es ab? 4) Gibt es schon Code, der das oder etwas ähnliches macht? (Dann zusammenführen, verallgemeinern oder löschen) 5) Kann man das noch übersichtlicher organisieren? Idealerweise sollte das Programm so aufgebaut sein, dass man bei einem Problem sofort begreift, dass muss Komponente X in Datei Y sein, wegen Funktion Z. Die ganze Architektur, der Control Flow, sollte möglichst einfach zu begreifen sein. Es braucht vor allem Übung. Hat man z.B. diverse Listenartige Strukturen, und bearbeitet diese an verschiedensten stellen, dann kann man sich mal eine allgemeine Implementierung diverser Listen & Hilfsfunktionen anlegen oder holen, und in separate Dateien packen. Hat man Funktionen, die nicht wirklich spezifisch zu irgendwas sind, kann man diese eventuell als Utillity Funktionen verallgemeinert auslagern. Hat man Code für Textausgaben, zum Parsen von Zeugs, zum Verwalten von X, zur Verarbeitung von Y, oder zum Verehren von Katzen, dann packt man die Dinge in eigene Dateien, eventuell sogar in je mehr als eine, etc. Bei manchen Sachen macht es auch sinn, jeder Funktion eine eigene Datei zu geben. Ich hab z.B. bei diesem Projekt von mir ein Parser für escape sequenzen, der bei jeder erkannten Escapesequenz die angegebene Funktion aufruft: https://github.com/Daniel-Abrecht/libttymultiplex/blob/master/src/parser.c#L36 Die Funktionen selbst sind dann aber alle in einem Unterordner in einer eigenen Datei, mit nur je 20-30 Zeilen code: https://github.com/Daniel-Abrecht/libttymultiplex/tree/master/src/sequencehandler
Andreas S. schrieb: > Du hältst es also für wesentlich sauberer, als Array eingebettete > Tabellen, Binärdateno.ä. in etliche Häppchen zu zerteilen und ggf. einen > Haufen Code zu schreiben, der diese Tabellenstücke entweder zur Laufzeit > oder durch obskure Präprozessoranweisungen zur Kompilierzeit wieder > zusammensetzt? Oder eben den wenig portablen und aus Quellcodesicht > verborgenen Weg über den Linker zu gehen? Das kann man so machen, aber > dann wird es scheiße. BTDT Bernd K. schrieb: > Und was ist dann die sinnvolle Vorgehensweise wenn ein Hardwaretreiber > zum Beispiel 1200 Zeilen enthält und es beim besten Willen keine > vernünftige(!) Trennlinie mehr zu ziehen ist welchen Teil man in ein > separates eigenständiges Untermodul auslagern könnte weil all das > bereits längst geschehen ist und jetzt echt nur noch das drin ist was > wirklich dort reingehört (und nirgends anderswohin), weil man auch mit > Gewalt nichts mehr refactorn könnte ohne es komplett zu vermurksen, und > es sind immer noch 200 Zeilen zuviel? Oder 300? Oder 500? Was machst Du > dann? Ja nun gut, ich kann nicht von jedem erwarten, dass er der deutschen Sprache mächtig ist. Ich hab das Wort "potentiell" verwendet. Dies suggeriert dem geneigten Leser, dass es auch Ausnahmen geben kann/wird: generierter Code, eingebettete Daten oder einfach nur die fehlende Möglichkeit, den Code weiter zu zerlegen. Auch wird es nicht passieren, dass Robert C. Martin mit der Maschinenpistole im Anschlag in der Tür steht, wenn man ein File größer macht. Man man man, aber mal wieder schön getrollt. merciless
Dirk K. schrieb: > Aus der Sicht von Clean Code würde ich jedes File, > das mehr als 1000 Zeilen enthält, als potentiell > zu groß bezeichnen. Das bedeutet aber im Umkehrschluss: mit Clean Code kann ich nur kleine Projekte oder halt Sammlungen (Treiber etc.) machen. Wenn 1000 eine Obergrenze ist, dann kann der Mittelwert (nach Pareto) nur bei wenigen 100 Zeilen liegen. Das ist für größere Projekte (>100.000 Zeilen) nicht sinnvoll.
Andreas S. schrieb: > Du hältst es also für wesentlich sauberer, als Array eingebettete > Tabellen, Binärdateno.ä. in etliche Häppchen zu zerteilen und ggf. einen > Haufen Code zu schreiben, der diese Tabellenstücke entweder zur Laufzeit > oder durch obskure Präprozessoranweisungen zur Kompilierzeit wieder > zusammensetzt? Oder eben den wenig portablen und aus Quellcodesicht > verborgenen Weg über den Linker zu gehen? Das kann man so machen, aber > dann wird es scheiße. BTDT Das Problem gäbe es gar nicht, wenn C eine gescheite Möglichkeit zur Compile-Time Verarbeitung von Binärblobs, CSV, etc. aus externen Dateien hätte. Trennung von Daten und Code und so.
Jemand schrieb: > Das Problem gäbe es gar nicht, wenn C eine gescheite Möglichkeit zur > Compile-Time Verarbeitung von Binärblobs, CSV, etc. aus externen Dateien > hätte. > Trennung von Daten und Code und so. Da kann man bequem herum arbeiten, das kann man immer noch absolut sauber trennen, auch wenn in irgendeiner Zwischenstufe generierter Code entsteht. Das würd ich eher als das allerkleinste von C's Unannehmlichkeiten betrachten.
A. S. schrieb: > Wenn 1000 eine Obergrenze ist, dann kann der Mittelwert (nach Pareto) > nur bei wenigen 100 Zeilen liegen. Das ist für größere Projekte > (>100.000 Zeilen) nicht sinnvoll. Angenommen, man hat 1000 Dateien mit rund 100 Zeilen Code bei einem größeres Projekt (>100.000 Zeilen), warum soll das nicht Sinvoll sein? Insbesondere, wenn man auch noch Unterordner verwendet, ist das doch kein Problem? Jemand schrieb: > Das Problem gäbe es gar nicht, wenn C eine gescheite Möglichkeit zur > Compile-Time Verarbeitung von Binärblobs, CSV, etc. aus externen Dateien > hätte. > Trennung von Daten und Code und so. Die Konvertierung kann man auch beim kompilieren machen. Dazu nutzt man ein Makefile. Dem ist es egal, was in welcher Sprache/Format da ist, es macht was auch immer man ihm sagt das es soll, um das Programm zu erstellen. Dann konvertiert man die Daten halt einem kleinen Hilfsprogramm nach C, und kompiliert das dann. Auch das Hilfsprogramm kann man sich vorher noch automatisch von make erstellen lassen. Insbesondere früher wusste man auch noch, wie man mit lex/yacc Parser schreibt, um das sogar mit komplexeren non-standard Daten/Programmstrukturen zu machen. Da das auch keine Unterstützung irgendwelcher speziellen/spezifischen Dateiformate in C selbst voraussetzt, ist die Lösung ja wohl auch viel versatiler und schöner.
A. S. schrieb: > Das bedeutet aber im Umkehrschluss: mit Clean Code kann ich nur kleine > Projekte oder halt Sammlungen (Treiber etc.) machen. > > Wenn 1000 eine Obergrenze ist, dann kann der Mittelwert (nach Pareto) > nur bei wenigen 100 Zeilen liegen. Das ist für größere Projekte > (>100.000 Zeilen) nicht sinnvoll. Ich empfehle dir die Lektüre des Buches von Robert C. Martin. merciless
:
Bearbeitet durch User
DPA schrieb: > Dann konvertiert man die Daten halt einem kleinen > Hilfsprogramm nach C, und kompiliert das dann. Auch das Hilfsprogramm > kann man sich vorher noch automatisch von make erstellen lassen. Solch ein Vorgehen entspräche aber nur dann der hier als Evangelium vermittelten Clean-Code-Lehre, wenn sich auch das Hilfsprogramm an die 1000-Zeilen-Beschränkung hielte.
Andreas S. schrieb: > DPA schrieb: >> Dann konvertiert man die Daten halt einem kleinen >> Hilfsprogramm nach C, und kompiliert das dann. Auch das Hilfsprogramm >> kann man sich vorher noch automatisch von make erstellen lassen. > > Solch ein Vorgehen entspräche aber nur dann der hier als Evangelium > vermittelten Clean-Code-Lehre, wenn sich auch das Hilfsprogramm an die > 1000-Zeilen-Beschränkung hielte. Auch so ein Hilfsprogramm kann man in ein eigenes Unterverzeichnis packen, und in mehrere Dateien aufteilen. Man kann sogar gemeinsame Teile der Programme in Libraries auslagern oder einige Dateien in mehreren Programmen linken. Normalerweise sind diese aber sehr viel kleiner. Bei meinem Fuserescue Projekt linke ich die Lizenz und das Readme mit rein, um es im Programm ausgeben zu können. Das Hilfsprogramm ist so kurz, ich hab es direkt in mein Makefile rein geschrieben: https://github.com/Daniel-Abrecht/fuserescue/blob/master/makefile#L26 (Im nachhinein betrachtet sollte ich das wohl noch so anpassen, dass man explizit angibt, wenn eine Datei unverändert eingelinkt werden soll.)
DPA schrieb: > Die Konvertierung kann man auch beim kompilieren machen. Dazu nutzt man > ein Makefile. Dem ist es egal, was in welcher Sprache/Format da ist, es > macht was auch immer man ihm sagt das es soll, um das Programm zu > erstellen. Dann konvertiert man die Daten halt einem kleinen > Hilfsprogramm nach C, und kompiliert das dann. Auch das Hilfsprogramm > kann man sich vorher noch automatisch von make erstellen lassen. Statt einem Einzeiler brauche ich ein externes Tool, welches meinen Datensatz auf ein Vielfaches ihrer Größe aufbläst, und muss das auch noch ins Buildsystem verwursten. So richtig überzeugend ist das nicht. DPA schrieb: > Da das auch keine Unterstützung > irgendwelcher speziellen/spezifischen Dateiformate in C selbst > voraussetzt, ist die Lösung ja wohl auch viel versatiler und schöner. C muss keine speziellen Formate unterstützen, C muss Compile-Time Codeausführung unterstützen.
DPA schrieb: >> Solch ein Vorgehen entspräche aber nur dann der hier als Evangelium >> vermittelten Clean-Code-Lehre, wenn sich auch das Hilfsprogramm an die >> 1000-Zeilen-Beschränkung hielte. > > Auch so ein Hilfsprogramm kann man in ein eigenes Unterverzeichnis > packen, und in mehrere Dateien aufteilen. Man kann sogar gemeinsame > Teile der Programme in Libraries auslagern oder einige Dateien in > mehreren Programmen linken. Es geht nicht um die Länge des Hilfsprogramms selbst, sondern dass dieses Hilfsprogramm so geschrieben sein muss, dass die von ihm erzeugten Dateien eine maximale Länge von 1000 Zeilen aufweisen. Das führt natürlich zu der putzigen Situation, dass die Anzahl und die Namen der später zu kompilierenden Dateien plötzlich von dem Inhalt der Ausgangsdatei abhängen, d.h. gestern ergab die Binärdatei noch 997 Zeilen, die heutige Version dann 1002 Zeilen. Entweder muss dann also das Hilfsprogramm auch noch die entsprechenden Makefiles generieren oder das Build-System muss Wildcards zulassen. Und das nur, weil jemand für C-Quelltexte eine 1000-Zeilen-Beschränkung in Stein gemeißelt hat. Super! Und in der eigentlichen Anwendung darf dann auch nicht auf ein großes Array zugegriffen werden, sondern jeder Zugriff muss über eine weitere Tabelle o.ä. erfolgen, in der auf das jeweilige Häppchen verwiesen wird. Ganz toll. Damit wird also ein gewaltiger Wasserkopf in der Anwendung geschaffen, nur um ein paar willkürliche Richtlinien umzusetzen.
Andreas S. schrieb: > Und das nur, weil jemand für C-Quelltexte eine > 1000-Zeilen-Beschränkung in Stein gemeißelt hat. Wer soll das getan haben? Aber wenn es dir hilft, kannst du den Array-Initialisierer ja in eine einzelne Zeile packen.
Jemand schrieb: > DPA schrieb: >> Die Konvertierung kann man auch beim kompilieren machen. Dazu nutzt man >> ein Makefile. Dem ist es egal, was in welcher Sprache/Format da ist, es >> macht was auch immer man ihm sagt das es soll, um das Programm zu >> erstellen. Dann konvertiert man die Daten halt einem kleinen >> Hilfsprogramm nach C, und kompiliert das dann. Auch das Hilfsprogramm >> kann man sich vorher noch automatisch von make erstellen lassen. > > Statt einem Einzeiler brauche ich ein externes Tool, welches meinen > Datensatz auf ein Vielfaches ihrer Größe aufbläst, und muss das auch > noch ins Buildsystem verwursten. So richtig überzeugend ist das nicht. In meinem verlinkten Beispiel wird das direkt per pipe in den gcc geschaufelt. Auf die art und weise wird die Datei nicht als ganzes verarbeitet, und die "Aufgeblasene" form muss nie irgendwo gespeichert werden. Im Binary ist es wieder die Form, in der man es ja sowieso braucht. Und irgendwie verwurstet wird da auch nichts. Das Buildsystem ist dafür da, das man ihm sagt, wie man das Programm baut. Müsste man jedes Programm gleich bauen, bräuchte man es nicht, aber dann kann man es auch für nichts mehr brauchen. Andreas S. schrieb: > Es geht nicht um die Länge des Hilfsprogramms selbst, sondern dass > dieses Hilfsprogramm so geschrieben sein muss, dass die von ihm > erzeugten Dateien eine maximale Länge von 1000 Zeilen aufweisen. Ich würde meinen, aus der Sicht der Clean-Code-Lehre ist generierter Code gar kein Code. Er wurde nicht geschrieben, also existiert er gar nicht. Die Dateien sind ja such nur Temporär, und können/werden auch immer wieder gelöscht.
Jemand schrieb: > C muss keine speziellen Formate unterstützen, C muss Compile-Time > Codeausführung unterstützen. Die Sachen für die ich gerne C-Code erzeugen will lassen sich in dynamischen Hochsprachen wie zum Beispiel Python viel einfacher und prägnanter hinschreiben und warten als wenn ich das in C machen würde. Man muss nicht alles nochmal neu erfinden wenn es schon fertige Tools gibt die man einfach nehmen kann.
Andreas S. schrieb: > ...Geblubber entfernt Schönes Wetter zum Trollen, gell? Niemand kommt und schneidet dir die Eier ab, wenn du mehr als 1000 Zeilen in ein File packst, ganz besonders dann nicht, wenn es sich um Daten handelt, die eingebettet werden. merciless
Wie wäre es wenn man hier für jeden Kommetar zahlen müsste, z. B. zwei Cent; würde die Maßnahme den Spam/das Trollen hier verringen oder eher erhöhen, nach dem Motto "Ich habe doch dafür bezahlt"? Gibt es dazu schon Studien?
Andreas S. schrieb: > Du hältst es also für wesentlich sauberer, als Array eingebettete > Tabellen, Binärdateno.ä. in etliche Häppchen zu zerteilen Wozu sollte man sowas verrücktes machen? Aus meiner Sicht ist das gar kein Code im herkömmlichen Sinn. Niemand muß darin irgendwelche Algorithmen und Abläufe verstehen oder ändern. Ich würde solche Datenfelder sogar als eigenständiges Projekt aufbauen und dann die fertige Binärdatei zum ausführenden Code hinzufügen (linken oder anhängen). Es kann auch sinnvoll sein, daß solche Datenfelder überhaupt nicht in den ausführbaren Code kommen, sondern in einen externen seriellen Flash. Man kann so Daten ändern oder hinzufügen, ohne die Applikation neu compilieren zu müssen. Z.B. um Schriftarten, Bilder, Sounds oder Animationen zu ändern. Code ist für mich nur das, wo man auch Gehirnschmalz reingesteckt hat. D.h. Dein Nachfolger sollte die Abläufe darin verstehen können, um ihn warten und erweitern zu können.
ich weiß, dass das Visual Studio 10 Probleme mit Code-Dateien über 65k +x Zeilen hatte. Zumindest der Debugger kam damit überhaupt nicht klar. (Der Compiler hats anstandslos gefressen) Aufgefallen war mir das, als ich ein Program debuggen wollte, was das SQLite amalgamation - c File nutzte - ich musste damals das file auf 2 oder 3 aufteilen. Das aktuelle amalgamation file (--> https://www.sqlite.org/download.html) ist fast 223000 Zeilen groß.
:
Bearbeitet durch User
Vlad T. schrieb: > Das aktuelle amalgamation file (--> > https://www.sqlite.org/download.html) ist fast 223000 Zeilen groß. Wow, das ist ja x-fach krank: - der Debugger (MS?) kommt nicht damit zurecht - Entwickler nutzen wohl eher einzelne Files (schon mal "make -j" auf einer 64 CPU Sun gestartet) - i.e. die parallele Verarbeitung wird damit verhunzt - Endanwender werden wohl ein fertiges Paket installieren Zum TO - kommt darauf an, aber bei ca. 10k Zeilen wird wohl ein Split übersichtlicher. leo
leo schrieb: > Vlad T. schrieb: >> Das aktuelle amalgamation file (--> >> https://www.sqlite.org/download.html) ist fast 223000 Zeilen groß. > > Wow, das ist ja x-fach krank: Ja, aber das ist bei den "amalgamation" also "Zusammenschluss" auch nicht erstaunlich. Warum die so einen scheiss bieten, keine Ahnung. Links zu den Repos hab ich hier gefunden: (abschnitt 3.1) https://sqlite.org/whynotgit.html#the_official_github_mirror Und als ich den mist unter: https://sqlite.org/copyright.html und https://sqlite.org/src/artifact/df5091916dbb40e6 gelesen habe, WTF. Also SQLite ist für mich tot.
DPA schrieb: > Warum die so einen scheiss bieten, keine Ahnung. Ich vermute mal um auch ohne LTO möglichste kleine Binaries zu erzeugen.
DPA schrieb: > Warum die so einen scheiss bieten, keine Ahnung. > Links zu den Repos hab ich hier gefunden: (abschnitt 3.1) > https://sqlite.org/whynotgit.html#the_official_github_mirror ich fand es sehr bequem. Einfach eine Datei dem Projekt hinzufügen und schon hat man sqlite drin. Kein umständliches Lib-Bauen oder hunderte extra-files dem Projekt hinzufügen. Außerdem bietet der Ansatz dem Compiler beste Möglichkeiten zur Optimierung. hier ist dazu auch was: https://www.sqlite.org/amalgamation.html da steht auch was über ein split-amalgamation was sie anbieten wegen Debuggingproblemen über 32k lines. vielleicht hab ich mich auch um eine Potenz getäuscht.
Erwin M. schrieb: > Bei einigen .c-Dateien in einem Projekt zeigte sich eine Dateigröße von > mehreren MB und mehrere zehntausend Zeilen Länge. > Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße > und Zeilenanzahl? Eigentlich ist die Frage in der Form unzureichend beschrieben, denn die .c oder .h Dateigröße ist eigentlich unerheblich. Wichtiger für den Compiler ist die Größe der Translation Unit, also das .i file ausgegeben vom Präprozessor. (Wer bei GCC bugs submittet soll auch immer die .i/.ii files nehmen, weil da alles zum Übersetzen/Reproduzieren des Fehlers enthalten ist und keine obskuren header fehlen.) Eine andere Beschränkung wäre die maximale Größe für den AST.
DPA schrieb: > Ja, aber das ist bei den "amalgamation" also "Zusammenschluss" auch > nicht erstaunlich. Warum die so einen scheiss bieten, keine Ahnung. SQLite ist kein normales Projekt, sondern vermutlich das weltweit meistverbreitete Stück Software. Das wird auch da eingesetzt, wo die Compiler- und Buildinfrastruktur wesentlich weniger gut ausgebaut ist. Deswegen gilt dort noch immer C89 und kein Verlass auf Compilererweiterungen (wie z.B. LTO) oder Infrastruktur (wie z.B. make, CMake oder irgendwas anderes).
Erwin M. schrieb: > Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße > und Zeilenanzahl? 424242 Byte mit rund 5300 Zeilen Code. Aber ordentlich vollschreiben!
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.