MinGWs Zukunft?

blue-tec

Danke für die Informationen, also kann man in Visual Studio genauso debuggen wie mit Qt-Creator ohne weitere Nachteile. Sind denn aber Addins nicht nur der kostenpflichtigen Version vorbehalten? Ich mache das alles ja nur als Hobby und will das auch nicht ändern und da ist mir VisualStudio zu teurer zumal ich keinen Mehrwert zum Creator für mich sehe.

So nun sind ja doch viele der Meinung das MinGW nicht mehr lange weiterbesteht, also bleibt den Leute von plattformunabhängiger Entwicklung nix mehr weiter übrig als auf mehrere Compiler zu setzen. Es müsste also zu beobachten sein wie bald viele große Projekte sich von MinGW distanzieren...ich bin mal gespannt.

Gruß Blue-Tec

Zeus

blue-tec schrieb:

Danke für die Informationen, also kann man in Visual Studio genauso debuggen wie mit Qt-Creator ohne weitere Nachteile. Sind denn aber Addins nicht nur der kostenpflichtigen Version vorbehalten? Ich mache das alles ja nur als Hobby und will das auch nicht ändern und da ist mir VisualStudio zu teurer zumal ich keinen Mehrwert zum Creator für mich sehe.

Addin dürften ab der Standard Version laufen. Bleib bei Creator.

blue-tec schrieb:

So nun sind ja doch viele der Meinung das MinGW nicht mehr lange weiterbesteht, also bleibt den Leute von plattformunabhängiger Entwicklung nix mehr weiter übrig als auf mehrere Compiler zu setzen. Es müsste also zu beobachten sein wie bald viele große Projekte sich von MinGW distanzieren...ich bin mal gespannt.

Gruß Blue-Tec

Unsinn, natürlich bleibt uns Mingw erhalten (mit alleine seinen Unangenehmlichkeiten).
Im Gegensatz zu Qt baut Artchi seine Lib so, dass er möglichst bestehende API verwendet, während Qt nur ein minimale API von System benutzt. Wenn der Primärcompiler von Windows Visual C++ und der von Linux GCC ist, wieso soll man Mingw supporten, wenndoch Mingw nicht mal die ganzen System-API ansteuern kann.

blue-tec

Na dann ist ja alles geklärt. MinGW bleibt, ist aber für viel und aktuelle WinAPI ungeeignet.

Gruß Blue-Tec

Artchi

blue-tec schrieb:

Pass mal auf mein kleiner Bastelfreund,

soweit ich weiß probiert du genau wie Qt auch etwas plattforumunabhängiges zu entwickeln. Qt hat unter Windows sehr viel mit der WinAPI zu tun und nutzt dazu unter anderem MinGW.

Du meinst also nicht im ernst das Qt unter Windows nicht viel WinAPI nutzt Auch wenn sie einiges selbst machen, so nutzen sie sehr wohl auch die WinAPI und deswegen ist der Vergleich durchaus legitim?

So und jetzt erkläre mir und den anderen mal warum Qt nix mit der WinAPI und MinGW zu tun haben soll?

Also, hier mal ein wenig Know-How von mir "Bastelfreund" für dich:

Qt hat das Konzept eine eigene Plattform zu sein, und somit praktisch seine eigene Runtime zu haben. Das haben viele Multiplattform-Toolkits, wie Qt, FTLT, GTK+ und mittlerweile wohl auch wxWidgets.

Zeus hat es erkannt und auch genannt, ich will es aber weiter ausführen. Mal ein ganz banales Beispiel, das übertrieben dargestellt ist:

Die API von z.B. Qt & Co. stellt das Zeichnen eines Pixels und eines gefüllten Rechtecks bereit:

void draw_pixel(int x, int y);
void fill_rect(rect r);

Was machen Qt & Co. in ihrer Implementierung? (es geht im Beispiel nur ums Prinzip!)

// Light wight
void draw_pixel(int x, int y)
{
#ifdef WIN32
     SetPixel( hdc, x, y, crColor); 
#endif
}

void fill_rect(rect r)
{
    // Rechteck Algorithmus nutzt draw_pixel-Funtion ohne #ifdef WIN32!
    // Im schlimmsten Fall muß draw_pixel millionenfach aufgerufen werden.
}

Hier wird der minimale Satz an Win32-API genutzt. Warum? Weil dadurch die Portierung auf andere Systeme weniger Aufwand bedeutet. Weil man weniger Code-Stellen ändern muß.

Nachteil? Ein Rechteck könnte mit der nativen Win32-Rechteck-Funktion schneller und/oder schöner gezeichnet werden.

Was mache ich, das ich die volle Win32-API nutzen will?

// Heavy wight
void draw_pixel(int x, int y)
{
#ifdef WIN32
     SetPixel( hdc, x, y, crColor); 
#endif
}

void fill_rect(rect r)
{
#ifdef WIN32
     FillRect(hdc, &r, brush);
#endif
}

Hier wird versucht so viel native Funktionen des Systems zu benutzen, um z.B. den Grafikchip das gefüllte Rechteck zeichnen zu lassen. Das heißt maximale mögliche Performance und evtl. ein anderes Aussehen, das eher der Plattform entspricht.

Nachteil? Ich muß für jedes System (Win32, X11 u.a.) einen Aufruf implementieren. Auf Systemen die keine Füllfunktion kennen, muß ich den Algorithmus trotzdem wie im ersten Beispiel implementieren! Denn die Funktion muß sollte trotzdem da sein. Also sehr viel Aufwand beim Portieren. Nativ ist aber immer vorzuziehen.

Hier ging es wohl gemerkt um ein dummes Rechteck. Es gibt aber so viele weitere Funktionen, die eine Library und System anbieten können. Und eine eigene Runtime hat den Vorteil, das die Library mit minimalen Aufwand überall kompiliert und man nur einen Basissatz-API anpassen muß.

Nachteil ist aber, das man nicht das Maximum aus einem System raus holen kann und sich die Funktionen für den Anwender fremd anfühlen können. Halt nicht nativ. Es ist eine Philosophie-Frage und ich verurteile Qt & Co. deshalb nicht. Aber es sind einfach Fakten, die ich hier nenne.

Sicherlich können solche Anwendungen und Libraries mit dem MinGW leben, aber ich pers. halte es für ein trauriges Ziel, das jede Anwendung auf jedem System gleich ist. Weil dann brauche ich keine Systemvielfalt mehr. Es ist für mich paradox, das ich z.B. X11 nutze, aber die Anwendung 1:1 wie die Windows-Version arbeitet (oder umgekehrt, in Windows habe ich X11-Verhalten). Dann kann ich auch gleich bei Windows bleiben.

Mein Anspruch ist Portabilität, aber bitte nicht zum Nachteil des Anwenders. Und ja, es ist ein Anspruch im wahrsten Sinne des Wortes.

Wenn ich noch weiter gehen würde, würde ich sogar nicht nur die Plattform unterscheiden, sondern noch die Compiler-Umgebung (MSVC und MinGW), was ich teilweise sogar praktiziere (siehe einen meiner vorherigen Posts!)! Aber die Man-Power ist begrenzt.

blue-tec

Da hast du mir leider gar nix neues erzählt, ich denke fast jeder hat schon mal kleine Wrapper um API Funktionen geschrieben und Fehlendes bei der einen oder anderen Plattform selbst implementiert. Mir ist auch klar das Qt viel selbst macht um den Portierungaufwand gering zu halten und es trotzdem schafft ein nativen Look hinzubekommen, während andere Frameworks wie wxWidgets mehr nativ sind und Libs wie FLTK so gut wie alles selbst machen. Das alles weiß man wenn sich ein paar Wochen mit C++ und GUI auseinandersetzt.

WinAPI verwendet Qt deswegen trotzdem auch mit MinGW, wie man auch aus de Headern sehen kann, ich habe nur mal kurz nachgeguck und gleich an Handle auf den Gerätekontex gefunden also einen hdc = GetDC blabla. Auch wenn sie die API sparsam nutzen.

Wenn man eine plattformunabhängige Lib entwickelt kann man ja nur viel anbieten aber dafür auch viel selbst machen oder den kleinsten gemeinsamen Nenner finden und ne 0815 Lib(im Vergleich zu Qt) machen die sehr eingeschränkt ist.

Gruß Blue-Tec

P.S. Ist ja auch Wurst, da wir ja herausgefunden haben das es wohl nicht so schlecht um MinGW aussieht.

Hello! fcekgbe interesting fcekgbe site!

f.-th. schrieb:

Wollt ihr ein paar Fragen zu dem Thema

Ich, ich, ich kann die Fragen beantworten!

Wie ist DOS Entstanden?

Bill Gates hat's programmiert.

Welche Firmen haben zu Anfang Windows entwickelt?

Das war Microsoft.

Welche Vorläufer gab es mit graphischen Bedieneroberflächen?

Hm, DOSSHELL oder Windows 1.0. Eines von dem beiden war es.

Welche Textverarbeitungen gab es vor Word?

Edit.exe von Microsoft

Welche Tabellenkalkulation gab es vor Excel?

Keine Ahnung, aber da QBasic bei DOS mitgeliefert wurde, konnte man damit schon schön Tabellen ausrechnen lassen. Man mußte halt ein bischen Basic programmieren können.

Welche Datenbanken gab es vor den MS-Produkten?

Das war Adabas.

Und ich kann noch eine Frage beantworten, die du nicht gestellt hast:

Wer hat das Internet erfunden?

Das war Bill Gates.

Mit dem Internet Explorer fingen plötzlich alle Firmen an, im World Wide Web present zu sein.

MS Shareholder schrieb:

Wie ist DOS Entstanden?

Bill Gates hat's programmiert.

okay wenn die erste antwort schon müll ist brauch ich den rest nicht lesen.