[C++] Warum trotz allem Visual Studio-C++-Compiler

[Florian Keßeler]

Und trotzdem bleibt ihr alle bei Microsoft-Compilern...

[Moderator-Aktion: Thema abgespalten von http://zfx.info/viewtopic.php?f=11&t=2501]

[Schrompf]

Weil der GCC unglaublich langsam ist. Irgendwann bau ich mir mal eine weitere Build-Konfiguration, die den GCC zur Erstellung der Release-Version benutzt. Um die letzten paar Prozent Tempo rauszuholen. Die IDE und der Debugger von Microsoft sind jedenfalls ungeschlagen.

[eXile]

Wenn überhaupt, wie Schrompf schon sagte, würde Clang noch in Frage kommen (welcher übrigens ratzeschnell ist), da eben viele Personen nicht auf die IDE und den Debugger von Visual C++ verzichten wollen. GCC kann keine PDB-Informationen ausgeben, weswegen es nicht mit dem Visual-C++-Debugger zu gebrauchen ist. Bei Clang gibt es wenigstens etwas Bewegung, als dass es einen GSoC-2012-Vorschlag für PDB-Support gab, welcher allerdings nicht aufgegriffen wurde.

Oder um es kurz zu machen: Wir bleiben nicht wegen des Microsoft Compilers, sondern wegen der IDE und des Debuggers und trotz des Microsoft Compilers. Mit Abstand den schnellsten Code kriegt man übrigens mit dem ICC-Compiler. Leider hat er auch ziemlich beschränkten C++11-Support.

[dot]

Abgesehen davon, wäre mir sehr neu, dass der GCC wirklich relevant schnelleren Code erzeugt als der MSVC. Bei den meisten Benchmarks, die ich so in Erinnerung hab, war es eigentlich sogar anders rum, wobei der Abstand meistens relativ klein war. Ich weiß aber nicht wirklich, wie es im Moment genau aussieht...

Und auch wenn hier oft drüber geschimpft wird: Es gibt sicherlich schlechtere Compiler als MSVC. Unter Windows seh ich (evtl. vom ICC mal abgesehen) momentan ehrlich gesagt eigentlich keine vernünftige Alternative zu MSVC. MSVC ist nunmal einfach die native Toolchain der Plattform...

Wie mal jemand gesagt hat:

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Gilt wohl für viele Dinge, auch Compiler...

Btw: Vielleicht sollte man die Compilerdiskussion abspalten, um Krishtys Log nicht zu zerreißen.

[Artificial Mind]

GCC hat natürlich seine pathologischen Fälle, wo er wirklich schnelleren Code erzeugt. (Siehe Winning Entry vom Underhanded C Contest 06: http://underhanded.xcott.com/?page_id=15 )

[Florian Keßeler]

Ich meinte das mal ganz unabhängig von irgendwelchen Performance- oder sonstigen Themen. Die Art und Weise, wie Microsoft mit Fehlern in ihren Produkten umgeht, finde ich sehr fragwürdig und wenig transparent. Ich habe jetzt hier schon mehrmals von Bugreports an Microsoft gelesen, die einfach ignoriert oder gelöscht wurden, trotz offensichtlicher Mängel in ihrer Software. Und es gibt ja noch andere Compiler als clang, gcc und den von Microsoft. Dazu kommt, dass zumindest clang und gcc sehr viel besseren C++11-Support bieten.

Die offenen Projekte entscheiden zwar auch ab und zu, dass Bugs zu unwichtig sind. Aber von spurlos verschwundenen Bugreports hab ich noch nichts gehört...

[kimmi]

Hier würde ich einen Laden wie MS nicht gleich vorverurteilen. Auch im GCC-Umfeld wird zum Teil fragwürdig mit Fehlern umgegangen. Ab einem gewissen Nummer an Fehlern muss man halt priorisieren und wenn halt keine Kapa da ist, löst man die, die die größeren Schmerzen verursachen.
Und doch: auch bei OS-Projekten verschwinden gern mal Bugs, weil sie als Dubletten missverstanden wurden und schwupps, weg sind sie.

By the Way: G++ erzeugt bei manchen Benchmarks mit C++11 Support schnelleren Code als MS.

Gruß Kimmi

[Schrompf]

[edit] @Florian: Da stimme ich Dir zu. Diese Art des Umgangs mit Kunden-Feedback ist eine Frechheit, die sich sonst kaum eine Firma leisten kann. Ich weiß jedenfalls, was mir in meinen bisherigen Jobs passiert wäre, wenn ich ein Ticket aus dem Issue Tracker gelöscht hätte...

Für mich persönlich war vor allem Edit&Continue ein echtes Alleinstellungsmerkmal. Und leider scheint das wirklich sonst keiner zu können. Aber wenn das jetzt unter x64 eh verloren ist, könnte man ja mal vorsichtig ausprobieren, wie weit die Konkurrenz in Sachen IDE und Debugger inzwischen gekommen ist. Soweit ich höre, ist der GDB immernoch eine Katastrophe.

[Jonathan]

Für mich war Edit&Continue immer sowas wie schwarze Magie. Man würde den Programmcode im laufenden Programm einfach ändern und danach verhalten sich Objekte einfach anders? Müssten da nicht fast immer schreckliche Dinge passieren, die das Programm direkt zum Absturz bringen?

[Schrompf]

Nein, der Compiler meckert ja bei allen Änderungen, die eine weitere Ausführung gefährlich machen würden. Edit&Continue taugt nur für kleine Änderungen wie "oh, hier hab ich eine Umrechnung in XYZ vergessen" oder "Mal schauen, wie die KI reagiert, wenn ich den Sichttest auf XYZ begrenze". Speziell letzteres finde ich bei Splatter immer wieder toll.

[eXile]

Müssten da nicht fast immer schreckliche Dinge passieren, die das Programm direkt zum Absturz bringen?

Hast du mal einfach versucht, den aktuellen EIP zu verschieben (das ist der gelbe Pfeil links beim Debuggen; ja, den kann man verschieben; am besten direkt von einer Funktion in eine ganz andere!)? Da passieren lustige Sachen! Du bist in Endeffekt immer noch Herr über deine Maschine, und kannst den Prozessor so viel aus dem Tritt bringen, wie du willst; nur bei Ausnahmen sägt dir das Betriebssystem halt den Prozess ab.

Edit-and-Continue hat viele Einschränkungen:

The following C/C++ changes cannot be applied during a debugging session:

• Most changes to global or static data.
• Changes to executables that are copied from another machine and not built locally.
• Changes to a data type that affect the layout of an object, such as data members of a class.
• Adding more than 64k bytes of new code or data.
• Adding variables that require a constructor at a point before the instruction pointer.
• Changes that affect code that requires run-time initialization.
• Adding exception handlers, in some instances.
• Changes to resource files.
• Changes to code in read-only files.
• Changes to code without a corresponding PDB file.
• Changes to code that has no object file.

Die Hervorhebungen sind von mir. Trotzdem kann man, besonders wenn man Arithmetik/Logik-Code schreibt (keine Seiteneffekte) sich so viel Programmier- und Testzeit ersparen.

Außerdem sind Graphikanwendungen und Computerspiele einfach für Edit-and-Continue prädestiniert, weil ja jede Menge Zeugs jeden Frame neu berechnet wird; und damit wird also im nächsten Frame der neue Code benutzt.

[Florian Keßeler]

Schrompf: Der GDB funktioniert super, das Problem ist, dass es einfach keine wirklich brauchbare GUI dafür gibt. Hat mich als GUI-Verweigerer bisher nicht gestört, aber mir ist klar, dass ich mit der Meinung ziemlich alleine dastehe...

[Jonathan]

Außerdem sind Graphikanwendungen und Computerspiele einfach für Edit-and-Continue prädestiniert, weil ja jede Menge Zeugs jeden Frame neu berechnet wird; und damit wird also im nächsten Frame der neue Code benutzt.

Hm cool, dann muss ich das auch mal ausprobieren :)