C++ auf Windows
 

Hallo!

Eigentlich verachte ich Windows... Aber man darf den Mainstream ja nicht ausschließen.

Momentan beschäftige ich mich mit C++ auf Unix und Mac OS X (durch fundierte Kenntnise in C und Obj-C war das nicht so viel Arbeit wie gedacht) aber ich will natürlich auch meine Anwendung auch für Windows bereit stellen. Meine Frage ist jetzt, wie ich möglichst viel schon vorher im Sourcecode portierbar machen kann. Eigentlich benutze ich fast nie OS-abhängige Funktionen. Aber wie komm ich an eine GUI? Hab kurz nach dem Release von .Net 4.0 mal in C# kleine Spielereien gemacht. Wie ist das bei C++? Wird der Code auch in ByteCode überstzt damit er in der ".Net VM" läuft? C# ist ja mehr wie Java und im worst case ist C++ nur eine weitere Methode um die .Net Libraries anzusprechen. Gibt es die GCC ordentlich portiert unter Windows? Habe viele Horrorgeschichten dazu gehört. Was sind denn die Alternativen zu der Gnu Compiler Compilation bzw. g++? Ist QT vielleicht die beste Möglichkeit für eine GUI? Gibt es vielleicht bessere Libraries für eine GUI? Es sollte auf jeden Fall nativ aussehen. Keiner mag Anwendungen im WIN2k style unter Windows Seven.

MfG Pennywise1911

Für .NET gibt es Managed C++, das wie C#, F# und VB in CIL kompiliert wird.

WPF ist das Stichwort. Weder Qt, noch Tk noch sonst irgendwelche GUI-Portierungen für Windows kommen an die Mächtigkeit von WPF ran. Allerdings gibt es die WPF erst ab .NET Framework 3.5, damit scheiden alle Betriebssysteme < Win Vista/Server 2003 aus.

Wenn er aber plattformunabhängige GUIs gestallten will, dann ist QT da um einiges besser geeignet :)
wxWidgets wäre da aber auch noch eine Möglichkeit.

Wenn du .Net machen willst, dann versuchs mal mit C# und GTK#. Damit müsstest du plattformunabhängig programmieren können.

Persönlich mag ich C++ mit QT am liebsten, gibt es natürlich für Linux&Win. Für Windows verwende ich dann VC++6.0.

Am schnellsten ist eine Maske aber mit C#.NET zusammengestopselt, egal welche Version.

Derzeit arbeite ich aber mit C mit Motif unter Windows.
Da siehst du den Unterschied ^^

Da .Net stinkt und ich WPF schon damals nicht mochte, werde ich wohl QT nehmen. Dann muss ich für Linux nicht so viel ändern. Auf Mac OS X nehm ich natürlich Cocoa.

Aber wie ist das mit dem Compiler? Kann man g++ unter Windows installieren? Hab vor Jahren mal mit Cygwin und g++ gearbeitet. Wurde damals in einem Video 2 Brain so gemacht. Wo sind unter Windows eigentlich die include und library paths? Unter Mac OS X und Linux sind die ja unter /usr/local/includes bzw. /usr/local/lib aber sowas hab ich unter Windows noch nie gesehen.

Gegen Tipps zu alternativen Compilern hab ich auch nichts.

Garnicht, es sei denn du verlässt dich komplett auf eine Unmenge aus C++ - OSS - Librarys ... was dir im Übrigen ständig Probleme bereiten wird, auch wenn es recht gut geht.

WINAPI oder OSS-Librarys wie QT. Damit wirste aber nichts anspruchsvolles hinkriegen, schon bei 3D hört es komplett auf .... zumindest in der Theorie, es gibt eben reverse-engineered MS-Libs

C++ kennt keinen Bytecode, das ist eine native Sprache ... und zugleich eine der Ältesten.

.... WAS?
Das ergibt nicht den geringsten Sinn

"Ordentlich" ... nein. Aber es gibt ihn.

Zurecht.

Zum Beispiel ein MS-Compiler. Der funktioniert wenigstens ausnahmslos und kann ebenso wie der gcc klug optimieren

Nein, die beste ist entweder die WINAPI oder sogar MFC. QT ist eine Lösung für die, die religiöse Glaubenskriege gegen einen Konzern führen. Im Übrigen hasse auch ich Microsoft.

Mit Java Swing kriegt man ein paar hübsche Dinge hin ... aber wenn man volle Grafikbeschleunigung und native Grafikoperationen will muss man Microsoft-Libs nehmen.

MFC ist aber meiner Ansicht nach hässlich. Dann würde ich mir lieber die VCL angucken ;)
Für produktive GUI-Entwicklung halte ich die VCL für die beste Lösung.

Auch das ergibt keinen Sinn und ist Schwachsinn, MFC ist eine Library, und zwar eine Objektorientierte ergo kann so etwas per Definition nicht "hässlich" sein, OOP wurde entworfen um Code lesbarer und wartbarer zu machen.

Ich sehe gerade dass dies seltsame VCL scheinbar nur WINAPI-Methoden kapselt ... hat also kaum einen Mehrzweck

In Sachen Code sind die MFC trotz OOP hässlich, da sie kein modernes OOP verwenden, sondern auch hässliche Dinge wie Makros und Co. Die VCL kapselt nicht nur stupide WinAPI Methoden, sondern stellt eine komplexe Bibliothek zur Entwicklung grafischer Anwendungen bereit. (Delphi, C++ Builder)
Die MFC bieten bei weitem nicht den Komfort, den die VLC bietet.

PS: OOP <> schön, wenn man es nicht richtig macht. Die besten Absichten helfen nichts, wenn man es nicht richtig umsetzt. (Ich will nicht sagen, dass ich es besser kann, sondern dass die Leute von Borland (heute Embarcadero) damals bessere Arbeit geleistet haben)

Mit der Meinung bist du auf dem Planeten recht einsam ... aber jedem das Seine, ich würde dir nur raten die Meinung nicht überall preis zu geben

Sehr viele Makros rufen Objekte auf ... aber es gibt natürlich frei nach C-Manier immernoch solche Ohne, das stimmt wohl.

Ich denke, dass ich das öffentlich zugeben kann. Ich denke halt nur, dass die Borlandmitarbeiter beim Kapseln der Funktionen mehr an den Programmierer gedacht haben. Die MFC hat ein stringentes System, was aber auch die VCL hat. Im Gegensatz zu den MFC lassen sich die VCL-Komponenten leichter manipulieren. Die Produktion einer ansehlichen GUI geht meiner Meinung nach einfach leichter von der Hand und ist auch für Anfänger deutlicher besser zu erlernen.

EDIT:

Nicht nur meine Meinung:

[Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]

Wer ernsthaft behauptet dass CObject über Makros realisiert und "hineingemogelt wurde" der hat zuallererst nur wenig / garkeine fachliche Kompetenz und ist zudem nicht in der Lage, objektiv zu urteilen oder gar die Wahrheit zu sprechen.

Der Artikel stammt nicht von mir. ;) Aber ich denke, dass der Autor die Anatomie von CObject meint ;) Ich selbst habe da keine Überblick. Ich kann nur für mich sagen, dass der Quelltext durch die Makros ziemlich unsauber wirkt. Außerdem ist die Abstraktionsebene der MFC viel niedriger als die der VCL, was den Einstieg und die Benutzung schwieriger macht.

BTW: Man spricht auch nicht die Wahrheit, wenn man alles, was den Anspruch auf OOP erhebt, als sauber darstellt. Die Implementierung entspricht einfach nicht mehr dem Zeitgeist.
Was den Designaspekt (nicht des Codes) anbelangt, steht man mit den MFC wirklich sehr schlecht dar. Für die VCL gibt es eine so große Bandbreite an Produkten und freien Ergänzungen, die das "aufpeppen" der Formulare in Sekundenschnelle ermöglichen. - Unter Verwendung der MFC ist das alles viel mehr Arbeit.

Ich glaub ich bestraf die Windowsuser zurecht für ihre OS-Wahl und warte bis Apple Cocoa portiert hat. =P

Ich glaub ich guck mal wieder in Visual Studio rein und entscheide dann, ob ich das wirklich will oder ob ich Winsows vernachlässige.

Danke für eure Antworten.

Nein. Das ist erfunden. Man trifft immer wieder Leute die das oder etwas ähnliches über MFC behaupten und wenn man nachfragt stellt man fest dass diese Info "mal gehört" wurde. Vor ca. 15 Jahren war MFC im Entwicklungsstadium und hatte dementsprechend kaum Funktionen - kompetenztechnisch fragwürdige Gestalten haben die Libs dann direkt beurteilt und nie wieder nachgeforscht, geben falsche Infos heutzutage sogar weiter.
Nenn mir eine Aufgabe die angeblich "nur umständlich" mit MFC zu lösen wäre und ich nenne dir eine einfache Lösung, tatsächlich ist MFC nämlich kinderleicht zu Verstehen und mitunter sogar recht mächtig, auch wenn es teilweise defekte Altlasten gibt.

Wie du vielleicht gemerkt hast, programmiere ich mit Delphi und bevorzuge dementsprechend, wenn ich C++ nutze, die VCL. Ich denke, dass sich viele Aufgaben, die man in VCL über die IDE lösen kann (ich denke, dass es bei diesem Thema in Ordnung ist das Framework und die IDE in einem Atemzug zu nennen, da meines Wissens weder die MFC noch die VCL ohne die entsprechende IDE des Herstellers ausgeliefert wird.) im Visual Studio nicht über den Formdesigner zu bewältigen sind, sondern im Code implementiert werden müssen.
Ich lasse mich eines besseren belehren, aber schon das Ändern des Fonts eines Labels gestalltet sich mit den MFC schwieriger:

VCL (CODE):

Ich gebe zu, dass das nicht gerade ANSI-C++ ist. Die Properties sind von Borland implementiert :D

MFC finde ich da etwas verwirrender, zumal man immer mit den Pointern rumspielen muss:

Also hatte ich mit meiner Vermutung recht.

Ich habe keine Ahnung warum da oben mit Pointern rumpfuschst aber ... Text zu ändern ist das leichteste überhaupt :
Übrigens sind Controls immer direkt als Membervariable in der Klasse vorliegend, da wird definitionsgemäß nichts ge-pointer-d.

Weil du nicht weisst wie es funktioniert, weil du dich noch nie damit beschäftigt hast. Ich zB. finde C# verwirrend - ich hab aber auch keinen Plan davon.

Tjo da hast du ein falsches "Wissen". MFC ist seit Windows 2000 in jedem MS-Betriebssystem vollautomatisch mit drin - Visual Studio ergänzt die vorhandenen Libs nur ein wenig (zB- über Debug-Symbole und einige recht praktische Makros)

Das ist im Übrigen stark fehleranfälliger Code, man kann von Glück reden wenn es überhaupt funktioniert - eine Control unter Windows hat erstmal keine Ahnung davon welche Variablen irgendwo für irgendwas stehen sollen. Zusätzlich dazu ist das Verbiegen von Zeigern generell eine dumme Idee, bei solchem Code kann man davon ausgehen dass das Produkt in Rekordgeschwindigkeit abraucht .... sofern es überhaupt startet.

Mag ja sein, dass ich nicht viel Ahnung von MFC habe, du aber auch nicht von der VCL - diese ist in diesem Fall nicht fehleranfällig, da der Borland-Compiler eine nicht ANSI-C++ konforme Erweiterung für Properties hat, wie ich oben schon angemerkt habe. Ich rufe mit dem '='-Operator quasi eine Setter-Methode auf ;)

;)

Persönliche finde ich MFC einfach unattraktiv ;)
Achja - meines Wissens werden die MFC Header nur mit den kostenpflichtigen Versionen des Visual Studios angeboten und sind damit wohl an die IDE gebunden. :)

Ich habe mit ehrlich gesagt nicht viel mit MFC auseinander gesetzt, habe es aber schonmal genutzt und dabei diese Artikel interpretiert:

[Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]
[Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]

Auch wenn du es zweimal sagst wird es nicht wahr.

OK, daher also der Unsinn ... dachte mir auch dass das aus solchen Portalen kommt - gerade diesen beiden sind berühmt für sowas. Vermutlich kriegt man dort auch "abgeraten" von MFC weil es "unsicher ist" und "schlecht" ist ... ergo in irgendeiner religiösen Welt ein Feindbild darstellt - weil es kein OSS ist.

Doie VCL-Sache schau ich mir irgendwann ma an ... hat mich iwie neugierig gemacht.

Zitat Wikipedia:

Ich hätte sonst keine Ahnung, wo ich die MFC Header sonst noch herbekommen sollte und glaube das einfach mal. Ich lasse mich aber gerne eines besseren belehren. Wie komme ich denn an die MFC ohne Visual Studio Standart, Prof, Ultimate und wie sie alle heißen ;)

Finde ich gut, dass ich dich neugierig machen konnte. Wenn ich eine GUI mit C++ erstellen muss, dann verwende ich die VCL von Borland/Embarcadero. Bin halt eigentlich "semi-professioneller Freizeit-Delphi-Programmierer" und dementsprechend bietet sich das für mich an.

EDIT

Ich habe mich mal auf meine vier Buchstaben gesetzt und das auf der Digitalmars Seite gefunden:

Comes with MFC 4.2 headers, source and libraries for Win32.
Hattest also Recht und ich habe wieder dazu gelernt.

Was sollen die Header mit den Libs zu tun haben? Garnichts.

Windows-Ordner öffnen.

Ich werde mal den Unsinn im Wikipedia-Artikel ändern .... nur um dann vermutlich erneut zuzusehen wie die Wahrheit vertuscht / gelöscht wird.

Wir reden hier doch von Bibliotheken und ich habe gedacht, da nicht jeder Compiler mit den MFC klar kommt, dass die Header nur beim Visual Studio dabei sind. Verstehst du? Ich rede vom Kompilieren und nicht vom Ausführen. Die Header der VCL sind z.B. nur bei den entsprechenden Embarcaderoprodukten dabei.
Ich habe irgendwie das Gefühl, dass wir aneinander vorbei reden ...

PS: Wow, ich habe gerade nachgeguckt und du hast ja wirklich schon eine Änderung bei Wikipedia eingereicht. Extrem schnell - Respekt!