Jammer-Thread
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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.)
(Anderes Thema für den Jammer-Thread ist, warum Invision-Foren zum Posten Zugriff auf meine Audiogeräte voraussetzen. WTF.)
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
GCC ist der einzige Compiler mit Store Merging.
OMFG.
Falls ihr es nicht glaubt:
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.
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
}
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.
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Internet Explorer 11 auf Windows 10 zerstört Setups beim Herunterladen. Ich kriege das Kotzen. Ich flippe aus. WHAT THE FUCK.
Nachtrag: Oh toll, mit WiX passiert das auch und User melden sowas wie
Nachtrag 2: Okay; es stimmt: MSI-Reparatur schlägt fehl, wenn das MSI umbenannt wurde. Rob Mensching erklärt:
- 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
Nachtrag: Oh toll, mit WiX passiert das auch und User melden sowas wie
undI 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.
Reparatur und Upgrade funktionieren nur, wenn man die Setups aus dem selben Verzeichnis startet?! Dann habe ich ja heute abend was zu testen …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.
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.
- 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.
- 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.
- 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.
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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.
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
Eine Preview ist für Visual Studio 2019 draußen.
Und die Farbgebung ist grottenhässlich.
Und die Farbgebung ist grottenhässlich.
Re: Jammer-Thread
VS2019 installiert:
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 :-)
Code: Alles auswählen
int main(){
gsl::owner<int*> x = new int{ 2 };
*x = 5;
return 0;
}
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 :-)
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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!
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!
- xq
- Establishment
- Beiträge: 1581
- Registriert: 07.10.2012, 14:56
- Alter Benutzername: MasterQ32
- Echter Name: Felix Queißner
- Wohnort: Stuttgart & Region
- Kontaktdaten:
Re: Jammer-Thread
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
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…
Programmiert viel in
Zig
und nervt Leute damit.
Programmiert viel in
- Chromanoid
- Moderator
- Beiträge: 4258
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Jammer-Thread
Ich würde sagen, dass kommt auf den Arbeitskontext an, oder?
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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.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 unbrauchbarenIch kapituliere und klicke halt bei jeder verletzten Assertion acht Zugriffsverletzungen weg.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.
Fuck.
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
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 -.-
Verdammtes Intellisense. Kann das nich wo anders amok laufen? In VS 2013 tat das noch alles -.-
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Die deutsche 3D Community: https://www.3d-ring.de
- dot
- Establishment
- Beiträge: 1734
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Jammer-Thread
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
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 :)
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Die deutsche 3D Community: https://www.3d-ring.de
Re: Jammer-Thread
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.
ich nominiere Microsoft hiermit für den "Worst Product Name" Award.
Re: Jammer-Thread
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.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/
Re: Jammer-Thread
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.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/
Re: Jammer-Thread
*Leise weinend vor sich hinwart*
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Die deutsche 3D Community: https://www.3d-ring.de
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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.
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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:
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.
- xq
- Establishment
- Beiträge: 1581
- Registriert: 07.10.2012, 14:56
- Alter Benutzername: MasterQ32
- Echter Name: Felix Queißner
- Wohnort: Stuttgart & Region
- Kontaktdaten:
Re: Jammer-Thread
Krishty, weißt du zufällig, wie das mit zirkulären Abhängigkeiten bzw. Forward Declarations und Modulen funktioniert?Krishty hat geschrieben:...
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…
Programmiert viel in
Zig
und nervt Leute damit.
Programmiert viel in
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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 …
-
- Establishment
- Beiträge: 467
- Registriert: 18.04.2002, 15:31
Re: Jammer-Thread
MSVC ist mit der Kombination aus CRTP, using-Deklarationen und Funktionstemplates offensichtlich überfordert.
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.
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);
}
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.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
-
- Establishment
- Beiträge: 467
- Registriert: 18.04.2002, 15:31
Re: Jammer-Thread
Die aktuelle Forenversion ist zu doof für korrekte Formatierung in Signaturen.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Clang auf Windows ist noch immer eine Pest.
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.
- 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.
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.
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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?!
__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
Es ist 2019 und ich fixe seit 10 Minuten ein Problem, weil ein Pfad ein Leerzeichen enthält. Ganz toll...
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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.
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.
-
- Moderator
- Beiträge: 2113
- Registriert: 25.02.2009, 13:37
Re: Jammer-Thread
Jemand von euch eine Idee, warum ungefähr alle Steam-Spiele gleichzeitig das gleiche Update brauchten?
- Krishty
- Establishment
- Beiträge: 8240
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Linux und Mac so: Windows ist aufgebläht mit lauter nutzlosem Scheiß. Zehn Gigabyte für Visual Studio, LOL
LLVM so: Hold my beer
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!
LLVM so: Hold my beer
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!
- xq
- Establishment
- Beiträge: 1581
- Registriert: 07.10.2012, 14:56
- Alter Benutzername: MasterQ32
- Echter Name: Felix Queißner
- Wohnort: Stuttgart & Region
- Kontaktdaten:
Re: Jammer-Thread
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:
Das sind hier die kompletten Pakete (also mit allen bins, libs, doku-files und sonstigem, aber halt ohne libc, libc++ und dergleichen)
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
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…
Programmiert viel in
Zig
und nervt Leute damit.
Programmiert viel in