Tortoise Git, Dateien und Icons

SeppJ

Ich habe mal ein bisschen rumgegoogelt und wenigstens bist du nicht der einzige mit dem Problem. Aber die Lösung ist quasi was ich vorgeschlagen habe, nur ein bisschen ausgekügelter (weil da anscheinend auch die Reihenfolge der Einstellungen sortiert werden muss - zumindest 2017, als das geschrieben wurde). Was soll man auch sonst machen? Entweder muss das, wie hustbaer sagt, vom Hersteller gemacht werden, oder man muss eben selber passend machen, was nicht passt.

https://www.uweraabe.de/Blog/2017/01/18/dproj-changed-or-not-changed/
https://www.uweraabe.de/Blog/2017/01/24/dprojnormalizer-for-xe7-and-xe8/

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

https://www.uweraabe.de/Blog/2017/01/18/dproj-changed-or-not-changed/

Man muss sich schon ernsthaft fragen, ob die Entwickler überhaupt mit ihrer eigenen Software arbeiten oder was die für einen Workflow haben, wenn dieses (IMHO massive) Problem anscheinend fast 8 Jahre dort niemanden gestört hat. Meines Erachtens gehören "Projektdateien" wie Makefiles, CMake-Skripte oder eben diese .cbproj-Dateien selbstverständlich ebenfalls unter Versionsverwaltung.

Apropos CMake: RAD Studio scheint das ja irgendwie auch zu unterstützen, ich weiß aber nicht wie gut. Vielleicht ist das ja eine Option, mit der man die .cbproj-Dateien irgendwie umgehen könnte. Allerdings wäre es auch ein ziemlicher Akt, ein größeres Projekt auf CMake umzustellen, daher ist das wahrscheinlich nicht praktikabel und der "Djprojnormalizer" vermutlich die bessere Lösung. Ich persönlich versuche allerdings immer, die IDE-spezifischen Projektdateien zu vermeiden und das alles soweit möglich mit CMake zu machen. Hat den Vorteil besserer Portabilität, da man sich nicht an einen Compiler und eine IDE bindet.

SeppJ

@Finnegan sagte in Tortoise Git, Dateien und Icons:

@SeppJ sagte in Tortoise Git, Dateien und Icons:

https://www.uweraabe.de/Blog/2017/01/18/dproj-changed-or-not-changed/

Man muss sich schon ernsthaft fragen, ob die Entwickler überhaupt mit ihrer eigenen Software arbeiten oder was die für einen Workflow haben, wenn dieses (IMHO massive) Problem anscheinend fast 8 Jahre dort niemanden gestört hat. Meines Erachtens gehören "Projektdateien" wie Makefiles, CMake-Skripte oder eben diese .cbproj-Dateien selbstverständlich ebenfalls unter Versionsverwaltung.

RAD Studio ist alt, und Borland (die ursprünglichen Entwickler) noch viel älter. Da ist git mit seinen 20 Jahren geradezu ein neuer Hype im Vergleich. Ich kann mir gut vorstellen, dass man bei Borland immer wieder mal die Frage gestellt hat "Sollen wir nicht auf git umsteigen?", und die Antwort war jedes Mal, dass ihre bisherigen Versionsverwaltungsmethoden gut genug sind, die Migration (oder gar Verlust!) der Historie zu schwer wiegen würde, die Toolchains und Workflows seit Jahrzehnten etabliert sind, und daher die Vorteile eines Umstiegs einfach zu gering. Und alle paar Jahre wurde das vielleicht wieder hinterfragt, aber dann war das Projekt und seine Historie noch größer, die Toolchain und Workflows noch länger etabliert, etc.

Auch wenn sie langsam aussterben, gibt es daher immer noch genug Nutzer von alternativen Versionsverwaltungssystemen, die das Problem vielleicht anders handhaben. Ich kann natürlich nur raten bezüglich Borland/Embarcadero, aber solche Geschichten gibt es doch zuhauf. Ich habe bei mir auf der Arbeit selber mal versucht, die befreundete nicht-Programmierer-Abteilung zu ihrem Glück mit git zu überzeugen, aber deren SVN-Repo war sowas von entartet (Gigabyteweise Binaries ) und so alt, dass eine Konvertierung Stunden dauerte, und danach war die Akzeptanz einfach nicht da, weil man nicht umlernen wollte vom schönen klickibunti Tortoise-SVN auf git, und das niemand genutzt hat. Soweit ich weiß, nutzen die das immer noch...

DocShoe

@SeppJ

Das Eine hat nichts mit dem Anderen zu tun. Man kann gleichzeitig ein altes Versionskontrollsystem benutzen und gleichzeitig dafür sorgen, dass die Projektdateien aufgeräumt bleiben. Man hat das Projektdateiformat (ist ne Art Xml) einige Male erweitert, zB, um Android und MacOS zu unterstützen. Da hätte man auch gleichzeitig die Sortierung von Einträgen usw. sicherstellen können. Und den Zeitstempel nicht schreiben, die kriegt man auch über den Zeitstempel der Datei raus.

Edit:
Danke für die Hinweise, aber ich glaube, ich möchte keine 6 Jahre alte Hobbylösung ausprobieren. Kann gut sein, dass sie funktioniert, und mit dem nächsten RAD Studio Update zerschießt sie die Projektdateien, das möchte ich nicht riskieren.

hustbaer

Der Zeitstempel wäre nichtmal ein Problem, wenn er nur aktualisiert würde sofern man auch wirklich Änderungen im Projekt gemacht hat.
Dass die Einträge ihre Reihenfolge ändern ist aber natürlich immer ein Problem.
Beides sollte aber leicht zu fixen sein.

hustbaer

p.S.: so nen "Normalizer" könnte man sich wohl auch selbst schreiben, ist denke ich auch nicht SO das grosse Problem.

Angenommen...

Das File ist standardkonformes XML
Man liest das File ohne Schema Validation in ein generisches DOM ein
Man macht in dem DOM nur Änderungen von denen man weiss dass sie "sicher" sind, wie bestimmte Elemente zu sortieren und den Zeitstempel auszutauschen

...dann sollte das mMn. auch halbwegs sicher/zuverlässig sein. Wenn Änderungen gebraucht werden, kann man sie dann selbst machen. Und falls wirklich mal was daneben geht, verliert man auch maximal die letzte Änderung -- die, die man committen wollte zu dem Zeitpunkt wo der Normalizer das File zerschossen hat.

SeppJ

An sich ist das fein und aus der git-Nutzersicht schön unsichtbar, aber wie ich oben schon sagte, kommt man in Teufels Küche, wenn man da irgendwie verteilt dran arbeitet und jemand (z.B. ein neuer Mitarbeiter) das nicht weiß (und man vergisst es zu erwähnen, weil es so unsichtbar ist), und da eine "verseuchte" Datei comitted. Die dann auch noch schön auf alle Kopien gepullt wird, bevor man es merkt, am besten noch dass jemand von so einem verseuchten Zustand wegbrancht und seine Branch-Historie nicht verlieren will.

Man kann das alles beheben, sogar sauber, aber man muss wirklich verstehen, wie das mit den Filtern, dem git-Arbeitsverzeichnis, dem Staging Area, usw. funktioniert. Wenn du dir vorstellen kannst, das so eine Situation eintreten kann (wenn du alleine dran arbeitest, sollte das kein Problem sein), dann würde ich unbedingt vorher ein paar Ernstfälle simulieren, diese in aller Ruhe zufriedenstellend beheben, und aufschreiben was man zu tun hat, um alle Mitarbeiter wieder auf einen sauberen Stand zu bringen.

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

An sich ist das fein und aus der git-Nutzersicht schön unsichtbar, aber wie ich oben schon sagte, kommt man in Teufels Küche, wenn man da irgendwie verteilt dran arbeitet und jemand (z.B. ein neuer Mitarbeiter) das nicht weiß (und man vergisst es zu erwähnen, weil es so unsichtbar ist), und da eine "verseuchte" Datei comitted. Die dann auch noch schön auf alle Kopien gepullt wird, bevor man es merkt, am besten noch dass jemand von so einem verseuchten Zustand wegbrancht und seine Branch-Historie nicht verlieren will.

Es gibt da so ne Git-Option für Konvertierung zwischen Unix- und Windows-Zeilenenden (CRLF). Da hatte ich es auch mal mit einer widersprüchlichen Konfiguration zu tun, was dann dazu führte, dass stets alle Dateien als verändert erkannt wurden. Zum Glück ist das vor dem Commit aufgefallen und es gab auch nur eine handvoll Entwickler. Das ist auch so ein Ding, mit dem man sich schnell die Historie zerschießen kann, wenn man nicht aufpasst. Commits, bei denen für 10.000 Dateien jede Zeile im Diff auftaucht, sind leider nur bedingt hilfreich, wenn man Änderungen nachvollziehen will

(CRLF ist echt auch so ein nerviges Ding, mit dem man ein Leben lang Spaß haben kann: Meiner Erfahrung nach sollte man im Zweifel immer Unix-LF bevorzugen. Ich kenne zumindest keine Windows-Tools und Editoren, die damit nicht klarkommen, während sich Builds mit Unix-Fokus (autotools et al.) immer mal wieder an sowas verschlucken. Oft mit sehr seltsamen Symptomen, bei denen man lange nach der Ursache suchen kann).

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

RAD Studio ist alt, und Borland (die ursprünglichen Entwickler) noch viel älter.

Ich fühl mich auch schon ganz schön alt, wenn ich bedenke, das Borland ziemlich heißer Scheiß war, als ich meine ersten Programmier-Schritte mit Turbo Pascal und Turbo C++ gemacht habe

Das Phänomen kann man oft bei Software mit so einer langen Geschichte beobachten (kürzlich mit einer Autodesk-Software gearbeitet, die stellenweise auch Duft diverser jahrzehntealter Verkrustungen versprüht). Zum Teil ist sowas wegen der alten Codebase verständlich, aber ich denke daran sind auch Entwickler nicht ganz unschuldig, die sich einer gewissen Altersbequemlichkeit ergeben haben, und sich nur ungern mit neuen Dingen befassen. Erinnert mich ein wenig an meinen alten Herrn, der Musik der 1980er noch immer für "modernes Zeug der Jugend von heute" hält, während die tatsächlich schon lange zur "Musik der Großväter" geworden ist

Ich finde auch, dass man nicht jeden aktuellen Hype hinterherrennen sollte (da wird schon oft jede Menge Schwachsinn durchs Dorf getrieben), aber bei Dingen, die sich rational als sinnvoll erweisen, sollte man schon ein bisschen mit der Zeit gehen.

wob

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Commits, bei denen für 10.000 Dateien jede Zeile im Diff auftaucht, sind leider nur bedingt hilfreich, wenn man Änderungen nachvollziehen will

Naja, du kannst den Commit-Hash ja in die .git-blame-ignore-revs schreiben. Sowas haben wir z.B. gemacht, wenn wir den Code-Formatter gewechselt haben und einen reinen Formatierungscommit hatten.

Und wenn der Commit nur versehentlich drin war UND du eine kleine Anzahl Entwickler hast, kannst du auch "einfach" den Commit wieder aus dem Repo löschen. Nicht dass ich ein großer Fan davon wäre, aber in diesem Fall kann das tatsächlich sinnvoll sein. Und dann überlegen, warum es kein Review gab bzw. warum das im Review nicht aufgefallen ist.

Nutzt ihr z.B. pre-commit? Da würde man doch normalerweise sowas checken können.

*john 0

@Finnegan sagte in Tortoise Git, Dateien und Icons:

@SeppJ sagte in Tortoise Git, Dateien und Icons:

RAD Studio ist alt, und Borland (die ursprünglichen Entwickler) noch viel älter.

Ich fühl mich auch schon ganz schön alt, wenn ich bedenke, das Borland ziemlich heißer Scheiß war, als ich meine ersten Programmier-Schritte mit Turbo Pascal und Turbo C++ gemacht habe

Ich entsinne mich daran, dass Pascal der heißeste Scheiß für Kleincomputer war (z.B. Language Card für Apple II), und in Folge Turbo Pascal entstand. Ich hatte zwar nie einen Apple II, kann mich aber noch sehr gut an die Kästen erinnern. Und daran, dass damals Watcom der C bzw. C++ unter DOS das Werkzeug der Wahl war. Nun ja, da ich später vor allem auf UNIX programmieren gelernt habe, nutzt ich seit Ewigkeiten den GCC, der in seinen Anfängen ähnlich prähistorisch wie Turbo Pascal ist.

Mir scheint, dass Borland nie so richtig den Wechsel von DOS auf Windows hinbekommen hat, und mit dem Bedeutungsverlust, der mit diesem Wechsel einher ging, niemals zurecht kam. Der Versuch auf Linux wirklich Fuß zu fassen, hat auch nicht so richtig geklappt. Danach habe ich das Produkt ehrlich gesagt aus den Augen verloren.

Das Phänomen kann man oft bei Software mit so einer langen Geschichte beobachten (kürzlich mit einer Autodesk-Software gearbeitet, die stellenweise auch Duft diverser jahrzehntealter Verkrustungen versprüht).

Ganz ehrlich GCC ist deutlich besser gealtert als Borlands/Embarcaderos Produkte.

Finnegan

@wob sagte in Tortoise Git, Dateien und Icons:

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Commits, bei denen für 10.000 Dateien jede Zeile im Diff auftaucht, sind leider nur bedingt hilfreich, wenn man Änderungen nachvollziehen will

Naja, du kannst den Commit-Hash ja in die .git-blame-ignore-revs schreiben. Sowas haben wir z.B. gemacht, wenn wir den Code-Formatter gewechselt haben und einen reinen Formatierungscommit hatten.

Und wenn der Commit nur versehentlich drin war UND du eine kleine Anzahl Entwickler hast, kannst du auch "einfach" den Commit wieder aus dem Repo löschen. Nicht dass ich ein großer Fan davon wäre, aber in diesem Fall kann das tatsächlich sinnvoll sein. Und dann überlegen, warum es kein Review gab bzw. warum das im Review nicht aufgefallen ist.

Nutzt ihr z.B. pre-commit? Da würde man doch normalerweise sowas checken können.

Nein, es hat ja nicht mal ein Commit stattgefunden. Das war nur ein Beispiel wie schnell sowas passieren kann, wenn man nicht aufpasst. core.autocrlf = true war zumindest damals noch ne Default-Einstellung von Git für Windows. Das wird eher dann zum Problem, wenn man Neulinge im Team hat, die sich z.B. nicht wundern, weshalb so viele Dateien bei den Änderungen aufgelistet sind.

Finnegan

@john-0 sagte in Tortoise Git, Dateien und Icons:

Ganz ehrlich GCC ist deutlich besser gealtert als Borlands/Embarcaderos Produkte.

Zu letzteren kann ich nicht viel sagen, aber GCC ist allerdings nur ein Compiler ohne IDE und Windows-Support hatte GCC selbst auch nie wirklich (das kam vom MinGW-Projekt). Aber sie haben die Kurve dennoch durchaus gut hinbekommen und dabei eine ganze Reihe alter unterstützter Architekturen erhalten. Im Quellcode sehe ich da immer noch Support für z.B. den M68k. Wäre mal ne Probe wert, wie gut sich Amiga-Programme in C++23 schreiben lassen. Ein Test vor Jahren mit einer entsprechend zusammengestellten Toolchain hat allerdings gemessen an z.B. der originalen A500-Hardware ganz schön große Executables erzeugt (Hallo Welt). Die C++-Standardbibliothek ist denke ich nicht unbedingt für sowas ausgelegt - vor allem iostreams.

Bei einem aktuellen (Retro-) Hobbyprojekt von mir habe ich ein ähnliches Problem. Da baue ich mit GCC 14 DOS-Programme (MZ-Executables) mit dem Original i386 ohne FPU als Zielarchitektur. Mit C-Code kommt "Hallo Welt" da auf wenige KiB. Und das, obwohl da noch eine malloc-Implementierung und Teile der libc mit drin stecken. Mit C++ gehts kaum unter 200 KiB - hauptsächlich für Exception Handling für das der Compiler trotz -fno-exceptions/-fno-rtti immer noch jede Menge Code emittiert. Sobald ich das "Hallo Welt" mit cout mache, explodiert die Executable dann auf etwa 1.3 MiB. Dass man nicht für das bezahlt, was man nicht nutzt, scheint jedenfalls nicht immer zu stimmen - theoretisch sollte man ja meinen, dass sich das je nach Implementierung zu einem simplen write(stdout, "Hallo, Welt!", 12); optimieren lassen müsste. Da landet aber wohl doch noch nen Haufen ungenutztes Zeug mit in der EXE.

Damn, jetzt schweif ich aber ganz schön ab. Genug OT

SeppJ

Ja, ist ganz schön schlecht, wenn die Zielplattform nicht dynamisch linken kann. Da bleibt die ja eigentlich nur, die Standardbibliothek raus zu werfen, und eine enorm abgespeckte C++-DOS-Library für einfaches IO zu suchen. Oder selber schreiben? DOS hat ja nur ein paar Handvoll Syscalls. Und damit sollte dann ja die volle Macht von C++ als Sprache verfügbar sein. Das wird ein Spaß, wenn all die komischen Ausnahmen, die Sprachpuristen immer anmeckern (z.B. ob man Pointer vergleichen darf, die sich nicht auf das gleiche Array beziehen), auf einmal super-wichtig werden.

*john 0

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Zu letzteren kann ich nicht viel sagen, aber GCC ist allerdings nur ein Compiler ohne IDE und Windows-Support hatte GCC selbst auch nie wirklich (das kam vom MinGW-Projekt). Aber sie haben die Kurve dennoch durchaus gut hinbekommen und dabei eine ganze Reihe alter unterstützter Architekturen erhalten. Im Quellcode sehe ich da immer noch Support für z.B. den M68k. Wäre mal ne Probe wert, wie gut sich Amiga-Programme in C++23 schreiben lassen.

Wenn man eine Turbokarte oder eine Vampire (die gibt es mittlerweile mit 1GB RAM) mit halbwegs ausreichend RAM hat, könnte das gelingen. Mein alter Amiga müsste ich erstmal wieder betriebsfähig machen, wahrscheinlich sind die Elkos hinüber.

Ein Test vor Jahren mit einer entsprechend zusammengestellten Toolchain hat allerdings gemessen an z.B. der originalen A500-Hardware ganz schön große Executables erzeugt (Hallo Welt). Die C++-Standardbibliothek ist denke ich nicht unbedingt für sowas ausgelegt - vor allem iostreams.

Ich hatte mit dem cc65 Compiler für 6502 Plattformen herumgespielt "Hello World!" für C128 2,7kB und das war nur C89. Wenn man da an den VIC20 denkt. Der Emulator kann natürlich wunderbar viel RAM zur Verfügung stellen, weil

Dass man nicht für das bezahlt, was man nicht nutzt, scheint jedenfalls nicht immer zu stimmen - theoretisch sollte man ja meinen, dass sich das je nach Implementierung zu einem simplen write(stdout, "Hallo, Welt!", 12); optimieren lassen müsste.

Optimierende Linker scheinen nicht wirklich in Gebrauch zu sein. Templates, so toll sie auch sind, sind leider richtig übel was den Speicherverbrauch fürs Executable betrifft. Es gab da mal ein Versuch im GCC (RTO oder wie hieß das nochmal?) das zu optimieren, was aber in endlos langen Compile Orgien endete.

*john 0

@SeppJ sagte in Tortoise Git, Dateien und Icons:

Das wird ein Spaß, wenn all die komischen Ausnahmen, die Sprachpuristen immer anmeckern (z.B. ob man Pointer vergleichen darf, die sich nicht auf das gleiche Array beziehen), auf einmal super-wichtig werden.

Tja, es hat schon seine Gründe, weshalb man den Kontext beachten sollte (DOS API vs. Win16, Win32s, Win32 bzw. Win64 API oder UNIX 32Bit bzw. 64Bit API). Viele Jüngere sind sich einfach nicht bewusst, was für ein Murks es war früher Programme zu schreiben, bzw. weshalb die x86 Plattform so verabscheut wurde/wird.

Ich hatte nie einen DOS Rechner sondern einen Amiga und da kam Freunde bei den C Compilern auf, da Lattice/SAS C int als 32Bit und Aztec C als 16Bit definierte, d.h. ILP32 vs. LP32 bei zwei verschiedenen Compilern.

Tyrdal

@wob sagte in Tortoise Git, Dateien und Icons:

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Commits, bei denen für 10.000 Dateien jede Zeile im Diff auftaucht, sind leider nur bedingt hilfreich, wenn man Änderungen nachvollziehen will

Naja, du kannst den Commit-Hash ja in die .git-blame-ignore-revs schreiben. Sowas haben wir z.B. gemacht, wenn wir den Code-Formatter gewechselt haben und einen reinen Formatierungscommit hatten.

Und wenn der Commit nur versehentlich drin war UND du eine kleine Anzahl Entwickler hast, kannst du auch "einfach" den Commit wieder aus dem Repo löschen. Nicht dass ich ein großer Fan davon wäre, aber in diesem Fall kann das tatsächlich sinnvoll sein. Und dann überlegen, warum es kein Review gab bzw. warum das im Review nicht aufgefallen ist.

Nutzt ihr z.B. pre-commit? Da würde man doch normalerweise sowas checken können.

Man könnte im diff auch einfach die whitespaces ignorieren lassen.

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

Ja, ist ganz schön schlecht, wenn die Zielplattform nicht dynamisch linken kann. Da bleibt die ja eigentlich nur, die Standardbibliothek raus zu werfen, und eine enorm abgespeckte C++-DOS-Library für einfaches IO zu suchen. Oder selber schreiben? DOS hat ja nur ein paar Handvoll Syscalls. Und damit sollte dann ja die volle Macht von C++ als Sprache verfügbar sein.

Ich verwende als C-Library picolibc und bei dieser werden auch nicht sonderlich viele Symbole mit in die Executable gelinkt, sofern man die Funktionen nicht nutzt. Wie gesagt, in C war "Hallo Welt" nur um die 30-40 KiB gross. Das war hauptsächlich die dlmalloc-basierte malloc-Implementierung von picolibc. picolibc macht für printf & Co bei der Initialisierung einen kleinen malloc-Aufruf (500 Bytes oder so). Ohne den könnte der malloc-Code wegfallen (tut er auch, wenn man printf nicht aufruft. Mit purem write(stdout, ...) schafft man auch unter 10 KiB.). Ich hab da noch einen in Assembler geschriebenen Loader-Code mit drin, der so gelinkt wird, dass er als erstes gestartet wird. Der detektiert den Speicher, wechselt in den 32-Bit Protected Mode, lädt mit DOS-Systemaufrufen das mit GCC kompilierte Hauptprogramm (damit dessen Größe nur durch den Speicher und nicht durch DOS-Funktionen limitiert wird) und implementiert von der libc benötigte OS-Aufrufe (open, close, read, write, sbrk, etc). Der Loader ist auch nochmal etwa 3 KiB.

Das ist alles soweit kein Problem. Gross wird es erst mit C++. Dann landen nämlich auch mit -fno-exceptions Exception-Handling-Tabellen in der EXE (.eh_frame_hdr und .eh_frame_entry.*-Sektionen im Linker). Die sind in Relation ziemlich groß und enthalten Daten zu jeder Menge Objekten und Funktionen der libstdc++. Das bläht das Ganze dann auf etwa 200 KiB auf und ich habe noch nicht herausgefunden, ob und wenn ja warum die benötigt werden (ich habe in GCC DWARF-Exception Handling aktiviert, das sind die "zero cost"-Exceptions von GCC, also mit fetten Tabellen fürs EH+Unwinding statt setjmp/longjmp). Dazu kommt dann auch noch der Stack Unwinding Code aus der libgcc, der auch noch einen nicht unerheblichen Anteil an der Größe hat. Ich muss allerdings auch erwähnen, dass ich einen Teil des Loaders in C++ geschrieben habe und dort schamlos moderne Features nutze wie std::span, std::string_view, Ranges, Views und Algorithmen. Mein Verdacht ist, dass vor allem daher die ganzen EH-Daten kommen. Ich werd's demnächst nochmal mit einer Multilib-Variante der libstdc++ versuchen, die ich dann ebenfalls mit -fno-exceptions baue.

Alles in allem jedenfalls ein lustiges Hobbyprojekt, bei dem man ne Menge über die Funktionsweise des Compilers lernt und was alles benötigt wird, damit so ein C++-Programm ausgeführt werden kann

Das wird ein Spaß, wenn all die komischen Ausnahmen, die Sprachpuristen immer anmeckern (z.B. ob man Pointer vergleichen darf, die sich nicht auf das gleiche Array beziehen), auf einmal super-wichtig werden.

Eine lustige Eigenschaft in diese Richtung hat mein Projekt schon: Ich verwende ein flaches Speichermodell ohne Paging (virtueller Adressraum), d.h. der physische Speicher lässt sich direkt adressieren und die Speicheradresse 0x0 ist eine gültige Adresse, die keine CPU-Exception oder sowas auslöst. Dort befindet sich bei x86 standardmäßig der Interrupt Vector Table für den 16-bit Real Mode ... auto ivt = reinterpret_cast<ivt_entry*>(0); ... ich mach solche Zugriffe dann aber doch lieber in Assembler. Keinen Bock, dass mir der Optimizer da irgendwann ein Bein stellt, weil nicht sein kann, was nicht sein darf ... und ja, da hab ich eine ganze Menge Code drin, bei dem mir bezüglich C++ sehr unwohl wird. Ich Versuchs aber nach bestem Wissen und Gewissen standardkonform zu halten.

@john-0 sagte in Tortoise Git, Dateien und Icons:

Optimierende Linker scheinen nicht wirklich in Gebrauch zu sein. Templates, so toll sie auch sind, sind leider richtig übel was den Speicherverbrauch fürs Executable betrifft. Es gab da mal ein Versuch im GCC (RTO oder wie hieß das nochmal?) das zu optimieren, was aber in endlos langen Compile Orgien endete.

Doch, ich hab das schon mit LTO gebaut und auch mit -ffunction-sections/-fdata-sections und -Wl,--gc-sections. Ich weiss schon, wie ich unnötigen Code aus der EXE heraushalte. Immerhin hab ich das Linker-Skript geschrieben, mit dem ich überhaupt erst MZ-Executables erzeugen kann (GCC kann das nicht von Haus aus) und ich schau mir mit -Wl,--print-map genau an, was alles wo in der EXE landet. Das Problem scheint tiefer zu liegen. Da bin ich noch dabei herauszufinden, warum das so ist... wenn ich wieder Zeit für das Projekt finde

Finnegan

@Tyrdal sagte in Tortoise Git, Dateien und Icons:

Man könnte im diff auch einfach die whitespaces ignorieren lassen.

Hah! Auch ne gute Idee. Danke. Werd ich mir merken, falls irgendwann doch mal so ein Commit duchkommen sollte

SeppJ

Wo wir über Embarcadero/Borland zu dem Thema gekommen sind: Weiß jemand, wie groß so eine minimale mit Turbo C++ erzeugte Executable war? Konnte Turbo C++ überhaupt Exception Handling? Bei der GNU Implementierung von C++ kann ich ja voll verstehen, dass sich niemand die Mühe gemacht hat, die Größe von DOS-Executables zu optimieren, aber für das Borland-Produkt war das ja sicherlich wichtig. Die erste Version ist von 1990, da mussten Programme noch mit allem drum und dran auf Disketten passen.