Seite 190 von 251

Re: Jammer-Thread

Verfasst: 17.11.2018, 11:36
von Krishty
Dann ist das eine scheiß Seite. Und damit meine ich wirklich beschissen – denn ich bin auch in Foren angemeldet, die vBulletin oder Invision benutzen, und das Login funktioniert überall ohne JavaScript. Selbst Googles Login funktioniert seit geraumer Zeit wieder ohne dass ich YouTube-Skripte erlauben muss. Nur Microsoft haben ihre Portale derart verkackt, dass man da für’s Login drei verschiedene Skript-Quellen zulassen muss.

(Anderes Thema für den Jammer-Thread ist, warum Invision-Foren zum Posten Zugriff auf meine Audiogeräte voraussetzen. WTF.)

Re: Jammer-Thread

Verfasst: 17.11.2018, 14:27
von Krishty
GCC ist der einzige Compiler mit Store Merging.

OMFG.

Falls ihr es nicht glaubt:

Code: Alles auswählen

void foo(char const * externalPointer) {
    char localArray[3];

    // JETZT ACHTUNG:
    localArray[0] = externalPointer[0];
    localArray[1] = externalPointer[1];

    localArray[2] = 0; // just for illustration
    printf("%s", localArray); // just for illustration
}
Sowohl Clang als auch Intel als auch Visual C++ werden die Bytes einzeln kopieren. Bei allen dreien müsst ihr memcpy(localArray, externalPointer, 2); hinschreiben, damit sie die benachbarten Bytes in einem Rutsch bewegen. Mit short und int dasselbe.

GCC hat diese Optimierung auch erst mit Version 7 bekommen (mit Nachbesserungen vor einem Jahr).

WTF. Sind wir noch im Jahr 1991?! Mind=Blown. Plötzlich ist alles so klar.

Ich glaube, jetzt muss ich erstmal ein paar tausend Code-Stellen überarbeiten …

Fun Fact: Ich wollte deshalb eigentlich einen Bug Report für Visual C++ schreiben, als ich gemerkt habe, dass alle anderen Compiler das ebenfalls verkacken.

Nachtrag: Visual C++ hat Store Merging für Konstanten. Wenn dort also 'a' und 'b' stünden statt eines Zeigers nach sonstwo, würde es die beiden Bytes zusammenfassen.

Re: Jammer-Thread

Verfasst: 17.11.2018, 16:54
von Krishty
Internet Explorer 11 auf Windows 10 zerstört Setups beim Herunterladen. Ich kriege das Kotzen. Ich flippe aus. WHAT THE FUCK.
  • ab nach https://papas-best.com/stlviewer_en#download
  • 32-Bit-Setup anklicken
  • direkt ausführen
  • Setup dürfte erfolgreich sein
  • wiederholen
  • Setup startet; dort Reparieren auswählen
  • Setup schlägt fehl mit „Das angegebene Konto ist bereits vorhanden“ bzw. „The specified account already exists“
  • startet man eine Kopie des Setups von Hand, werden plötzlich Admin-Rechte verlangt und das Setup bricht mit dem Fehler ab, das eingebettete Archiv könne nicht gefunden werden
Wenn man das gleiche macht, aber das Setup mit dem IE herunterlädt statt es direkt aus dem IE auszuführen, funktioniert alles reibungslos. Mit Chrome, Firefox und Edge funktioniert alles reibungslos. Auf Windows 7 kommt ein knallroter UAC-Prompt, aber es funktioniert. Nur der fucking IE 11 auf dem fucking Windows 10 verkackt es, ein MSI zu starten. I can’t even

Nachtrag: Oh toll, mit WiX passiert das auch und User melden sowas wie
I get exactly the same difference in successful/unsuccessfull log (with different MSI name of course) when trying to apply minor upgrage with REINSTALL=ALL REINSTALLMODE=vomus.
But I ran it on Windows 8.1 and there is no KB2918614 in my updates list at all.

Minor uprade applies successfully only if MSI package of previous version is in the same folder.

If I'm trying to run my new MSI from another location, I get "The specified account already exists" error.
und
For me this worked for me by keeping the names of both the older version and the newer version of the installer same. No idea why it works, but some of the best practices while working with msi is to keep the name of the installers same.
Reparatur und Upgrade funktionieren nur, wenn man die Setups aus dem selben Verzeichnis startet?! Dann habe ich ja heute abend was zu testen …

Nachtrag 2: Okay; es stimmt: MSI-Reparatur schlägt fehl, wenn das MSI umbenannt wurde. Rob Mensching erklärt:
  • Der Windows Installer erkennt Packages an ihrer UID und ihrem Dateinamen. Der wird benutzt, damit man ihn dem Anwender präsentieren kann, wenn ein Medium fehlt (Bitte legen Sie die CD mit Office2000.msi ein).
  • Wenn sich ein Dateiname ändert, gilt das Package für den Windows Installer als unterschiedlich zum Original.
Daraus schließe ich:
  • Wenn das Package unterschiedlich zum Original ist, kann der Windows Installer es nicht zur Reparatur benutzen.
  • Warum ausgerechnet die Fehlermeldung mit dem Konto kommt, und warum er nicht auf die interne Kopie des Installationsmediums im Windows Installer-Cache zurückgreifen kann, ist mir völlig unklar.
Weiterhin …
  • Wenn der Internet Explorer 11 Dateien herunterlädt, um sie direkt auszuführen, benennt er sie im Cache um.
  • Das löst die Kettenreaktion aus, an deren Ende Windows Installer kein gültiges Installationsmedium für eine Reparatur findet.
  • Reparatur schlägt fehl.
Und was nun?
  • Der Windows Installer lässt Reparaturen also nur zu, wenn sie von exakt dem selben Package (inklusive Dateiname) gestartet werden wie die originale Installation.
  • Mir ist keine Möglichkeit bekannt, das aus dem Package heraus festzustellen.
  • Also kann man gar keine Reparatur anbieten.
Überall Scheiße, wo man auch hinsieht.

Re: Jammer-Thread

Verfasst: 02.12.2018, 02:07
von Krishty
Es gibt die Clang Power Tools als Visual Studio Extension, und darin enthalten ist Clang-Tidy.

Wer’s nicht kennt: Damit kann man z. B. innerhalb von Sekunden in einer Million Zeilen Code automatisch override einfügen, wo es gebraucht wird. Oder alte Typdeklarationen durch auto ersetzen. Oder typedef durch using.

Und letzteres hat bei mir ein paar Dutzend Deklarationen zerstört, denn Clang-Tidy macht aus dem Muster

  template <class T> class Quaternion {
    typedef T TYPE;
    typedef Quaternion SelfType;


fälschlicherweise

  template <class T> class Quaternion {
    typedef float TYPE;
    typedef Quaternion<float> SelfType;


Oder auch:

  using SelfType = FastDelegate<type-parameter-0-0 ()>;

AUA! Außerdem ersetzt es __stdcall durch __attribute__-Syntax; wtf?!

Und noch einer: Clang-tidy kapiert nicht, dass

  template <typename TYPE> class X { typedef TYPE TYPE; };

gültig ist, sich aber _nicht_ zu

  template <typename TYPE> class X { using TYPE = TYPE; };

umwandeln lässt!

Und die for-each-Umwandlung macht aus

  for(std::vector<int>::const_iterator it = v.begin(); it < v.end(); ++it)
    sum += *it * sizeof(*it);


das falsche

  for(auto & i : v)
    sum += i * sizeofi; // Fehlendes Leerzeichen!


Und manchmal sieht es so aus, als ob clang-tidy einfach keinen Bock mehr hat und aufgibt:

  typedef svector<CBlend*,MAX_BLENDED> BlendSVec;
  typedef BlendSVec::iterator BlendSVecIt;
  typedef BlendSVec::const_iterator BlendSVecCIt;


wird zu

  typedef svector<CBlend*,MAX_BLENDED> BlendSVec; // what …
  using BlendSVecIt = int; // … the …
  using BlendSVecCIt = int; // … fuck?!


Oh Mann; so etwas hätte ich bei Machine Learning erwartet, aber nicht bei … einem von Clangs Vorzeigeprojekten. Wenn ich dafür Bug Reports schreibe, ist der Sonntag schon wieder rum.

Re: Jammer-Thread

Verfasst: 06.12.2018, 14:11
von TDK
Eine Preview ist für Visual Studio 2019 draußen.

Und die Farbgebung ist grottenhässlich.

Re: Jammer-Thread

Verfasst: 13.12.2018, 22:05
von NytroX
VS2019 installiert:

Code: Alles auswählen

int main(){
	gsl::owner<int*> x = new int{ 2 };
	*x = 5;
	return 0;
}
Code-Analyse: 0 Errors, 0 Warnings....

Uuuund gleich wieder deinstallieren.

Wieder VS2017 drauf:
Warning C26403 Reset or explicitly delete an owner<T> pointer 'x' (r.3).

Aah, jetzt, ja! So is besser :-)

Re: Jammer-Thread

Verfasst: 15.12.2018, 23:40
von Krishty
Ich nutze Clang-Tidy aus der Visual Studio-Extension Clang Power Tools. Das ist meiner Erfahrung nach besser als Microsofts Analyse, und vor allem auch feiner einstellbar – man kann die Stilwarnungen schön abschalten.

Ich hasse Stilwarnungen. Ich kriege beim Durchkompilieren meines Codes um die 4000 Stilwarnungen, obwohl ich schon alle offensichtlich sinnlosen abgeschaltet habe. Und in diesem Wulst verstecken sich dann zwei oder drei wirklich echte Fehler wie gerade eben

 if(stringEqualsLiteral(nameBegin, "Spark") && '\0' == nameEnd) // use nullptr [modernize-use-nullptr]Oh verdammt, da fehlt eindeutig eine Dereferenzierung!

Re: Jammer-Thread

Verfasst: 17.12.2018, 07:54
von xq
Ich arbeite privat viel mit QtCreator und der hat seit seinem letzten Update das Feature, dass er einem live beim Tippen solche Diagnostics anzeigt. Finde ich persönlich extrem praktisch, aber stimme dir zu: Stilwarnungen gehen gar nicht

Re: Jammer-Thread

Verfasst: 17.12.2018, 10:02
von Chromanoid
Ich würde sagen, dass kommt auf den Arbeitskontext an, oder?

Re: Jammer-Thread

Verfasst: 04.01.2019, 00:06
von Krishty
Krishty hat geschrieben:Wenn man die Adresse einer Funktion oder einer Variable hat, kann man via SymGetLineFromAddrW64() ihren Namen, ihre Quelldatei, und die Zeile ihrer Definition herausfinden. (Sofern das Projekt mit Debug-Informationen kompiliert wurde, natürlich.)

Bei mir ist sie deshalb unverzichtbar für Call Stacks, Assertions, und Debug-Ausgaben.

Dummerweise crasht sie irgendwo in dbghelp.dll!AddressMap::getSectionLength().

Aber nur in einem Projekt. Und nur in rund 80 % der Fälle; in 20 % funktioniert alles wie gewollt.

Ich habe den Quelltext zig-fach auf Speicherfehler untersucht; mit Application Verifier und Debug Checks ausgeführt; alle Compiler-Einstellungen identisch zu anderen Projekten gemacht, in denen sie zuverlässig funktioniert. Ich habe Wettläufe ausgeschlossen und verifiziert, dass DbgHlp nicht doppelt initialisiert wird. Aber all das hat nichts gebracht. Crash, Crash, Crash.

Der einzige andere Mensch, der im Internet etwas davon schreibt, ist Bruce Dawson beim Chrome-Debugging. Er schiebt es auf eine veraltete XP-Version der DLL, aber meine ist definitiv Windows 7-kompatibel. Er schließt mit einem leider völlig unbrauchbaren
The crashing may be caused by VS 2015 generated PDBs hitting some edge cases which would explain why I am seeing this more frequently. The crash is not 100% with VS 2015 PDBs, but it is a non-trivial percentage. We'll have to watch for this if VS 2015 is going to cause XP tests to crash sometimes when failing.
Ich kapituliere und klicke halt bei jeder verletzten Assertion acht Zugriffsverletzungen weg.

Fuck.
In zumindest einem Projekt konnte ich die Fehler loswerden, indem ich in den Linker-Optionen Generate Debug Information optimized for faster links (/DEBUG:FASTLINK) zu Generate Debug Information optimized for sharing and publishing (/DEBUG:FULL) geändert habe. Ich gehe davon aus, dass die Debugger-API Probleme mit /DEBUG:FASTLINK hat.

Das würde auch erklären, warum es vor allem in Projekten auftauchte, die ich unter VS 2015 angelegt habe: Damals war /DEBUG:FASTLINK die Standardeinstellung; seit VS 2017 nicht mehr. Und weil das Einstellungsfenster zu klein für den riesigen Titel ist, sehen beide gleich aus.

Re: Jammer-Thread

Verfasst: 04.01.2019, 10:28
von Tiles
VS 2017 meckert mir dauernd am Python Code rum obwohl da gar keine Fehler sind. Proof: File zu, File auf, keine Fehlermeldung mehr. Und dann find mal die Dinger die wirklich falsch sind wenn VS einfach schon mal den halben Code rot markiert hat. Wir machen das File zu, machen auf, und schaun wo es doch zu Recht meckert ...

Verdammtes Intellisense. Kann das nich wo anders amok laufen? In VS 2013 tat das noch alles -.-

Re: Jammer-Thread

Verfasst: 05.01.2019, 13:55
von dot
Mein Tip: Schau dir mal Visual Studio Code an. Für Python imho unschlagbar. Das große Visual Studio war mir für Python immer zu umständlich und schwerfällig…

Re: Jammer-Thread

Verfasst: 05.01.2019, 17:51
von Tiles
Ja, guter Tip, denn VS Code habe ich installiert und auch im Einsatz. Das ist auch nicht schlecht. Das meckert mir aber dauernd über angeblich fehlende Abhängigkeiten und markiert die dann rot, was VS nicht tut. Und Fenster splitten ist einfach nicht das Gleiche wie einfach den Tab rausziehn und wo anders plazieren. Und mir ist da schon mehr als einmal passiert dass ich an einer alten Datei rumeditiert habe weil ja VS beim zu und wieder aufmachen wie Sublime Text die alten Dateien im Editor behält. Da hat VS die Nase vorn :)

Re: Jammer-Thread

Verfasst: 05.01.2019, 19:18
von NytroX
Und kennt ihr das, wenn man sucht, wie man XYZ in Visual Studio macht, kommen immer Suchergebisse von VSCode und andersrum ?!??
ich nominiere Microsoft hiermit für den "Worst Product Name" Award.

Re: Jammer-Thread

Verfasst: 06.01.2019, 00:11
von Jonathan
Ja, aber ich würde tatsächlich nicht für VS Stimmen, sondern für einen der vielen Spiele-Serien-Teile die unbedingt genau so heißen müssen, wie die Urversion des Spiels. Es ist so absurd nervig, wenn man ein älteres Spiel spielt und dazu genau 0 Informationen im Netz findet, weil jede Seite die neueren, gleichheißenden Teile behandeln muss. Interessanterweise versagen genau da auch die ganzen tollen KI-Algorithmen von Google und Co. die meine präzisen Suchbegriffe automatisiert (und teilweise unverhinderbar) abwandeln, weil sie meinen, ich suche doch ganz bestimmt nach etwas total anderem.

Re: Jammer-Thread

Verfasst: 06.01.2019, 11:43
von Jonathan
Aus aktuellem Anlass möchte ich an dieser Stelle auch meine Lieblings-Android-Hörbuchapp Voice nachnominieren. Das Ding funktioniert ganz gut, aber wehe dir, du willst jemals etwas darüber in Erfahrung bringen. Eine eher nischige App mit einem absolut generischen Namen macht das einfach komplett unmöglich.

Re: Jammer-Thread

Verfasst: 13.01.2019, 11:28
von Tiles
*Leise weinend vor sich hinwart*

Re: Jammer-Thread

Verfasst: 13.01.2019, 13:50
von Krishty
Ja; was für eine selten blöde modale Nachricht. Stört mich auch immer. Falls der (C)-Compiler hängt: Task Manager, cl.exe abschießen, fertig.

Re: Jammer-Thread

Verfasst: 13.01.2019, 14:41
von Krishty
C++ Modules.

Erstmal der gute Teil: Sie sind tatsächlich fast einsatzfähig. Der Header-Verzicht ist unglaublich geil. Keine Header mehr! Keine Deklarationen mehr! Die Kompiliergeschwindigkeit – da läuft es mir nass die Schenkel runter. Ein Traum!

… bis auf’s Build-System. Visual C++ baut keinen Abhängigkeitsbaum für Module auf. Das bedeutet, dass man die Kompilierungsreihenfolge aller C++-Dateien von Hand vorgeben muss, um fehlerfrei kompilieren zu können. Ein totaler Showstopper.

Ich überlege jetzt fieberhaft, wie ich sie irgendwie trotzdem in meine Projekte gezimmert kriege … weil die Vorteile so riesig sind. Aber ich finde keinen alltagstauglichen Weg. Mist.

Zumindest macht das hier Hoffnung:
https://build2.org/article/cxx-modules-misconceptions.xhtml#build hat geschrieben:When I started looking into build systems and modules, my first idea (and I bet I am not alone) was that we need something similar to -M and /showIncludes but for extracting module dependency information. In fact, it would be even better if we can somehow combine both header and module dependency extraction into a single pass since both require a preprocessor run (the compiler will have to preprocess before it can parse import declarations because they can be #ifdef'ed out, etc., just like #include's). And I have it on good authority that the MSVC folks are working on a tool that will do exactly that.

Re: Jammer-Thread

Verfasst: 17.01.2019, 10:48
von xq
Krishty hat geschrieben:...
Krishty, weißt du zufällig, wie das mit zirkulären Abhängigkeiten bzw. Forward Declarations und Modulen funktioniert?

Re: Jammer-Thread

Verfasst: 17.01.2019, 19:09
von Krishty
Falls sich Module gegenseitig nutzen, würdest du das Ganze auf zwei Interface Modules und zwei Implementation Modules aufteilen. Also wie Header und cpp. Wie genau das aussieht und ob es syntaktische Unterschiede zwischen diesen Modultypen gibt, weiß ich aber nicht …

Re: Jammer-Thread

Verfasst: 30.01.2019, 19:20
von kaiserludi
MSVC ist mit der Kombination aus CRTP, using-Deklarationen und Funktionstemplates offensichtlich überfordert.

Code: Alles auswählen

template<typename T>
class C
{
public:
	void c(void){}
	template<typename FT> void c(FT param){}
};

class D : public C<D>
{
public:
	using C<D>::c;
	template<typename FT> void c(FT param){}
};

int main()
{
    D d;
    d.c<int>(1);
}
clang und G++ bescheinigen mir, dass mein Code absolut OK ist.

Siehe:
https://stackoverflow.com/questions/544 ... -ambiguous
https://godbolt.org/z/vkLHvz

Ich könnte jetzt einen Bugreport an Microsoft schreiben, aber wenn die das fixen, dann eh nur für eine Version von VS, die für die vorliegende Codebase als niedrigste unterstützte VS-Version frühestens in 10 Jahren akzeptabel ist.

Re: Jammer-Thread

Verfasst: 30.01.2019, 19:24
von kaiserludi
Die aktuelle Forenversion ist zu doof für korrekte Formatierung in Signaturen.

Re: Jammer-Thread

Verfasst: 30.01.2019, 21:34
von Krishty
Clang auf Windows ist noch immer eine Pest.
  • Es versucht, Visual C++ zu imitieren, wo es nur geht. Clang ist auf Windows standardmäßig im Visual C++-Kompatibilitätsmodus. Man muss das mit einer Million Flags abschalten (-fno-ms-extensions!).
  • Es nutzt die Visual C++-Laufzeitbibliothek statt libc++. Weil libc++ nie so wirklich nach Windows portiert wurde(?). Um sie zu nutzen, muss man sie selber kompilieren. PAIN IN THE ASS
  • Es nutzt die Visual C++-Toolsets zum Einbetten von Ressourcen und Manifests.
  • Seit einigen Monaten hat es zumindest einen eigenen Linker.
Als verkündet wurde, dass Chrome auf Windows von Clang statt Visual C++ kompiliert würde, war das also extrem übertrieben. Clang läuft im Microsoft-Kompatibilitätsmodus über die CPPs, spuckt Microsoft-Objektdateien aus, versieht sie mit Microsoft-Debug-Informationen, ruft dann Microsofts Linker und Microsofts Manifest-Tool und Microsofts Resource-Compiler auf, um die EXE zu produzieren. Da die Optimierungen im Linker geschehen (LTCG!), kam zur Zeit der Meldung nicht einmal LLVMs Optimizer zum Einsatz sondern nur Microsofts!

JA TOLL

Wer gern plattformunabhängig werden möchte, sollte also lieber MinGW nutzen. Aber dann hat man GCC als Compiler, mit dem schlechtesten SIMD-Optimizer, den die Welt je gesehen hat.

Wenn sich Chrome for Windows also irgendwann kompilieren lässt OHNE Visual Studio installieren zu müssen, dann feiere ich das gern. Bis dahin bleiben Clang-Kompilate etwas, das ich am Monatesende für Code Analysis und Undefined Behavior Sanitizer nutze und dann schnell wieder lösche bevor das Chaos jemand sieht und ich mich schämen muss.

Re: Jammer-Thread

Verfasst: 31.01.2019, 20:23
von Krishty
Oh geil. Microsoft kann das hier:

__declspec(restrict) void * malloc(size_t);

… das bedeutet, dass das Ergebnis von malloc() ein einzigartiger Zeiger ist, der sonst nirgends im Programm produziert wird. Das verbessert die Aliasing Analysis und erzeugt minimal besseren Code in einigen Situationen.

Jetzt Clang/GCC:

void * __restrict__ malloc(size_t);

warning: type qualifiers ignored on function return type [-Wignored-qualifiers] What?! Stellt sich heraus: Die Aliasing-Analyse von GCC kann das Attribut gar nicht weiterreichen; deshalb hat es auf Rückgabewerten überhaupt keine Wirkung.

Okay, das ist halt GCC. Der stinkt sowieso. Aber Clang?! Nicht einmal Clang macht das besser?! Ist Aliasing Analysis bei denen plötzlich ein gelöstes Problem?!

Re: Jammer-Thread

Verfasst: 01.02.2019, 17:50
von Jonathan
Es ist 2019 und ich fixe seit 10 Minuten ein Problem, weil ein Pfad ein Leerzeichen enthält. Ganz toll...

Re: Jammer-Thread

Verfasst: 01.02.2019, 21:09
von Krishty
noexcept verursacht nun das gleiche Leistungsproblem wie das veraltete throw(), das es ersetzt.

Abstrakt bleibt noexcept natürlich weiterhin eine effektive Optimierung – std::vector kann für Elemente, die sich via noexcept verschieben lassen, auf das viel schnellere memcpy() zurückfallen statt pro-Element zu kopieren und im Ausnahmefall alles zurückrollen zu müssen. Usw, usf.

Es geht viel mehr um das definierte Verhalten, dass std::terminate() aufgerufen werden muss, falls eine noexcept-Funktion eben doch eine Ausnahme schmeißt: Da bricht das „Zero-Overhead“-Konstrukt des Standardkomitees zusammen, denn es macht die Installation eines Compiler-generierten Exception Handlers um die aufgerufene Funktion nötig. „Nur, wenn der Compiler nicht garantieren kann, dass keine der Unterfunktionen Ausnahmen wirft!“, ruft der tüchtige C++-Theoretiker. Aber in der Praxis – mit externen Bibliotheken, C-Funktionen, COM-Schnittstellen, vergessenen catch-Statements usw. – ist das so eine PITA, dass einige Compiler-Entwickler auch Jahre nach noexcepts Einführung noch von der Nutzung abraten.

„Aber ein C++-Exception-Handler hat doch keine Laufzeitkosten!“, entgegnet das tüchtige Komiteemitglied. Das vielleicht nicht (außer auf 32-Bit-x86) – aber der Platzverbrauch ist Grund genug, die Kosten-Nutzen-Rechnung fürs Inlining gehörig zu verhageln, denn der Exception Handler muss an jeder Aufrufstelle repliziert werden.

Und so haben wir zehn Jahre, nachdem throw() durch noexcept ersetzt wurde „weil es diese versteckten Kosten hat und generell nicht recht durchdacht war“ ein noexcept, das Äquivalent zu throw() definiert ist, und die gleichen versteckten Kosten mitbringt. Genial.

Re: Jammer-Thread

Verfasst: 01.02.2019, 22:24
von Alexander Kornrumpf
Jemand von euch eine Idee, warum ungefähr alle Steam-Spiele gleichzeitig das gleiche Update brauchten?

Re: Jammer-Thread

Verfasst: 07.02.2019, 20:57
von Krishty
Linux und Mac so: Windows ist aufgebläht mit lauter nutzlosem Scheiß. Zehn Gigabyte für Visual Studio, LOL

LLVM so: Hold my beer

llvm.png

Das ist bloß der bin-Ordner! Allein Clang++.exe ist 84 Megabyte groß. Größer als Chrome. Und es ist nicht einmal eine fucking IDE dabei!

Re: Jammer-Thread

Verfasst: 08.02.2019, 11:16
von xq
Ja, du hast halt bei Windows nen großen Haufen Redundanzen dabei und jedes linux-tool kommt mit ner halben GNU-Toolchain mit...

Wenn ich clang mal unter Arch Linux begutachte:

Code: Alles auswählen

[felix@denkplatte ~]$ pacman -Qi llvm-libs llvm clang | grep -E "Installed Size|Name"
Name            : llvm-libs
Installed Size  : 63.73 MiB
Name            : llvm
Installed Size  : 184.49 MiB
Name            : clang
Installed Size  : 83.55 MiB
Das sind hier die kompletten Pakete (also mit allen bins, libs, doku-files und sonstigem, aber halt ohne libc, libc++ und dergleichen)