• Login

Dear visitor, welcome to RPG Studio - Make your World real. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

  • Der Imperator

    Oberschurke im Ruhestand

    You have to register first, to connect to this user.

255

Raging about C++ & MSVC--

Rating:

by Der Imperator, Sunday, September 15th 2013, 8:25am

Es ist so weit, und Visual Studio -Nutzer haben einen neuen Grund, sich einen Ast abzufreuen:

Visual Studio 2013 (MSVC 1800) RC ist da!


Ich nutze ja Visual Studio 2012 Ultimate über eine ziemlich praktisches Uni-Partner-Programm. Ohne derartige Rabatt-Quellen würde diese IDE ganz schön ins Geld gehen. Das sind happige 5000€ für die Ultimate-Version. Unbezahlbar, definitiv, aber rappevoll mit verdammt nützlichen Tools für aufwändige Projekte. Gut, die Professional-Variante tut's natürlich auch, kostet aber noch immer satte 500€. Und was ein Upgrade von z.B. 2010 auf 2012 kostet weiß der Kuckuk.

Jedenfalls fließt eine stolze Menge an Bares in eine gute IDE rein - spätestens, wenn man nicht mehr Teil besagter Partner-Programme ist. Aber ist die IDE wirklich so gut? Ist sie das Geld wert? Die Syntax- und Code-Analyse ist Microsoft definitiv gelungen. Zwar gibt es gelegentlich eigenartige Momente, in denen der Syntax-Highlighter kurzzeitig stirbt, doch ist es mir mit Visual Studio noch nie passiert, dass ich zahlreiche Flüchtigkeitsfehler beim nächsten Kompillier-Test beheben musste, da Typ- und Syntax-Fehler in aller Regel sofort gekennzeichnet wurden. Noch beeindruckender finde ich gar, wie gut Visual Studio mitten beim Programmieren Präprozessor-Makros analysieren, und typsicher auflösen kann. In anderen Worten: Ich erkenne es sofort, wenn ein Makro Mist fabriziert, was bei den anderen mir bekannten IDEs (QtCreator, Eclipse+CDT, Code::Blocks,...) entweder garnicht, oder nach scharfem Hinsehen auffällt. Der Compiler teilt es mir sonst irgendwann mal mit, wenn ich teste.

Visual Studio erspart mir also mit seinen Analyse-Werkzeugen viel Arbeit und viele lästige Flüchtigkeitsfehler. Eine dankeswürdige Leistung, die zweifellos eine finanzielle Entlohnung verdient. Die Frage ist allerdings, ob das alles ist, was zählt. Mit Visual Studio kommt auch der MSVC++-Compiler, durch den der ganze Code letztendlich gejagt wird. (Ich bewerte an dieser Stelle mal nicht die Optimierungs-Mechanismen von MSVC im Vergleich zu GCC und Clang) Und am Ende des Projekts zählen bekanntlich und selbstverständlich bloß noch die Binaries, die dann wer-auch-immer nutzen mag. Hier schließlich fängt das erste große Problem von Visual Studio an.

Vor einiger Zeit wurden für C++ neue Standards verabschieded, bzw. sind noch in der Umsetzung. Einer war bekannt als C++0x und erschien als C++11, die anderen kennt man vorsichtig als C++1y und werden voraussichtlich C++14 und C++17 heißen. Die neuen Standards bringen eine stolze Palette neuer Mechanismen und Bibliotheks-Erweiterungen mit sich, die so ziemlich jeden Code zuverlässiger, schneller, sparsamer, und auch sonst auf vielen Wegen einfach besser machen. Gut, die ganzen externen Bibliotheken, die man so verwendet (z.B. Zeug zum Laden von Audio-Dateien), brauchen ihre Zeit, um auf die neuen Features umzusteigen, und werden es größten Teils nie tun. Aber das möge einen nicht daran hindern, den eigenen Code mit C++11/C++1y zu verfeinern.

C++ ist jetzt allerdings eine kompillierte und syntaktisch äußerst komplizierte Sprache. Zudem gibt es da draußen eine stolze Reihe an Compilern, die alle irgendwie im Laufe der Zeit für den neuen Standard aufrüsten müssen. Einer ist da selbstverständlich schneller als der andere, und so kommt es trotz allem zu Kompatiblitäts-Problemen. Um zwei Beispiele anzubringen, die ich sehr mag, sind G++ (GCC) und Clang++ (LLVM) bereits fast völlig fertig mit der Implementierung von C++11 (Die äußerst wenigen, fehlenden Fetzen sind für mich nicht von Belang.) und gehen gar längst C++14 an.

Wie sieht es da mit MSVC++ aus? Eine Liste im MSDN zeigt anschaulich wie auch für GCC und Clang den aktuellen Fortschritt bei der Implementierung von C++11 und C++1y -Features. Dort sind erst 20 von insgesamt 56 Punkten auf der "ToDo"-Liste erledigt, darunter auch Zeug, das ich äußerst häufig verwende, bzw. gern verwenden würde, namentlich noexcept, constexpr, und [[attributes]]. Auffällig ist auch, dass für alte Visual Studio -Versionen keine Features nachgerüstet wurden. Man zahlt also bis zu 5000€ für eine IDE - gut, als Normalsterblicher eher die 500€ -, die von einem milliardenschweren Konzern entwickelt wird, deren Tools und Syntax-Highlighter zwar äußerst gut sind, der mitgelieferte Compiler allerdings um Jahre hinterher schliert. Ich weiß nicht, ob es günstiger kommt, ein Upgrade von einer Version zur nächsten zu machen, sollte es Upgrade-Lizenzen für Professional und Ultimate geben (Was ist so schwierig daran, leicht findbare Preislisten zu veröffentlichen, Microsoft?). Sie werden aber wahrscheinlich abgesehen von Express=>Express nicht umsonst sein. Das sind Momente, in denen ich mich frage, wie viel Geld wohl ohne ein solches Partner-Programm über die Zeit darin fließen würde, den blöden Compiler aktuell zu haben.

Unterm Strich ist der MSVC Compiler definitiv kein Kaufgrund. Auch nicht für Windows-Only-Entwicklung. GCC und Clang z.B. sind wesentlich aktueller, produzieren hochwertigen und schnellen Byte-Code (... es ist so 'ne seltsame Sache, bei Micro-Code-Maschinen von "Maschinen-Code" zu sprechen.), kosten nichts, und sind obendrein Cross-Platform. Vor allem Cross-Platform hat hier für mich einen enormen Reiz, da ich mich so nur auf einen/zwei Compiler konzentrieren muss, die alle auf allen gewünschten Ziel-Systemen laufen (z.B. Linux, BSD, OS X, weitere Unixoide, Windose,...). Ich kann mir den ganzen Spaß ersparen, ständig zwischen __declspec(dllimport) und __attribute__((dllimport)) unterscheiden zu müssen, und - was noch viel wichtiger ist - ich kann mir solch einen lästigen Mist ersparen:

Cpp Source code

1
2
3
4
5
6
7
#ifdef _MSC_VER
#  define my_noexcept throw()
#else
#  define my_noexcept noexcept
#endif
 
void my_never_throwing_fun() my_noexcept;
(Ja, es gibt einen signifikanten Unterschied zwischen throw() und noexcept.) Damals mit dem RC von Visual Studio 2011 musste ich gar auf die wunderschönen range-based-loops verzichten. Man vergleiche:

Cpp Source code

1
2
3
4
5
6
7
std::vector<int> _stuff;
# Mit VS2011...
for(auto i = std::begin(_stuff); i!=std::end(_stuff); ++i) {
  do_stuff(*i);
}
# Ohne MSVC, bzw. ab VS2012...
for(auto i : _stuff) {do_stuff(*i);}
So viel lesbarer, ergo leichter zu warten! Generell kommt es häufiger zu Fällen, in denen ich speziell für MSVC++ irgendwelche "Ach, und wenn der Compiler das nicht kann, dann halt das..."-Makros einbauen musste. Das führte allmälich dazu, dass ich Visual Studio fast nur noch als Code-Editor verwende und den Compiler - wenn's hoch kommt - mal für winzige, triviale Tests nutze. Programmieren mit Visual Studio, kompillieren mit MinGW. So viel angenehmer. So kam ich dann immer mehr auf den Gedanken, auf diese lästigen Kompatiblitäts-Makros zu verzichten und MSVC einfach nicht zu unterstützen. Ich komme damit wunderbar klar. Es erspart mir sehr viel Arbeit und es ist bei kostenfreien Compilern wie GCC und Clang äußerst einfach, von anderen zu erwarten, den Compiler ggf. zu aktualisieren, sollte ich zum Schluss kommen, dass ich den gesamten Quell-Code zur freien Verfügung stellen möchte. Ich komme mit dem Gedanken wunderbar klar. Visual Studio allerdings nicht. Tippe ich z.B. einfach ein noexcept an eine Funktion, gilt das als syntaktischer Fehler und wird mir äußerst nerviger Weise angestrichen, da noexcept für MSVC2013 noch kein gültiges und verarbeitbares Schlüsselwort darstellt (Und ich kann zwar noexcept irgendwie über throw() und wenn ich ganz viel Bock auf hässlichen Code habe über ein Makro für __declspec(nothrow) emulieren, aber das ist einerseits hässlich, gibt andererseits ohne jenes Makro nicht die nötige Strenge der Garantie, und als ob das noch nicht genug wäre, bleiben Fragen offen, wie z.B. was ich mit constexpr machen soll. Hinter constexpr steckt ein völlig anderer Mechanismus als const, vergleichbar mit immutable aus D. Das Schlüsselwort mit const zu emulieren sorgt dafür, dass bestimmte Dinge am Code mit MSVC nicht möglich sind).

Es hat für mich also auf Dauer keinen Zweck beim in den Himmel als Non-Plus-Ultra der C++-Entwicklung bewertetem Visual Studio zu bleiben. Mal sehen, vielleicht nutze ich Code::Blocks oder QtCreator. Haben mir beide auf meinem Tux-Netbook lang und gut gedient. Vielleicht teste ich mal Netbeans mit C++ oder schließe gar Frieden mit Eclipse und CDT. Das sind allerdings nicht alle Gründe, mich von Visual Studio abzuwenden.
Bild
Mal ehrlich, WTF?!

Was für einen Hirnschmalz dachte sich Microsoft? Entweder ist dies die armseligste Art, dem Proletariat einen Brauser anzudrehen, der so scheiße ist, dass man als Website-Betreiber so zu sagen Schmerzensgeld für die Entwickler verlangt, oder Visual Studio meint aus irgendwelchen Gründen einen Browser verbauen zu müssen, um... weiß Gott, was für einen Content vom MSDN oder Microsoft's Website anzuzeigen, der mich nicht die Bohne interessiert. Wahrscheinlich auch noch Werbung, wenn ich mir so manche Office-Versionen oder Windoof 8.1 anschaue. Wahrscheinlich ein Mix aus beidem. Danke, Microsoft, aber ich bin ganz glücklich mit meinem externen Firefox, und ihr scheint Firefox selbst lieber zu mögen. (In einem Presse-Video zu Windows 8 wurde an einer Stelle der neue Internet Explorer gezeigt, als ein Update-Popup von Firefox auf plöppte. Zu faul, den Link zu suchen. Findet sich auf Golem.de: IT-News für Profis ) Wie heißt es so schön? Zahle für das, was man auch nutzt.

Ich nutze jetzt erstmal wieder Code::Blocks und TortoiseGit.

Gruß und Segen,
Der sich mal auskotzende Imperator

This article has been read 3,222 times.

Tags: C++, C++11, C++14, MSC, MSVC, Visual Studio

Categories: Neuigkeiten


Comments (4)

  • 4

    by Der Imperator (Thursday, September 19th 2013, 7:29pm)

    Nun, ICC kostet für Windows erneut ein stolzes Sümmchen und ein GCC-Plugin gibt's ebenfalls nur für Bares. Ergo kann man Visual Studio als Normalsterblicher effektiv nur mit MSVC nutzen.
    ICC ist btw. dafür bekannt, so zu kompillieren, dass der Code zwar auf Intel-Rechnern flott läuft, sich hingegen auf AMD-Rechnern eher schleppt. Miese Geschichte.

    Vim und Emacs hatte ich mal getestet. War interessant, und es würde mir genügen, aber ich genieße einfach den Komfort von IDEs, die einem fix Rückmeldung geben.

  • 3

    by Ankou (Tuesday, September 17th 2013, 12:51pm)

    Prinzipiell ist es möglich Visual Studio mit anderen Compilern zu verwenden, für Intels Compiler gibts das schon eine Weile, aber so verbreitet scheint das nicht zu sein. Visual Studio hatte aber noch andere Probleme, z.B. einen mangelhaften Support von kompilieren auf mehreren Kernen. Wobei andere IDEs auch nicht besser waren, Code::Blocks hat mich 2 mal durch Bugs verloren, Eclipse CDT ist furchtbar langsam(selbst mit SSD) und indiziert ständig (Eclipse für Java ist schon nicht das schnellste, aber CDT ist noch wesentlich schlimmer) außerdem hat es beim letzten mal völlig zufällig andere Projekte neu kompiliert (was in dem Fall 20 Minuten gedauert hat) und QtCreator is zwar ganz ok, aber Features hatte das Ding nicht so wirklich viele. Dann gibts da noch CodeLite, das war ganz "ok".

    IDEs sind eine tolle Sache ... für andere Sprachen. Für C++ bleib ich lieber bei der Kommandozeile und einem guten Editor (vim, sublimetext, whatever)

  • 2

    by Kenai (Tuesday, September 17th 2013, 9:01am)

    Was auch an MSVC++ nervt, sind diese Laufzeitbibliothek-Parameter (/MT, /MD usw.). Es nervt einfach, dass man fast gezwungen wird, auf jedem Zielrechner diese Visual C++ Redistributable installieren zu müssen. Sicherlich hat das fast jeder schon installiert und es soll irgendwo auch Ressourcen sparen... aber manche haben es eben nicht auf ihrem System und die DLLs in den Binary-Ordner zu hauen, ist auch eine Lösung, aber irgendwie auch sinnlos. :3

    Du nutzt jetzt also Code::Blocks... Hmmm, dann werde ich mal Eclipse mit MinGW ausprobieren. Sieht recht vielversprechend aus. =)

  • 1

    by Kenai (Tuesday, September 17th 2013, 9:00am)

    Och, wirklich gut geschrieben. =) Jetzt hast du mir so ins Gewissen geredet, dass ich vielleicht auch noch mal über MinGW und irgendeiner kostenlosen IDE-Alternative nachdenken möchte.

    Bisher ist bei mir aber leider so, dass ich zwar schon öfter immer kurz vor dem Umstieg stand, aber als es dann um die Wahl einer IDE ging, ich nicht so recht wusste, welche nur die wirklich Bessere ist. Ja ich weiß, das kann man nie so recht sagen, aber das ist derzeit der einzige Grund, was mich _noch_ davon abhält. Umsteigen würde ich gerne, auch weil es in letzter Zeit enorm cool ist, alles plattformunabhängig zu entwickeln. ^_^

Blog navigation

Previous article

Stronghold 3 - Fluch oder Segen?!

by Der Imperator (Monday, October 24th 2011, 11:48pm)