Praxisnahe IDE

[Janjan]

Der Compiler von Microsoft produziert für Windows einfach deutlich schnelleren Code als die Alternative von GNU.

[Embar]

Falls das auf meine Frage bezogen sein soll:
Was hat das mit

Unter Windows sollten die Micrsoftprodukte die schnellsten sein.

zu tun? Das sind doch schon zwei völlig unterschiedliche Aussagen. Mal abgesehen davon, dass es doch noch ein paar mehr Compiler gibt...

Links zu unabhängigen Studien, die das untersuchen, würden mich übrigens interessieren. Hast du da vielleicht ein paar Links zu? Eventuell auch noch mit anderen Kandidaten, wie dem C++ Builder, Sun C++ oder Intel C++.

[asc]

DarkBug schrieb:

1. Wird C++ überhaupt noch in der Praxis eingesetzt, also das auch Firmen mit C++ programmieren und diese Programme verkaufen?

Ja, und nicht gerade wenige. Auch wenn es seit der Zeit, in der angefangen habe, etwas zugunsten überwiegend von Java und etwas C# verschoben hat (Wobei ich inzwischen einige Firmen kenne die von Java wieder zu C++ gewechselt haben).

DarkBug schrieb:

2. Wenn C++ noch aktuell ist, was für IDEs werden in Firmen verwendet.

Ich kann es nur aus der Windowsecke eindeutig sagen, dort ist es noch immer eindeutig Microsoft Visual Studio (Auch wenn ich beruflich aktuell mit dem C++ Builder arbeite).

DarkBug schrieb:

Ich würde nämlich gerne eine IDE haben, die auch die neuen GUI-Objekte von Windows 7 mit an Board hat.

Der C++ Builder hat mit C++ erstmal recht wenig gemein, wenn du die VCL-Komponenten meinst. Die VCL ist Delphi/C++ Builder spezifisch, und es gibt keine C++ "UI", sondern sehr viele verschiedene. Wer mit dem C++ Builder angefangen hat (sei es wegen schlechten C++ Unterricht...) und sich an die VCL gewöhnt hat, der wird sich erstmal sehr schwer tun (Als ich in meiner aktuellen Firma begonnen habe war kaum "echter" C++ Code im Projekt enthalten, viele Konstrukte wie Containerklassen händisch programmiert... Templates, die C++ Standardbibliothek usw. kam eigentlich erst mit mir in das Projekt).

[f.-th.]

Das mit dem "schnellsten" war ein wenig doppeldeutig

Gemeint war, wenn die bei MS ein neues OS auf den Markt werfen, sollte die Compilerschmiede von denen zuerst über die "Neuigkeiten" orientiert sein.

MfG f.-th.

[DarkBug]

Vielen Dank für eure Antworten. Ich glaube ich schau mir mal das Microsoft Visual Studio Express an.

Mit freundlichen Grüßen,
DarkBug

[audacia]

f.-th. schrieb:

Gemeint war, wenn die bei MS ein neues OS auf den Markt werfen, sollte die Compilerschmiede von denen zuerst über die "Neuigkeiten" orientiert sein.

Denkste. Tatsächlich wurde die VCL idR schneller an die Windows-Neuerungen angepaßt als WinForms oder MFC (-> Aero-Glass-Support in C++Builder 2007, Ribbon-Steuerelemente in C++Builder 2009, Touch-Support in C++Builder 2010 etc.).

DarkBug schrieb:

Gibt es solch eine IDE für C++, welche in Firmen benutzt wird um kommerzielle Programme zu programmieren und die neuesten GUI-Objekte von Windows 7 mit an Board hat?

Was sind "die neuesten GUI-Objekte von Windows 7"? Wenn du Ribbon-Steuerelemente suchst, die sind in VCL und MFC dabei; für WinForms müßtest du vermutlich eine Drittkomponente erwerben.

Ansonsten werden die aktuellen Versionen von C++Builder - nach C++Builder 6 kamen C++Builder 2006 (Borland), C++Builder 2007 (CodeGear), C++Builder 2009 und C++Builder 2010 (Embarcadero) - durchaus kommerziell verwendet. Wenn es um ein ansprechendes, zeitgemäßes Windows-UI geht, ist das vermutlich auch die beste Option.

[__cpp]

Wer den Emacs nicht kennt hat das Coden verpennt

Mal im ernst C++ Snippets und VisualStudio ist schon sehr peinlich oder? *duck

[DarkBug]

@audacia: Mit "die neuesten GUI-Objekte von Windows 7" meinte ich Sachen wie Aero-Glass-Support, Ribbon-Steuerelemente und Touch-Support ja. Welche IDE benutzt du denn?

@__cpp: Du rätst mir von Visual Studio ab. Warum?

[volkard]

DarkBug schrieb:

@__cpp: Du rätst mir von Visual Studio ab. Warum?

Das war nur ein Troll.

[zwutz]

DarkBug schrieb:

Mit "die neuesten GUI-Objekte von Windows 7" meinte ich Sachen wie Aero-Glass-Support, Ribbon-Steuerelemente und Touch-Support ja.

Ribbons sind nur eine neue Art von Steuerelementen. Der einzige Grund, warum man sie in anderen Frameworks eher selten findet dürfte die Lizenzpolitik von MS sein.

Die anderen beiden Punkte setzen lediglich Windows voraus, kein spezifisches Framework

[audacia]

DarkBug schrieb:

@audacia: Mit "die neuesten GUI-Objekte von Windows 7" meinte ich Sachen wie Aero-Glass-Support, Ribbon-Steuerelemente und Touch-Support ja. Welche IDE benutzt du denn?

C++Builder 2010.

zwutz schrieb:

Die anderen beiden Punkte setzen lediglich Windows voraus, kein spezifisches Framework

Das Framework kann dir aber den Umgang damit entschieden vereinfachen.

[zwutz]

audacia schrieb:

Das Framework kann dir aber den Umgang damit entschieden vereinfachen.

das ist klar, aber nicht nur das MS-Framework bietet die Unterstützung. Wobei Glass eh nur ein Dreizeiler ist

[audacia]

zwutz schrieb:

das ist klar, aber nicht nur das MS-Framework bietet die Unterstützung.

Ich spreche auch von der VCL.

[DarkBug]

Ist jetzt wirklich von Visual Studio abzuraten im Gegensatz zum C++ Builder 2010? Ich mein warum sollte __cpp das sonst schreiben, oder kann ich diesen Beitrag als Spam betrachten?

[Artchi]

Nicht ernst nehmen. Wenn er es ernst meinen würde, würde er den Mumm haben sich wenigstens zu registrieren.

[asc]

DarkBug schrieb:

Ist jetzt wirklich von Visual Studio abzuraten im Gegensatz zum C++ Builder 2010? Ich mein warum sollte __cpp das sonst schreiben, oder kann ich diesen Beitrag als Spam betrachten?

Das ist reiner Spam, wie es sich leider in einigen Threads befindet, bei der es um "Glaubensfragen" geht.

Für reines C++, erst einmal losgelöst vom Framework ist imho Visual Studio dem C++ Builder vorzuziehen. Wenn man Oberflächen schnell zusammenklicken will, ist der C++ Builder die bessere Wahl. Grundsätzlich bin ich aber vorsichtig bei der Aussage zur Zukunft (Viele Komponentenentwickler haben ihre VCL-Entwicklung eingestellt - sicherlich gibt es noch viel, aber bei weiten nicht mehr so viel wie ursprünglich).

[audacia]

asc schrieb:

Für reines C++, erst einmal losgelöst vom Framework ist imho Visual Studio dem C++ Builder vorzuziehen.

Ja. Wenn's nur um C++-Code geht, also ohne nennenswertes UI, dann dürfte der bessere Compiler von VC den Ausschlag geben.

asc schrieb:

Wenn man Oberflächen schnell zusammenklicken will, ist der C++ Builder die bessere Wahl.

"Schnell zusammenklicken"? Sicher, das ist auch ein nettes Feature. Aber die VCL ist viel mehr als "schnell zusammenklicken".

Ich würde sagen, wenn du Anwendungen mit anspruchsvollem UI für Windows entwickeln willst, ist die VCL mit Abstand die beste Lösung. Am besten mit Delphi, aber wenn es C++ sein soll, dann ist C++Builder das Mittel der Wahl.

asc schrieb:

(Viele Komponentenentwickler haben ihre VCL-Entwicklung eingestellt - sicherlich gibt es noch viel, aber bei weiten nicht mehr so viel wie ursprünglich).

Ja, der große Trend weg von Delphi, C++Builder und VCL begann etwa 2002, als alle glaubten, .NET werde über kurze Sicht das neue Windows-API restlos ersetzen, und infolgedessen Borland nicht so recht weiterwußte, etwas verzweifelt Delphi nach .NET portierte und gleichzeitig versuchte, C++Builder durch den platformunabhängigen, jedoch für Borland selbst unvorteilhaft egalitären C++BuilderX zu ersetzen. In dieser Zeit stiegen nicht wenige Drittanbieter aus. (Man wird retrospektiv sagen können, daß das Borland-Management in durchaus nennenswertem Ausmaß für die Misere mitverantwortlich war. Glücklicherweise wurde das IDE-Business vor ein paar Jahren an Embarcadero verkauft, bevor Borland, nach dem der Aktienkurs asymptotisch gegen 0 zu gehen begann, schlußendlich von MicroFocus geschluckt wurde.)

Der Trend hat sich aber zwischenzeitlich mehr als relativiert. Ich bin nicht sicher, ob es dazu wirklich brauchbare Statistiken gibt - TIOBE wohl eher nicht -, aber die Präsenz von Delphi und C++Builder im Netz, etwa bei StackOverflow, nimmt wieder zu.

[Zeus]

Auf jeden Fall bin ich gespannt, was Embarcadero aus Delphi macht, soll ja in Richtung Funktionale Programmiersprache, Cross-Platform und 64-Bit Computing gehen

[asc]

audacia schrieb:

asc schrieb:

Für reines C++, erst einmal losgelöst vom Framework ist imho Visual Studio dem C++ Builder vorzuziehen.

Ja. Wenn's nur um C++-Code geht, also ohne nennenswertes UI, dann dürfte der bessere Compiler von VC den Ausschlag geben.

Oh, für den VC gibt es einige UI-Frameworks, und auch einige Plugins für entsprechende Designer (zum Beispiel, aber nicht ausschließlich QT).

audacia schrieb:

asc schrieb:

Wenn man Oberflächen schnell zusammenklicken will, ist der C++ Builder die bessere Wahl.

"Schnell zusammenklicken"? Sicher, das ist auch ein nettes Feature. Aber die VCL ist viel mehr als "schnell zusammenklicken".

Ja, aber sie kann auch einiges was gänzlich der üblichen C++ Entwicklung wiederspricht [Und Schwierigkeiten beim Umgang mit STL-Algorithmen etc. verursachen kann; Beispiel: __fastcall Konvention, keine saubere const Unterstützung bei ein paar VCL-Datentypen...] - ist halt die Frage, in wie weit man sich an die VCL binden möchte.

audacia schrieb:

Ich würde sagen, wenn du Anwendungen mit anspruchsvollem UI für Windows entwickeln willst, ist die VCL mit Abstand die beste Lösung.

Ich behaupte das einige andere UI-Frameworks mit der VCL gleichziehen (Seien es die beiden UI-Frameworks von .Net, sei es QT...), und ob ich mich nun an die Compilerspezifischen Erweiterungen von dem C++ Builder, oder an .Net oder dem Makrokrimskrams von QT binde, ist glaube ich durchaus vergleichbar.

audacia schrieb:

asc schrieb:

(Viele Komponentenentwickler haben ihre VCL-Entwicklung eingestellt - sicherlich gibt es noch viel, aber bei weiten nicht mehr so viel wie ursprünglich).

Ja, der große Trend weg von Delphi, C++Builder und VCL begann etwa 2002, als alle glaubten, .NET werde über kurze Sicht das neue Windows-API restlos ersetzen,...

Und auch derzeit gibt es noch immer den Trend von der VCL weg (Es sind auch in den letzten paar Jahren noch weitere Komponentenhersteller abgesprungen). Das hat natürlich auch die Überlebenswahrscheinlichkeiten der Restlichen etwas erhöht (Wo weniger Konkurrenz herrscht, ist die Suche nach alternativen Herstellern schwierig). Nenn mir bitte beispielsweise einen gescheiten HTML-Viewer, den man nicht mittels COM ansteuern muss, und der aktuell noch gut gepflegt wird.

Zeus schrieb:

Auf jeden Fall bin ich gespannt, was Embarcadero aus Delphi macht...

Mir wäre es mal lieber, zu wissen wie die Zukunft vom C++ Builder aussieht. Und der C++ Builder wird und wurde lange Zeit nur minimal gepflegt (und im Gegensatz zum VS gibt es auch so gut wie keine Addins, die mangelnde Fähigkeiten der IDE ausbügeln).

Die Zeit, in der ich von der VCL überzeugt war, liegen jedenfalls schon etliche Jahre zurück. Und ich stoße immer wieder an Stellen, die mir negativ bei der VCL in Zusammenhang mit C++ auffallen.

[audacia]

asc schrieb:

Oh, für den VC gibt es einige UI-Frameworks, und auch einige Plugins für entsprechende Designer (zum Beispiel, aber nicht ausschließlich QT).

Qt ist ja ganz nett, wenn man plattformunabhängig bleiben will. Aber UIs für Windows würde ich nicht mit Qt erstellen. Qt versucht zwar, den Windows-Look zu imitieren, verwendet aber keine nativen Windows-Controls, was im Vergleich zu "richtigen" Windows-Anwendungen (VCL, MFC, WTL, WinForms) durchaus auffällt; andauernd stimmen irgendwelche subtilen Details im Aussehen, Bedienung oder Funktionalität nicht. Aus demselben Grunde übrigens würde ich einen weiten Bogen um AWT oder Swing machen.

Abgesehen davon ist die Unterstützung für Windows-spezifische Eigenheiten in C++Builder einfach deutlich besser (bzw. überhaupt vorhanden); man denke nur an den umfangreichen ActiveX-Support, oder einfach an die Vista-spezifischen Neuerungen in den Common Controls.

Auch die Ribbon-Steuerelemente sind ein passendes Beispiel: für C++Builder sind sie gleich mitgeliefert, mir fallen spontan zwie weitere 3rd-party-Komponenten dazu ein, und es gibt, glaube ich, noch ein paar mehr. Aber für Qt? Niente.

Und Qt ist in dieser Hinsicht noch die beste Option. wxWidgets, GTK und all die anderen Toolkits können das durchaus anerkennenswerte Niveau von Qt nicht halten.

asc schrieb:

Ich behaupte das einige andere UI-Frameworks mit der VCL gleichziehen (Seien es die beiden UI-Frameworks von .Net, sei es QT...)

Die VCL ist vielleicht etwas umfangreicher und mehr "up-to-date", aber sonst ist WinForms sicherlich sehr konkurrenzfähig. Allerdings bevorzuge ich aus verschiedenen Gründen den ressourcenbasierten VCL-Designer (die DFM-Dateien) gegenüber dem WinForms-Designer, der Quelltext generiert. Etwa vereinfachen UI-Ressourcen die Internationalisierung. Und bei der Arbeit mit Versionskontrollsystemen ist

object LvwDataItems: TListView
  Left = 8
  Top = 143
  Width = 353
  Height = 150
  Columns = <
    item
      Caption = 'First column'
      Width = 200
    end
    item
      Caption = 'Second column'
      Width = 100
    end>
  TabOrder = 2
  ViewStyle = vsReport
end

einfach übersichtlicher als

// 
            // lvwDataItems
            // 
            this.lvwDataItems.Columns.AddRange(new System.Windows.Forms.ColumnHeader[] {
            this.firstColumn,
            this.secondColumn});
            this.lvwDataItems.Location = new System.Drawing.Point(8, 143);
            this.lvwDataItems.Name = "lvwDataItems";
            this.lvwDataItems.Size = new System.Drawing.Size(353, 150);
            this.lvwDataItems.TabIndex = 0;
            this.lvwDataItems.UseCompatibleStateImageBehavior = false;
            this.lvwDataItems.View = System.Windows.Forms.View.Details;
            // 
            // firstColumn
            // 
            this.firstColumn.Text = "First column";
            this.firstColumn.Width = 200;
            // 
            // secondColumn
            // 
            this.secondColumn.Text = "Second column";
            this.secondColumn.Width = 100;

Es gibt natürlich durchaus auch Aspekte, die bei WinForms besser gelöst sind; etwa die Datenbindung. Aber alles Hin und Her wird zu unwichtigen Details, wenn auf das eigentliche Problem von WinForms stößt: für alles außer C# und VB.NET ist die IDE-Unterstützung einfach miserabel. Ich denke, Jochen Kalmbach hat das hier gut ausgeführt - von C++/CLI, speziell in Verbindung mit WinForms, sollte man tunlichst die Finger lassen.

Zurzeit arbeite ich an einem C++/CLI-Projekt, das C++-Code für ein mit C#/WinForms erstelltes UI zugänglich machen soll, und ich find's nicht lustig. VS 2010 unterstützt für C++/CLI nicht einmal IntelliSense; die Verbindung von Managed und Unmanaged Code ist (obzwar viel besser als nackte P/Invoke-Aufrufe) insgesamt recht unschön. (__clrcall ist kein Stück besser als __fastcall, und das Herumhantieren mit Handles macht die Arbeit mit STL und dergleichen auch nicht einfacher. Außerdem füge mal einer TForm-Klasse einen Member vom Typ std::vector<> hinzu - und dann versuche das mal in C++/CLI )

Zwar steht diese Deutung diametral zur chronologischen Abfolge der Ereignisse, aber ich bei der Arbeit mit C++/CLI drängt sich mir sehr oft der Gedanke auf "C++Builder ist, was C++/CLI hätte sein sollen".

Mit WPF ist das ohnehin etwas anders. WPF ist für neuartige Anwendungsfälle sicherlich hochattraktiv, aber es ist selbst in der .NET-Welt kein Ersatz für WinForms. Und die IDE-Unterstützung für C++ mit WPF ist nicht einmal miserabel, sie ist überhaupt nicht existent.

asc schrieb:

Nenn mir bitte beispielsweise einen gescheiten HTML-Viewer, den man nicht mittels COM ansteuern muss, und der aktuell noch gut gepflegt wird.

Ich kenne weder für die VCL noch für WinForms einen, der nicht auf dem Internet Explorer basieren würde. (Das Gecko-basierte Browser-Widget in Qt ist vielleicht eine interessante Alternative.) Und offen gesagt halte ich es für ziemlich sinnfrei, an dieser Stelle das Rad neu zu erfinden, anstatt ein Steuerelement einzubinden, das auf einem etablierten Browser basiert.

asc schrieb:

und im Gegensatz zum VS gibt es auch so gut wie keine Addins, die mangelnde Fähigkeiten der IDE ausbügeln

Nein, da gibt es absolut gar keine, außer TwineCompile, GExperts, den CNWizards oder den DDevExtensions

Sicher, es gibt kein Visual Assist X oder CodeRush für C++Builder. Aber vielleicht tut sich da ja etwas?

asc schrieb:

Mir wäre es mal lieber, zu wissen wie die Zukunft vom C++ Builder aussieht.

Sie wird sehr eng verbunden sein mit der Zukunft von Delphi. Das nächste Release wird beispielsweise auch Mac-Anwendungen erstellen können.

asc schrieb:

Und der C++ Builder wird und wurde lange Zeit nur minimal gepflegt

Das ist, mit Verlaub, Blödsinn. C++Builder litt natürlich unter der C++BuilderX-Eskapade um 2003-2005. Aber die Ressourcen in der Entwicklung von Delphi und C++Builder sind seit 2007 wieder ziemlich gut ausbalanciert. Das C++-Compiler-Team dürfte sogar etwas besser besetzt sein als das Delphi-Compiler-Team.