Sollte man VC spezifisch proggen?

[tori]

Ich habe mich jetzt hier ein wenig im Forum eingelesen und hier wird in fast jedem Thread eine MSVC-spezifische Funktion erwähnt, zu erkennen an den beiden Unterstrichen (__) vor dem Funktionsnamen.

Ich empfinde ein derart compilerspezifisches Programmieren irgendwie als unsauber, so wie wenn ich meine Website mit Spezialfunktionen versehe die nur der IE6 kennt;)

Geht's hier sonst niemandem so oder sehe ich das einfach nur engstirnig? Bringt es so viele Vorteile die überhaupt zu verwenden?

gruß

[waigie]

Naja ich versuche das immer einigermaßen zu vermeiden. Hierbei muss man aber sicher etwas unterscheiden.

Bei einer Website/Webanwendung ist das ein totales no-go. Einfach weil man es nicht nur mit dem IE6 benutzen wird. Anders sieht das aus, wenn man ein Projekt umsetzt was z.B. auf DirectX basiert. Diese Projekte werden nur unter Windows für Windows kompiliert. Wenn es da eine Vereinfachung oder Verbesserung durch diese Funktionen gibt dann nutzt man sie.

Erst recht wenn es sich um ein Hobbyprojekt handelt. Meist schau ich bei Hobbyprojekten einfach nur darauf das es fertig wird und nicht das es sonderlich schön wird.

[tori]

mir ist auch aufgefallen dass der vergleich mir der website etwas hinkt, einfach, weil man nicht sehr oft den compiler wechselt (quasi nie).

mir fallen spontan auch nur open source projekte ein die sich mit verschiedenen compilern kompilieren lassen. da beschweren sich manchmal leute wenn das nicht unter ihrem VC geht obwohl es mit gcc entwickelt wurde... das ist auch etwas seltsam.

vllt etwas zu meinem background: ich bin student und arbeite in den übungen je nach fach/modul mit verschiedenen compilern. Da ich noch nicht weis wo ich später lande finde ich es sinnvoll, nicht allzu Compiler-spezifisch zu werden.

gruß

[Krishty]

Hi und willkommen!

Bei Websites spürt es der Anwender, wenn du was nicht Portables benutzt. Bei C++-Anwendungen hingegen kommt beim Anwender nur Maschinentext an. Bei dessen Ausführung ist es egal, ob der durch VC-spezifische Makros erzeugt wurde oder nicht. Der Einzige, der jemals einen Unterschied spürt, bist du selber – oder alle, die deinen Quelltext verwenden wollen, falls er Open Source ist. Wenn du in großen Firmen programmierst ist es eh so gut wie egal, weil dort selbst Compiler-Einstellungen nur jedes zweite Weihnachten geändert werden, Compiler-Versionen nur in Schaltjahren und Compilertypen nie.

Ich würde auch liebend gern nur Standardfunktionen nutzen, allerdings deckt der C++-Standard nicht alles lückenlos ab. Theoretisch bekommt man fast alles mit purem C++ hin, allerdings manches nur sehr umständlich – das Runden von floats ist so ein Beispiel; da besteht zwischen der portablen C++-Version und einem VC-spezifischen Intrinsic (eine im Compiler fest eingebaute Funktion) ein Geschindigkeitsunterschied von 1:100, den man natürlich gern mitnehmen möchte, wenn man Multimediaanwendungen schreibt. Da muss man dann abwägen ob man lieber ein schnelles, einfaches oder ein überall kompilierbares Programm haben will.

Meistens ist das übrigens garkrein Problem, weil es eh nur eine Handvoll großer Compilertypen gibt und die alle ähnliche Funktionen anbieten, nur unter jeweils anderem Namen. Man kapselt das dann in einer Funktion; per #ifdef findet der Quelltext dann heraus, durch welchen Compiler er übersetzt wird, und wählt das passende Intrinsic aus. Der Rest des Quelltexts nutzt nur die kapselnde Funktion und merkt nichts, wenn die intern für jeden Compiler ein anderes Intrinsic wählt.

Gruß, Ky

[Aramis]

Die Kunst besteht eher darin, zu wissen was jetzt genau VC-spezifisch ist und was nicht :-/ Bei __declspec und Konsorten geht es ja noch einfacher, schwieriger wird es bei spontanen Spracherweiterungen oder Spaessen in der Standardbibliothek.

Wenn es um Portabilitaet geht, wuerde ich immer versuchen, selbst wenn du einstweilen nur mit einem Compiler arbeitest, dir moeglichst viele Optionen offen zu lassen. __declspec etc. kann man beispielsweise wunderbar hinter einem Makro verschwinden lassen, das dann auf einem anderen Compiler ins Leere zeigt.

[Krishty]

Ich glaube, so schlimm ist das Ganze nicht. Ehrlich gesagt ist heute eine goldene Zeit für die Portabilität. Nie waren die Compiler so nah am Standard, und mit jeder Aktualisierung rücken sie näher zusammen. Natürlich kann man beim Portieren erstmal einen Batzen Zeit einplanen um hundert unvorhergesehene Konflikte zu beseitigen — aber vor zehn Jahren konnte man seinen Quelltext schlicht und einfach wegschmeißen wenn man von Visual C++ 6.0 auf GCC 2.0 portieren wollte … noch dazu hat man m.E. nach heute eine höhere Funktionalität-pro-Quelltext-Ausbeute dadurch, dass sich so langsam endlich generische Programmierung und RAII durchsetzen …

D.h., man muss heute für das gleiche Programm weniger Quelltext schreiben, den man hinterher auf kompatiblere Compiler portiert. Und es wird immer besser werden.

(Ich hatte heute erst versucht, meinen über Jahre pur in VC geschriebenen Text auf GCC mit LLVM zu portieren und war positiv überrascht, wie wenig Probleme er gemacht hat.)

[Schrompf]

Sehe ich auch so. Die Zeiten selbst für uns unterbezeitete Hobbyentwickler werden eigentlich immer besser. Was ich aber hier konkret in diesem Forum als Verbesserung anerkenne, ist ein deutliches Hinweisen, falls man in einem Codebeispiel eine compilerspezifische Erweiterung benutzt. Das könnte ein paar Verwirrungen vermeiden.

[Thoran]

Sehe ich auch so. Die Zeiten selbst für uns unterbezeitete Hobbyentwickler werden eigentlich immer besser. Was ich aber hier konkret in diesem Forum als Verbesserung anerkenne, ist ein deutliches Hinweisen, falls man in einem Codebeispiel eine compilerspezifische Erweiterung benutzt. Das könnte ein paar Verwirrungen vermeiden.

Das setzt voraus, dass man sich dessen bewußt ist, ohne das ich das jetzt böse gemeint habe.

Thoran

[Schrompf]

Ja, auch das stimmt. Ich habe gelegentlich schon Dinge propagiert, zu denen mir erst andere Leute erklären mussten, dass das eine MSVC-spezifische Erweiterung ist. Meine peinlichste Diskussion dazu hatte ich vor langer Zeit zum Thema __super - ich kannte das von Java und hielt es für eine valide Option in C++.

Aber dafür ist das ja ein Forum, nicht wahr? Man kann ja auch einfach eine kurze freundliche Notiz hinzufügen, wenn jemand anders eine compiler-spezifische Erweiterung an Lösung anbietet, ohne sich dessen bewusst zu sein. Ist ja nichts Böses, so eine zu benutzen - man muss nur wissen, was man tut.

[Jonathan]

Ich hab es jetzt bei einem Uni Projekt gemerkt, dass VC2010 schon einige tolle C++0X Features unterstützt (auto, override) die auf anderen Compilern nicht funktionierten. Das Override konnte man mit einem Makro in den Griff kriegen, das auto musste ich leider weglassen.
Aber gerade diese Sachen, die heute noch nicht jeder Compiler kann, die aber toll sind und bald im Standard sein werden (oder schon sind?) werde ich auch weiterhin privat benutzen.
Ein bisschen anders sieht es z.B. damit aus, dass sit VC std::exceptions im CTor schon eine Fehlernachricht übernehmen können, obwohl das im Standard wohl nicht vorgesehen ist. An so Sachen merkt man dann, wie bestimmte Hersteller hier und da klammheimlich ein wenig abweichen. War ansich kein großes Ding, aber die Kollegen haben sich trotzdem nicht über die Fehlermeldungen gefreut.

[kaiserludi]

Wenn du in großen Firmen programmierst ist es eh so gut wie egal, weil dort selbst Compiler-Einstellungen nur jedes zweite Weihnachten geändert werden, Compiler-Versionen nur in Schaltjahren und Compilertypen nie.

Man merkt, dass ich für eine kleine Firma arbeite:
Die C++ Variante des Codes kompiliert unter MSVC, GCC und MinGW, die Projekte gibt es für VS, XCode und QTCreator. Als Architektur werden X86 und ARM unterstützt, an OS mittlerweile 8 verschiede Plattformen und das ist nur die C++ Variante, es gibt ja noch Varianten in C, objC, C#, Java, Flash, Javascript :D
Da muss der Code schon recht multiplatform sein. Wir nutzen nicht mal die C++ std-lib, sondern eigene Datentypen für maximale Kompatibilität.

[odenter]

Das hat ja nichts mit der Größe des Unternehmens zu tun, sondern mit den Anforderungen.

Wenn ich protablen Code brauche dann schreibe ich welchen, wenn ich nur eine Zielplatform habe, dann verwende ich auch Platformspezifische Libs, Funktionen/Whatever.

[kaiserludi]

Das hat ja nichts mit der Größe des Unternehmens zu tun, sondern mit den Anforderungen.

Das war auch mit einem Augenzwinkern gemeint ;)

[Krishty]

Ja, ich hatte da ein wenig übertrieben; da hat kaiserludi schon korrekt augengezwinkert. Natürlich gibt es auch große Firmen mit flexibler Quelltextbasis. Aber ebenso gibt es die, deren Produkte (gewollt) seit jeher nur auf einer einzigen Plattform eingesetzt werden, und da ist alles sehr schwerfällig. Da wir bei VC sind ist Microsoft ein passendes Beispiel: Die setzen afaik noch großflächig VS 2005 ein und etablieren erst jetzt Link-Time Code Generation, obwohl es schon seit 2003 in ihren eigenen Compilern ist. Es hängt einfach ein riesiger Rattenschwanz dran (z.B. enthalten einige Windows-Versionen noch 16-Bit-Text, aber die aktuellen VC-Compiler können den nicht mehr erzeugen), es kann viel schiefgehen (weil jede Version neue Bugs enthält oder auch Features Entfernt werden) und je sicherheitskritischer die Anwendung ist, desto mehr setzt man auf etablierte Systeme (was ja nur rational ist). Als Compiler und Linker für Kernkomponenten wie Windows höchstselbst setzen die afaik auch Sonderanfertigungen ein, das verzögert eine mögliche Portierung natürlich erneut.

[odenter]

Das hat ja nichts mit der Größe des Unternehmens zu tun, sondern mit den Anforderungen.

Das war auch mit einem Augenzwinkern gemeint ;)

War auch nicht böse oder so gemeint. :)