Entwicklungsumgebung für C++ - Aber welche?

[joehler]

Hallo,

es sind schon ca. 20 Jahre her, als ich den letzen C Code unter DOS geschrieben hatte. Gerne würde ich zum Spass als Hobby wieder in die Materie einsteigen und C++ unter Windows programmieren. Ziel wäre vorerst, in die Sprache C++ und in die Tiefen des Windows 7 einzutauchen. Aber welche Entwicklungsumgebung ist empfehlenswert? Früher programmierte ich noch mit Borland C aber die Firma gibt es nach meinen Wissen nicht mehr. Welche Entwicklungsumgebung ist für den Wiedereinsteig empfehlenswert und läuft auch unter 64 Bit?

JOEHLER

[TheGamer]

Visual Studio

[Baalzamon]

Ich entwickel jetzt schon seit längerer Zeit (mehr als 2 Jahre) mit Eclipse/CDT. Ich bin damit wirklich sehr zufrieden, die Umgebung hat über die letzten paar Versionen echt extreme Forstschritte gemacht und ist im Gegensatz zu Visual Studio kostenlos. ;)

Für Windows gibts ein fertiges Paket: http://code.google.com/a/eclipselabs.org/p/wascana/downloads/list

[TheGamer]

Visual Studio Express ist auch kostenlos

[Gast]

unter Windows führt im Grunde kein Weg an Visual Studio vorbei. Wenn du aber eh bei fast 0 anfängst so würde ich direkt mit C# einsteigen.

[Locutus2002]

Eine ebenfalls kostenlose und sogar plattformübergreifende C++-Entwicklungsplattform ist das Qt-SDK

http://qt.nokia.com/downloads

Das SDK enthält alles was Du brauchst, d.h. die Bibliotheken, einen Compiler und Entwicklungsumgebung. Alternativ kannst Du aber auch Eclipse benutzen, musst dort "nur" die Bibliotheken einbinden (so hats ein Kollege gemacht) oder das Visual Studio (dafür gibts ein Qt-Plug-In).
Mir selbst reicht das SDK bis jetzt vollkommen, ist aber eher für Anfänger. Bei komplexeren Projekten braucht man schon einen besseren Debugger.

[joehler]

Ich hatte vor, mich in C++ einzufuchsen. Es wurde als weitere Programmiersprache noch C# empfohlen. Welche hat mehr Zukunft, bzw. wird in der Zukunft länger bestehen bleiben?

Wo sind die konkreten Unterschiede?

[huha]

C++ hat definitiv mehr Zukunft, weil's einfach wesentlich hardwarenäher ist.
Die Frage, die ich mir allerdings stellen würde: Was willst du machen? C++ ist (zumindest aktuell, mit C++0x scheint sich ja zumindest punktuell was zu verbessern) eine veritable Scheißsprache, die man eben ertragen muß, wenn man bestimmte Dinge machen will.
Willst du die allerdings nicht machen (und das kann im Hobby-Bereich durchaus der Fall sein), würde ich eher zu komfortableren Sprachen raten, die zwar im Prinzip langsamer und nicht so portabel sind, dafür aber viele Probleme bereits im Kern vermeiden.
Hobbymäßig würde ich daher C# klar vorziehen, sofern du nicht sehr spezielle Anforderungen hast.

-huha

[Trap]

C++ hat definitiv mehr Zukunft, weil's einfach wesentlich hardwarenäher ist.
Das scheint mir genauso plausibel wie die Umkehrung: C# hat definitiv mehr Zukunft, weil es die Hardware einfach wesentlich mehr abstrahiert.

Auf jeden Fall sind beide Sprachen groß genug, dass sie mehrere Jahrzehnte bräuchten um unterzugehen. C# ist mittlerweile ähnlich komplex wie C++, man kann mit der Komplexität aber IMO mehr anfangen. C++ würde ich nur empfehlen, wenn du einen guten Grund dafür hast.

Eine Übersicht zur Verbreitung der Programmiersprachen gibt es auf http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

[del_4901]

C++ hat definitiv mehr Zukunft, weil's einfach wesentlich hardwarenäher ist.
C ist noch vielaus hardwarenaeher, und trotzdem wuerde keiner auf die Idee kommen jetzt noch ein Projekt in C anzufangen.
Zumal viele Projekte inzwischen C# mit C++ mischen. Ich finde das C# mehr Zukunft hat, weil .Net eine grosse Sprachvielfalt hat.

[Gnafoo]

Was heißt mehr Zukunft? Sprachen sterben ja nicht einfach. Nur die Nutzerbasis ändert sich und die steigt denke ich in C# eher, weil sich .NET einfach zu einer der besten Entwicklungsumgebungen in Windows mausert.

Technisch betrachtet sind C++ und C# zwei paar Schuhe. C++ ist eine Sprache der alten Schule, die direkt in Maschinencode übersetzt wird (was nicht schlecht sein muss), C# geht den Pfad, den auch Java eingeschlagen hat: virtuelle Maschine, Garbage Collection etc. Bequemer ist imho ganz klar C#, auch weil es einfach neuer und moderner aufgebaut ist. Kein Stress mehr mit undefined Behaviour, ungenau definierten Datentypen, ungültigen Zeigern, String-Handling etc.

Für C++ sprechen: mehr Kontrolle und ein gewisser Performance-Vorteil, wenn man die Kontrolle zu nutzen weiß (das sollte man aber imho nicht überbewerten, C# ist auch kein lahmer Esel). Man hat bei C++ mehr Bibliotheken zur Auswahl, braucht diese aber auch häufiger (weil man nichts vergleichbares zum .NET-Framework hat). Wenn man das nicht braucht, ist C# imho eine hervorragende Alternative.

.NET/C# ist ansonsten natürlich stark Windows-zentriert, unter Linux kommt man mit Mono aber inzwischen auch recht weit (wenn vielleicht auch nicht immer mit den neuesten Features).

Wenn ich die Wahl habe, ziehe ich inzwischen C# vor, einfach weil es sich viel angenehmer programmiert. C++ ist sicher auch eine gute Sprache, aber ohne die nötige Erfahrung fällt man schnell in irgendeine Stolperfalle oder macht sich das Leben unnötig schwer. Unter Windows ist eine .NET-Sprache stattdessen sicher keine falsche Entscheidung. Gerade bei Anwendungen mit GUI kommt man mit Visual Studio und Windows Forms/WPF sehr schnell und bequem zu einem Ergebnis und das motiviert.

[Shink]

C ist ja zur Zeit (als Assembler-Ersatz z.B. für Embedded-Bereiche, zeitkritisches Zeug o.ä.) wesentlich wichtiger als C++.

Trotzdem wird es mE auch nach unserem Tod noch Bedarf an Entwicklern für alle genannten Programmiersprachen geben.
Es sind ja z.B. auch noch genug Fortran- und COBOL-Programme im Einsatz.

[Exxtreme]

Es wäre halt interessant zu wissen was der TE so machen möchte.

[Gauron Kampeck]

Alle Sprachen haben Zukunft, weil sie alle ihr Anwendungsgebiet haben. C für kleine µC (Motorsteuerungen usw.), C++ für mittlere/größere µC auf denen komplexere Datenmodelle verwendet werden sowie wirklich performancekritische PC-Anwendungen, C#/Java für hardware-abstrake, domänenorientierte Programme.

[huha]

Eine Sprache wie C# ist zwar nett, bietet aber nichts, was sie davor schützt, durch modernere Sprachen abgelöst zu werden. Eine Sprache wie C++ ist ziemlich lästig, ist aber eben noch hardwarenah genug, um auch in Zukunft noch für hardwarenahe Programmierung benötigt zu werden. Es gibt unglaublich viel Embedded-Code, den man nicht einfach mit einer virtuellen Maschine und JIT-Compilern erschlagen kann, weil dort Preis, Energieverbrauch, Performance, Speicherverbrauch, Binary-Größe, uswusf. zählen. Insofern denke ich, daß C++ mehr Zukunft hat als C#, da man C++ kaum durch etwas 'Besseres' ersetzen kann, ohne die Maschinenorientierung so weit aufzugeben, daß man immer noch für dieselben Zielplattformen entwickeln kann.
C# hingegen ist eine moderne Sprache, die sicherlich irgendwann durch noch modernere Sprachen ersetzt werden wird, die eben die identische Programmiersprachen-Nische besetzen. ;)

Insofern muß davon ausgegangen werden, daß uns C++ noch sehr, sehr, sehr lange beglücken wird, bei C# weiß man das nicht so recht. Dennoch würde ich für die hobbymäßige Windows-Programmierung C# deutlich vorziehen, Zukunftstauglichkeit hin oder her (C# wird sicher nicht über Nacht ersetzt und die Codebasis ist groß, das Veralten ist also keine aktuelle "Bedrohung").

-huha

[Shink]

Eine Sprache wie C++ ist ziemlich lästig, ist aber eben noch hardwarenah genug, um auch in Zukunft noch für hardwarenahe Programmierung benötigt zu werden.
Die Sprache C# könnte man natürlich auch ohne JIT ausführen. Davon abgesehen könnte man C++ durch etwas D-ähnliches ersetzen. (Rein theoretisch - ich sag ja gar nicht dass ich das wahrscheinlich finde.)

Edit: Ja, ich mag C++ nicht. Wenn es hardwarenahe sein soll (Betriebssystem, Treiber, Shader-Programmierung, VM-freier Embedded-Bereich) dann finde ich C angebracht, ansonsten würde ich natürlich Java, C# oder gar etwas dynamischeres bevorzugen.

[joehler]

Es wäre halt interessant zu wissen was der TE so machen möchte.
Ein bestimmtes Projektziel verfolge ich nicht. Sondern ich möchte aus Neugier wieder in die Programmierung einsteigen.

[Shink]

Dann würde ich sagen: Tiefen von Windows 7 -> C# mit Visual Studio Express

[Exxtreme]

Also ab hier ist es eigentlich egal was man nimmt.

Ich würde C# oder Java nehmen.

C++ ist zwar sehr "pragmatisch", es ist aber sehr abhängig von irgendwelchen Klassenbibliotheken, es hat einen Haufen Redundanzen drinne, es ist recht fehleranfällig, man muss relativ oft auch C nutzen etc.

[Gnafoo]

Jop sehe ich auch so.

Bitte nicht falsch verstehen, ich mag C++ und würde es jederzeit reinem C vorziehen, aber es gibt jede Menge Altlasten, die wegen der C-Kompatibilität mitgeschleppt wurden. Das Resultat ist, dass es meist sehr viele Wege gibt etwas umzusetzen und gerade als Anfänger schnappt man gerne mal die schlechtere Lösung auf.

Wenn man diese ganzen ekligen Details mit Hilfe von RAII, STL-Containern, String-Klassen, Smart Pointern, Referenzen und co. umgeht, dann kann man durchaus elegant mit der Sprache arbeiten (ab C++0x noch mehr), aber man ist nicht dazu gezwungen. Hinzu kommt, dass die Sprache teilweise einfach ungenau definiert ist (um auf möglichst vielen Plattformen zu laufen). Da kommen dann sehr kuriose Dinge heraus (z. B. das der signed overflow undefiniert ist oder dass Integer-Typen keine eindeutig definierte Breite haben).

Imho ist C++ eine Sprache die recht schwer gut zu beherrschen ist. Einem Anfänger, der nicht darauf angewiesen ist, würde ich eher zu C#/VB.NET oder Java raten (unter Windows eher .NET, ist aber Geschmackssache). Inzwischen lassen sich damit auch fast alle Anwendungsfälle abdecken.

[Zephyroth]

Wenn's rein um C/C++ geht und eventuell noch für Win und Linux sein soll, dann kann man auch Codeblocks mit dem GCC verwenden. Ich arbeite damit und mache eigentlich ganz gute Erfahrungen (wobei der Schwerpunkt im embedded Bereich mit dem SDCC liegt).

Grüße,
Zeph

[Trap]

Wann man diese ganzen ekligen Details mit RAII
RAII find ich extrem elegant, wenn man es damit vergleicht, wie man das Problem in Java lösen muss, wenn die Ressource nicht durch die JVM automatisch verwaltet wird.

Aber grundsätzlich hast du natürlich Recht, C++ ist sehr komplex und um es gut nutzen zu können muss man nicht nur wissen was es gibt, sondern vor allem auch die unendlich vielen Dinge, die man alle besser nicht macht. :freak:

[Gnafoo]

Hm vielleicht ist das falsch herübergekommen (hab den Text zur Sicherheit mal umformuliert). Ich wollte nicht sagen, dass RAII ein ekliges Detail ist, sondern dass man diese ganzen Details (in diesem Fall Ressourcen-Management) mit RAII & co. umgehen/kapseln/vermeiden kann. RAII finde ich selbst eigentlich auch sehr elegant.

[Ectoplasma]

Nimm Visual Studio Express. Alles andere hängt doch sehr hinterher. Vorallem der Debugger ist nach wie vor unschlagbar. Visual Studio Express kann man auch für 64 Bit Plattformen umstellen, allerdings ist das etwas tricky.

[Senior Sanchez]

Mit C++ habe ich gerade auf Arbeit so meine Probleme. Der Compiler läuft einwandfrei durch, aber wenn ich ein Objekt einer bestimmten Klasse auf dem Heap erzeuge, kracht die Anwendung mit einer Access Violation weg! Ehrlich gesagt, weiß ich noch nicht, ob der Fehler in der Parameterübergabe an den Konstruktor (simpler Call-by-value) oder an der Objekterzeugung an sich liegt. Aber das schaue ich mir morgen an.

[Coda]

Edit: Ja, ich mag C++ nicht. Wenn es hardwarenahe sein soll (Betriebssystem, Treiber, Shader-Programmierung, VM-freier Embedded-Bereich) dann finde ich C angebracht
Ich nicht. Ich finde genauer gesagt C praktisch nie angebracht. Selbst für rein prozeduralen Code bietet C++ mehr als genügend Vorteile. Bspw. Referenzen, const correctness, bessere Typsicherheit, Templates oder die STL. Und mit C++0x kommt da noch mehr dazu.

Den einzigen Sinn an C sehe ich noch darin, dass es momentan die einzige Low-Level-Sprache ist, die sich von Beweisassistenten verifizieren lässt.

Dieses geradezu manische Festhalten an C in bestimmten Kreisen vernichtet Produktivität ohne Ende. Ich will nicht wissen wieviele Leute in C schon Hashmaps, Linked Lists etc. neu geschrieben haben, obwohl die STL-Container sowohl besser designed, typsicher und in den allermeisten Fällen auch noch schneller sind. Geradezu groteske Züge nimmt das bei Gnome und GTK an wo sie C mit einer radioaktiv mutierten Abart einer Objektorientierung erweitert haben.

Der schlechte Ruf von C++ rührt wohl von der leider vorhanden Möglichkeit her, kompletten Schrottcode mit beliebig großer C-Einstreuung zu produzieren. Es ist eine sehr feine Sprache, wenn man weiß was man tut. Das heißt aber nicht, dass es für die meisten Zwecke nicht doch bessere Alternativen gibt. Ich bin beispielsweise ein großer Fan von den neueren Multiparadigma-Sprachen wie Scala oder F#.

Nimm Visual Studio Express. Alles andere hängt doch sehr hinterher. Vorallem der Debugger ist nach wie vor unschlagbar. Visual Studio Express kann man auch für 64 Bit Plattformen umstellen, allerdings ist das etwas tricky.
Eclipse CDT bietet sehr ähnliche Funktionalität und in Teilbereichen sogar mehr. Unter Windows fährt man aber mit VC++ besser, weil das meiste dafür entwickelt wurde.

Mit C++ habe ich gerade auf Arbeit so meine Probleme. Der Compiler läuft einwandfrei durch, aber wenn ich ein Objekt einer bestimmten Klasse auf dem Heap erzeuge, kracht die Anwendung mit einer Access Violation weg! Ehrlich gesagt, weiß ich noch nicht, ob der Fehler in der Parameterübergabe an den Konstruktor (simpler Call-by-value) oder an der Objekterzeugung an sich liegt. Aber das schaue ich mir morgen an.
Falls die App auch auf Linux oder OS X läuft teste es mit valgrind. Du schreibst mit großer Sicherheit irgendwo über nen Buffer raus.

[Senior Sanchez]

Falls die App auch auf Linux oder OS X läuft teste es mit valgrind. Du schreibst mit großer Sicherheit irgendwo über nen Buffer raus.

Leider nein, ist unter Windows XP und da stecken einige Libraries drin, sodass ich das leider auch nicht schnell portieren kann (zumal dabei auch wieder ganz andere Dinge schief gehen können).

In diese Richtung habe ich auch schon gedacht, aber bisher konnte ich noch nichts Seltsames sehen.

Mal aber generell eine Frage an dich. Angenommen ich habe einen vector auf strings. Diesen vector könnte ich ja im lokalen Methodenstack aber auch auf dem Heap erzeugen. Bei der ersten Variante ist mir aber nicht klar, wie der Compiler dafür sorgt, dass ich neue strings in den vector einfügen kann ohne das irgendetwas im lokalen Methodenstack überschrieben wird.
Weißt du das zufällig?

Klar, er könnte einfach ein bisschen Platz lassen, aber dann bräuchte er trotzdem irgendwie eine Information, wie viel Elemente hinzugefügt werden.
Oder sollte man solche Container generell auf dem Heap erzeugen, wo es nicht diese Platzprobleme gibt?

[Ectoplasma]

C verwendet man dort, wo es System-Calls gibt oder für Low-Level Kommunikation in plug-ins. Denn dummerweise sind C++ Calls unter den verschiedenen C++ Compilern nicht portabel.


Geradezu grotteske Züge nimmt das bei Gnome und GTK an wo sie C mit einer radioaktiv mutierten Abart einer Objektorientierung erweitert haben.

Full ack. Das ist echt kranker Shit. Da können nur echte Nerds draufkommen.

[ScottManDeath]

OT@Senior Sanchez: std::vector (re)alloziert Speicher auf dem Heap und speichert die Pointer darauf in Instanzvariablen ab, und gibt ihn auch wieder frei, unabhaengig davon ob die Instanz von std::vector auf dem Stack oder dem Heap liegt.

Lesen, jeden Tag einen der Artikel!

http://www.gotw.ca/gotw/index.htm

oder gleich seine Buecher kaufen!

[joehler]

Danke für die SUPER Tipps!!
Ich werde mich in Richtung C# orientieren und meine ersten Gehversuche mit dem Buch Einstieg in Visual C# 2010: Inkl. Visual Studio Express Editions (http://www.amazon.de/Einstieg-Visual-2010-Editions-Computing/dp/3836216116/ref=sr_1_1?ie=UTF8&qid=1299838078&sr=8-1) unternehmen.

[del_4901]

Danke für die SUPER Tipps!!
Ich werde mich in Richtung C# orientieren und meine ersten Gehversuche mit dem Buch Einstieg in Visual C# 2010: Inkl. Visual Studio Express Editions (http://www.amazon.de/Einstieg-Visual-2010-Editions-Computing/dp/3836216116/ref=sr_1_1?ie=UTF8&qid=1299838078&sr=8-1) unternehmen.
Ich wuerde eher das hier nehmen: http://apress.com/book/view/1430225491 Das kannst du auch als Nachschlagewerk verwenden.

Wenn du dir das nicht zutraust, dann evtl. das hier: http://apress.com/book/view/1430231718 aber da weiss ich nicht wie gut das wirklich ist.

[Odal]

C ist noch vielaus hardwarenaeher, und trotzdem wuerde keiner auf die Idee kommen jetzt noch ein Projekt in C anzufangen.
Zumal viele Projekte inzwischen C# mit C++ mischen. Ich finde das C# mehr Zukunft hat, weil .Net eine grosse Sprachvielfalt hat.

C fehlt im großen und ganzen der OO overhead das macht es unter umständen performanter ansonsten gibts für viel peripherie eher c libs
ansonsten seh ich da nicht wirklich mehr hardwarenähe

@topic auch wenn du plötzlich (warum auch immer?) auf c# umgeschwenkt bist

als freie c++ entwicklungsumgebung würde ich codelite mit gcc (bzw. mingw unter windows) http://codelite.org/ empfehlen (kannst natürlich auch intel oder ms compiler einbinden)

hat imho mit abstand die beste codecompletion (zumindest was non commercial anbelangt) und ein recht durchdachtes interface....

kostenpflichtig ist sicherlich ms visual studio unter windows besser wobei mir das zu überladen ist.

und wenn du einfach zum lernzweck schnell ein paar resultate willst kannst du ja mal was mit der sfml lib (simple fast media lib http://sfml-dev.org/ ) machen

[Gnafoo]

C fehlt im großen und ganzen der OO overhead das macht es unter umständen performanter ansonsten gibts für viel peripherie eher c libs ansonsten seh ich da nicht wirklich mehr hardwarenähe

Welcher Overhead denn? Ich sehe nicht, warum C++ hier irgendwie langsamer sein sollte, als C mit Funktionen + Strukturen. Im Gegenteil: Funktoren sind häufig effizienter als Funktionszeiger, Template-Container können effizienteren Code erzeugen als das malloc/void*-Geraffel, das ich in C brauche etc.

C-Libraries kann ich natürlich auch in C++ nutzen, das ist kein Grund.

[Exxtreme]

C fehlt im großen und ganzen der OO overhead das macht es unter umständen performanter ansonsten gibts für viel peripherie eher c libs
ansonsten seh ich da nicht wirklich mehr hardwarenähe

Also ich sehe da nicht wirklich wo es viel Overhead geben sollte nur wegen OO. Es gibt IMHO kaum Gründe C zu benutzen. Ausser vielleicht irgendwelche DLL-Aufrufe weil es in C++ keine einheitliche Konvention gibt und jeder Compilerhersteller seine eigene Suppe kocht. Die Aufrufe als C-Funktionen bereitzustellen ist halt der kleinste gemeinsame Nenner. Ist halt eins der vielen unschönen Dinge in C/C++.

[joehler]

Ich bin auf C# umgeschwenkt, da ich vermute, dass die Sprache für Einsteiger zugänglicher sein wird als C++. Denn vor 20 Jahren hatte ich das letzte mal mit C und Assembler unter DOS programmiert und vor x Jahren mit NewtonScript! Ich fange somit eignetlich wieder von Null an und nur zum Spaß, damit die grauen Zellen nicht verkalken :-)

[Odal]

Also ich sehe da nicht wirklich wo es viel Overhead geben sollte nur wegen OO. Es gibt IMHO kaum Gründe C zu benutzen. Ausser vielleicht irgendwelche DLL-Aufrufe weil es in C++ keine einheitliche Konvention gibt und jeder Compilerhersteller seine eigene Suppe kocht. Die Aufrufe als C-Funktionen bereitzustellen ist halt der kleinste gemeinsame Nenner. Ist halt eins der vielen unschönen Dinge in C/C++.


ok ich hab mich evtl. falsch ausgedrückt ich sag mal so es verleitet weniger effizienten code zu produzieren je nachdem inwieweit man den compiler sinnloser weise objektkopien anlegen lässt und generell die speicherverwaltung dem default destruktor belässt

das soll nicht heissen das man mit c++ nicht deutlich produktiver sein kann

[Xmas]

Eine Sprache wie C# ist zwar nett, bietet aber nichts, was sie davor schützt, durch modernere Sprachen abgelöst zu werden.
Das würde ich prinzipiell als großen Vorteil sehen, sofern man nicht gerade darauf aus ist, durch Kenntnis veralteter Sprachen Jobsicherheit zu erreichen.

[creave]

Eine Sprache wie C# ist zwar nett, bietet aber nichts, was sie davor schützt, durch modernere Sprachen abgelöst zu werden.


Sehe ich auch nicht so als Problem, eine Sprache doch auch weiterhin nur ein Werkzeug. Vielmehr entscheidet man sich mit C# für .NET, und das wird mit ziemlicher Sicherheit noch lange leben und bei Bedarf auch neue, moderne Sprachen erhalten. Ein Beispiel wäre hier F# zu nennen, auch wenn es nur ein Jahr jünger ist als C#.

[Coda]

C fehlt im großen und ganzen der OO overhead das macht es unter umständen performanter
Ich kann für jedes C++-OOP-Konzept, das falsch angewendet wird auch äquivalent schlechten C-Code schreiben. Das ist ein Mythos der sich echt hartnäckig hält.

C verwendet man dort, wo es System-Calls gibt oder für Low-Level Kommunikation in plug-ins. Denn dummerweise sind C++ Calls unter den verschiedenen C++ Compilern nicht portabel.
Dafür gibt es extern "C" in C++. Auch kein Grund.

[Gnafoo]

ok ich hab mich evtl. falsch ausgedrückt ich sag mal so es verleitet weniger effizienten code zu produzieren je nachdem inwieweit man den compiler sinnloser weise objektkopien anlegen lässt und generell die speicherverwaltung dem default destruktor belässt

das soll nicht heissen das man mit c++ nicht deutlich produktiver sein kann

Ich stimme da eigentlich Coda zu: der häufig beschworene „OOP-Overhead“ ist ein Mythos der sich hartnäckig hält. Sorry aber deine Begründing ist mir zu schwammig: der Default-Destruktor hat mit der Speicherverwaltung nichts am Hut (das kann bei einem eigenen Destruktor natürlich anders aussehen) und was an temporären Objekten so teuer sein soll weiß ich auch nicht. Ein std::pair ist auch nicht teurer als zwei Variablen. Ein temporäres Objekt ohne Zustand (Funktoren z. B.) muss afaik nicht einmal alloziert werden.

Aber mal ganz abgesehen davon: wen interessiert das wirklich? Diese Performance-Überlegungen sind doch bestenfalls für 10% des Codes interessant und diese 10% lassen sich in C++ mindestens genauso gut optimieren, wie bei C (natürlich erst, nachdem mit einem Profiler verifiziert wurde, dass man an der Stelle einen Hotspot hat).

Auf der anderen Seite profitiert der restliche Code unheimlich von dem sauberen C++-Code und der besseren Wartbarkeit.

[joehler]

Wenn ich es richtig verstanden habe, werden alle Sprachen (C#, F#, ...) innerhalb der .NET Infrastruktur nicht nativ sondern in die Common Intermediate Language übersetzt. Die CIL wird dann nicht direkt in Maschinencode ausgeführt sondern interpretiert. Leidet hierbei die Performnace stark draunter oder ist dies in der Praxis nicht spürbar.

[Senior Sanchez]

OT@Senior Sanchez: std::vector (re)alloziert Speicher auf dem Heap und speichert die Pointer darauf in Instanzvariablen ab, und gibt ihn auch wieder frei, unabhaengig davon ob die Instanz von std::vector auf dem Stack oder dem Heap liegt.

Ah, danke für die Info! So macht das Sinn.

Btw, mein Problem ist gelöst. Es lag an einer eingebundenen Library, denn jedes Mal, wenn ich ein Objekt einer bestimmten Klasse dieser Library erzeugt habe, gabs die Access Violation.

Mit einer älteren Version der Library läufts dagegen einwandfrei.

[del_4901]

Wenn ich es richtig verstanden habe, werden alle Sprachen (C#, F#, ...) innerhalb der .NET Infrastruktur nicht nativ sondern in die Common Intermediate Language übersetzt. Die CIL wird dann nicht direkt in Maschinencode ausgeführt sondern interpretiert. Leidet hierbei die Performnace stark draunter oder ist dies in der Praxis nicht spürbar.
Solange du den Code nicht auf einer Playstation etc. ausfuehren musst, wirst du davon nicht viel mitbekommen.

[ScottManDeath]

CIL wird Just In Time zu nativem Maschinencode compiliert wenn eine Methode das erste mal aufgerufen wird. Man kann auch das Programm bei der Installation komplett in nativen Maschinencode.

Bei Java wurde urspruenglich der Bytecode interpretiert, aber moderne Runtimes kompilieren auch zu nativen Maschinencode.

[Gnafoo]

Wenn ich es richtig verstanden habe, werden alle Sprachen (C#, F#, ...) innerhalb der .NET Infrastruktur nicht nativ sondern in die Common Intermediate Language übersetzt. Die CIL wird dann nicht direkt in Maschinencode ausgeführt sondern interpretiert. Leidet hierbei die Performnace stark draunter oder ist dies in der Praxis nicht spürbar.

Das ist im Prinzip richtig. Allerdings wird die CIL nicht interpretiert, sondern von einem JIT-Compiler zur Laufzeit in Maschinencode übersetzt.

Das kann sogar Performance-Vorteile bringen, weil der JIT-Compiler die Zielplattform genau kennt und ggf. zur Laufzeit besser analysieren kann, wie erfolgreich gewisse Optimierungen sind. Auf der anderen Seite kommt es beim kompilieren in nativen Code idR. nicht auf die Geschwindigkeit des Compilers an, daher kann man evtl. ausführlichere Optimierungen durchführen. C++ und co. gibt es außerdem auch schon sehr lange, entsprechend gut sind die Compiler.

Ich würde sagen: C#/.NET ist tendenziell etwas langsamer. Das liegt aber nicht nur am JIT-Compiler. Beispielsweise werden in C# Array-Zugriffe überprüft. Greift man außerhalb des Arrays zu, kriegt man eine Exception und schreibt nicht einfach über den Rand. Solche Features kosten natürlich etwas, sind es aber imho wert.

Es ist auch nicht so, dass C++ generell schneller wäre. Es gibt sicher auch Situationen in denen C# effizienteren Code erzeugt. Meiner Meinung nach ist der Unterschied nur in Sonderfällen relevant. C#/.NET ist absolut kein lahmes Pferd.

[Exxtreme]

Wenn ich es richtig verstanden habe, werden alle Sprachen (C#, F#, ...) innerhalb der .NET Infrastruktur nicht nativ sondern in die Common Intermediate Language übersetzt. Die CIL wird dann nicht direkt in Maschinencode ausgeführt sondern interpretiert. Leidet hierbei die Performnace stark draunter oder ist dies in der Praxis nicht spürbar.
Die Startzeit der Programme verzögert sich spürbar. Ein reiner Interpreter ist das .NET-Framework jedoch nicht sondern ein JIT-Compiler. Sprich, es wird nur das übersetzt was gerade benötigt wird.

Und leider ist mir kein .NET-Programm bekannt, welches sich flüssig bedienen lässt. Ich nutze z.B. auf der Arbeit SQL Server Management Studio und da merkt man schon, dass das Tool nicht nativ läuft. Soll aber kein Affront gegen .NET sein, vielleicht optimiert MS ja noch ein wenig. Bei Java geht es auch, dass sich Programme flüssig bedienen lassen.

[PatkIllA]

Den JIT-Teil kann man durch Erzeugen von Nativen Codes umgehen. Das muss aber nicht unbedingt schneller sein.

[Aquaschaf]

Die Startzeit der Programme verzögert sich spürbar. Ein reiner Interpreter ist das .NET-Framework jedoch nicht sondern ein JIT-Compiler. Sprich, es wird nur das übersetzt was gerade benötigt wird.

Ein JIT-Compiler ist ja was anderes als ein Interpreter. Der .NET-Standard verbietet es sogar explizit die CIL mit einem Interpreter auszuführen :)

[Gnafoo]

Das sich .NET-Anwendungen weniger flüssig anfühlen finde ich eigentlich nicht. Davon abgesehen wäre das denke ich sowieso eher dem Window-Toolkit (also in der Regel Windows.Form oder WPF) als der Sprache an sich zu verschulden. Ich könnte mir auch vorstellen, dass die Geschwindigkeit von Windows.Forms und WPF ein wenig vom Betriebssystem abhängt. Kann sein dass es ab Vista besser aussieht damit.

Negativ fällt mir da eher noch Java auf, weil viele Java-GUIs unter Windows einfach nicht nativ aussehen oder sich fremd anfühlen. Soll natürlich nicht heißen, dass das mit Java nicht ginge, aber .NET fügt sich da von Haus aus imho besser ein. Das Problem hätte man hier wohl eher bei linux/mono.

[Demirug]

Solange du den Code nicht auf einer Playstation etc. ausfuehren musst, wirst du davon nicht viel mitbekommen.

Für die Playstation nutzt man genauso wie für das iPhone natürlich einen PreJit.

[Exxtreme]

Das sich .NET-Anwendungen weniger flüssig anfühlen finde ich eigentlich nicht. Davon abgesehen wäre das denke ich sowieso eher dem Window-Toolkit (also in der Regel Windows.Form oder WPF) als der Sprache an sich zu verschulden. Ich könnte mir auch vorstellen, dass die Geschwindigkeit von Windows.Forms und WPF ein wenig vom Betriebssystem abhängt. Kann sein dass es ab Vista besser aussieht damit.

Negativ fällt mir da eher noch Java auf, weil viele Java-GUIs unter Windows einfach nicht nativ aussehen oder sich fremd anfühlen. Soll natürlich nicht heißen, dass das mit Java nicht ginge, aber .NET fügt sich da von Haus aus imho besser ein. Das Problem hätte man hier wohl eher bei linux/mono.
Naja, am Toolkit selbst liegt es eigentlich nicht. Es ist so: du machst eine Aktion, die ein neues Fenster öffnet. Dann erscheint ein Fenster, das ist aber erstmal für 5 - 10 Sekunden weiss, und danach ist schlagartig der Inhalt da. Ist halt total nervig.

Gut, mein Rechner auf der Arbeit ist jetzt nicht der Jüngste aber das IBM Data Studio, welches auf Java basiert führt er flüssig aus.

[Gnafoo]

Hm ja. Bei 5–10 Sekunden würde ich eher tippen, dass die Anwendung im GUI-Thread irgendwelche Dinge tut, die man vermutlich besser in einen Hintergrundthread hätte auslagern sollen (oder ganz hätte vermeiden können?). Ich denke, dass das eher an der Programmierung der Anwendung selbst liegt und nicht an .NET.

[Coda]

Ich würde sagen: C#/.NET ist tendenziell etwas langsamer. Das liegt aber nicht nur am JIT-Compiler. Beispielsweise werden in C# Array-Zugriffe überprüft.
Das kann oft wegoptimiert werden.

[Exxtreme]

Hm ja. Bei 5–10 Sekunden würde ich eher tippen, dass die Anwendung im GUI-Thread irgendwelche Dinge tut, die man vermutlich besser in einen Hintergrundthread hätte auslagern sollen (oder ganz hätte vermeiden können?). Ich denke, dass das eher an der Programmierung der Anwendung selbst liegt und nicht an .NET.
Das sind einfache Aufrufe von z.B. Benutzern oder Serverrollen etc. Da glaube ich nicht, dass da was im Frontend läuft. Der alte native Enterprise Manager ist da wesentlich schneller.

[Gast]

Und leider ist mir kein .NET-Programm bekannt, welches sich flüssig bedienen lässt. Ich nutze z.B. auf der Arbeit SQL Server Management Studio und da merkt man schon, dass das Tool nicht nativ läuft. Soll aber kein Affront gegen .NET sein, vielleicht optimiert MS ja noch ein wenig. Bei Java geht es auch, dass sich Programme flüssig bedienen lassen.

Klingt sehr komisch. Meiner Erfahrung nach laufen .NET Programme spürbar reaktionsschneller von der GUI als Java Programme. Und das SSMS 2008 läuft bei mir auch absolut fix. Vielleicht liegt da eher ein anderes Problem vor (Netzwerk), dass die Kommunikation mit dem Server langsam ist.

[Gast]

das ist aber erstmal für 5 - 10 Sekunden weiss, und danach ist schlagartig der Inhalt da. Ist halt total nervig.


Das klingt eher danach, das der GUI Thread blockt, weil auf Daten gewartet werden muss bevor der GUI Thread zeichnen kann. Wie schon gesagt, klingt eher als ob die Kommunikation lahmt. Das ist jedenfalls kein Standardverhalten, das man mit .NET assoziieren könnte.

[del_4901]

Für die Playstation nutzt man genauso wie für das iPhone natürlich einen PreJit.
Der muss es ersteinmal schaffen SPU freundlichen Code zu generieren. Ohne Custom lib wird man da nicht wirklich viel raushohlen koennen. Und dann waehr man lieber gleich bei C++ geblieben. Allein auch der geringe Hauptspeicher ist sehr unfreundlich fuer eine moderne Sprache.

[Ectoplasma]

Dafür gibt es extern "C" in C++. Auch kein Grund.

Ist mir schon klar. Ich würde auch nie C verwenden, nur ab und zu gibt es halt Dinge die einen in C++ dazu zwingen, die C Aufrufkonvention zu verwenden. An dieser Stelle hätte man C++ schon längst standardisieren müssen. Mir ist klar, dass hier eine ganze Menge dranhängt. Das Objektmodell an sich, RTTI, Exception Handling etc.

[Gast]

Hier mal ein Artikel, der sich mit C++ bei Kernelmode Treibern für Windows beschäftigt:

http://msdn.microsoft.com/en-us/windows/hardware/gg487420