undefined reference to InitCommonControls

Neonof

Mitglied
Hallo,
folgendes Problem:

Ich versuche mittels der Windows-API eine GUI für meine Anwendung zu schreiben und möchte ein Tab-Control erstellen. Damit die Fensterklasse WC_TABCONTROL bekannt ist, verwende ich wie üblich InitCommonControls().

Beim Kompilieren gibt es nun die Meldungen:
warnung: "implicit declaration of function 'InitCommonControls'"
error: "undefined reference to `InitCommonControls'
(detaillierter Errorlog im Anhang)

Die Funktion ist also nicht bekannt.
windows.h ist natürlich eingebunden.

Hier die verwendete Software:
IDE: CodeLite 10.0.6
Compiler: MinGW(TDM-GCC-64)
System: Windows 10 Pro

Meine Projekteinstellungen:
Screenshots

Mein Code:
C:
#define STRICT
#include <windows.h>
//#include <stdio.h>
//#include <stdlib.h>

HINSTANCE app_hInstance = NULL;

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
        case WM_CREATE:
        {
            static RECT rcClient;
            static HWND hwndCtrlTab1;
//            static TC_ITEM tie;
      
            GetClientRect(hWnd, &rcClient);
            InitCommonControls();
            hwndCtrlTab1 = CreateWindow(WC_TABCONTROL, "", WS_CHILD | WS_CLIPSIBLINGS | WS_VISIBLE, 0, 0, rcClient.right, rcClient.bottom, hWnd, NULL, app_hInstance, NULL);
      
            return 0;
        }
        case WM_DESTROY:
        {
            PostQuitMessage(0);
            return 0;
        }
        default: return DefWindowProc(hWnd, message, wParam, lParam);
    }
}

const char szAppName[] = "AnagramTools";

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
    HWND hWnd;
    MSG msg;
    WNDCLASS wc;
    app_hInstance = hInstance;
 
    wc.style = CS_HREDRAW | CS_VREDRAW;
    wc.lpfnWndProc = WndProc;
    wc.cbClsExtra = 0;
    wc.cbWndExtra = 0;
    wc.hInstance = hInstance;
    wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
    wc.hCursor = LoadCursor(NULL, IDC_CROSS);
    wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
    wc.lpszMenuName = NULL;
    wc.lpszClassName = szAppName;
 
    if (!RegisterClass(&wc))
    {
        MessageBox(NULL, "Fensterregistrierung fehlgeschlagen!", "Fehler!", MB_ICONERROR | MB_OK);
        return 0;
    }
 
    if (!(hWnd = CreateWindow(szAppName, szAppName, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL)))
    {
        MessageBox(NULL, "Fenstererstellung fehlgeschlagen!", "Fehler!", MB_ICONERROR | MB_OK);
        return 0;
    }
 
    ShowWindow(hWnd, iCmdShow);
    UpdateWindow(hWnd);
 
    while (GetMessage(&msg, NULL, 0, 0))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
 
    return msg.wParam;
}

Der Code richtet sich nach dem Beispiel aus der Win32 Programmer's Reference -> Creating a Tab Control

C:
#define STRICT
setze ich, weil es in einem Tutorial mal hieß, das gewähre bessere Typsicherheit. Es spielt hierfür keine Rolle. Der Fehler tritt mit und ohne auf.

Ich habe auch versucht, selbigen Code einmal mit Pelles zu kompilieren. Dort tritt der gleiche Fehler auf.

ComFreek hatte mal ein ähnliches Problem, nutzte jedoch andere Software, weshalb ich mit seiner Lösung nicht direkt etwas anfangen kann:
Ich habe es gerade geschafft Ich hatte wxWidgets mit "SHARED=0" kompiliert, aber dann bei den Einstellungen in Code::Blocks "DLL" angegeben!
(Ich habe 1,5 Wochen daran gesessen! :))
Da ich mit Code::Blocks keine Erfahrung habe, sagt mir "SHARED=0" nicht sehr viel. Falls das ein Argument innerhalb eines Makefiles ist, kann ich damit ebenfalls nichts anfangen, da ich keines nutze. Allerdings lässt mich seine Lösung vermuten, dass ich ein entsprechendes Flag setzen oder ein Makro definieren muss, ehe ich die windows.h einbinde.

Weiß einer eine Lösung?

Danke schon einmal für Hilfe!

Gruß,
Neonof
 

Anhänge

  • BuildLog.txt
    1,9 KB · Aufrufe: 1
Zuletzt bearbeitet:
Hi

Gemäss MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/bb775695(v=vs.85).aspx

Du musst die "Commctrl.h" einbinden (implicit declaration error) und gegen die "Comctl32.lib" linken (undefined Reference error) (letzteres müsste eigentlich schon der Fall sein, aber wer weiss...).

Gruss
cwriter

/EDIT: Allerdings:
msdn hat gesagt.:
Under Comctl32.dll version 6.0 and later, InitCommonControls does nothing. Applications must explicitly register all common controls through InitCommonControlsEx.
=> InitCommonControlsEx verwenden.
 
Da sind meine Helpfiles wohl schon etwas veraltet. Ich sollte mir angewöhnen, häufiger ins msdn zu schauen.
Vielen Dank für die Hilfe! :)

Kennst du aktuellere offline Helpfiles?
Ist ja noch nicht lang her, dass ich wieder ausgiebig suchte.

Bezüglich InitCommonControlsEx() treten keine Fehler als solches mehr auf, allerdings fehlt immernoch eine Referenz.
gegen die "Comctl32.lib" linken
Wie linke ich eine lib gegen ein spezielles Headerfile? Macht man das in den Projekteinstellungen oder im Code?
Wenn ich nur die Commctrl.h gegen die Comctl32.lib linken soll, würde ich denken, ich müsste sie im Code der Commctrl.h inkludieren - doch die sollte ja nicht verändert werden und bereits alles benötigte zur Verfügung stellen. Bestimmt ist die Antwort ganz einfach und ich verpeile nur mal gerade wieder, was zu tun ist... :rolleyes:

Das ist nun der Code:
C:
#define STRICT
#include <windows.h>
#include <Commctrl.h>
//#include <stdio.h>
//#include <stdlib.h>

HINSTANCE app_hInstance = NULL;

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
        case WM_CREATE:
        {
            static RECT rcClient;
            static HWND hwndCtrlTab1;
//            static TC_ITEM tie;
           
            GetClientRect(hWnd, &rcClient);
           
            INITCOMMONCONTROLSEX ctrlclass;
            ctrlclass.dwSize = sizeof(INITCOMMONCONTROLSEX);
            ctrlclass.dwICC = ICC_TAB_CLASSES;
           
            InitCommonControlsEx(&ctrlclass);
            hwndCtrlTab1 = CreateWindow(WC_TABCONTROL, "", WS_CHILD | WS_CLIPSIBLINGS | WS_VISIBLE, 0, 0, rcClient.right, rcClient.bottom, hWnd, NULL, app_hInstance, NULL);
           
            return 0;
        }
        case WM_DESTROY:
        {
            PostQuitMessage(0);
            return 0;
        }
        default: return DefWindowProc(hWnd, message, wParam, lParam);
    }
}

const char szAppName[] = "AnagramTools";

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
    HWND hWnd;
    MSG msg;
    WNDCLASS wc;
    app_hInstance = hInstance;
   
    wc.style = CS_HREDRAW | CS_VREDRAW;
    wc.lpfnWndProc = WndProc;
    wc.cbClsExtra = 0;
    wc.cbWndExtra = 0;
    wc.hInstance = hInstance;
    wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
    wc.hCursor = LoadCursor(NULL, IDC_CROSS);
    wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
    wc.lpszMenuName = NULL;
    wc.lpszClassName = szAppName;
   
    if (!RegisterClass(&wc))
    {
        MessageBox(NULL, "Fensterregistrierung fehlgeschlagen!", "Fehler!", MB_ICONERROR | MB_OK);
        return 0;
    }
   
    if (!(hWnd = CreateWindow(szAppName, szAppName, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL)))
    {
        MessageBox(NULL, "Fenstererstellung fehlgeschlagen!", "Fehler!", MB_ICONERROR | MB_OK);
        return 0;
    }
   
    ShowWindow(hWnd, iCmdShow);
    UpdateWindow(hWnd);
   
    while (GetMessage(&msg, NULL, 0, 0))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
   
    return msg.wParam;
}
 
Kennst du aktuellere offline Helpfiles?
Nein, aber die MSDN sollte sich als Webarchiv speichern lassen, z.B. das hier: https://msdn.microsoft.com/en-us/library/windows/desktop/hh298367(v=vs.85).aspx

Das Problem bei offline-Dateien ist ja immer, dass die Inhalte zwangsläufig veralten, was auf der MSDN immerhin zumindest mit einem Hinweis gekennzeichnet wird.

Wenn ich nur die Commctrl.h gegen die Comctl32.lib linken soll, würde ich denken, ich müsste sie im Code der Commctrl.h inkludieren - doch die sollte ja nicht verändert werden und bereits alles benötigte zur Verfügung stellen. Bestimmt ist die Antwort ganz einfach und ich verpeile nur mal gerade wieder, was zu tun ist... :rolleyes:
Im Prinzip fehlt dem Linker ja die Definition der Funktion, die Headerdatei gibt nur die Deklaration (also wie die Funktion aussieht, nicht, was sie tut). Diese Definition wird dann im Linkvorgang aus der Bibliothek geladen (bzw. der Verweis darauf, dass die Funktion in der DLL zu finden ist).

Der Linker läuft nach dem Compiler, daher sieht er den Sourcecode nicht. (Ausser bei VS, wo ein #pragma comment(lib, "CommCtl.lib") dem Linker mitteilt, dass noch etwas gelinkt werden soll. Meines Erachtens sehr angenehm, auch wenn es nicht 100%ig korrekt ist).

Daher:
lib-Dateien kommen in die Projekteinstellungen.

Je nachdem musst du auch den Bibliothekspfad angeben (weiss nicht, we seriös CodeLite die PATH-Variable berücksichtigt).

Gruss
cwriter
 
Je nachdem musst du auch den Bibliothekspfad angeben (weiss nicht, we seriös CodeLite die PATH-Variable berücksichtigt).
Treffender Kommentar ^^'
CodeLite meldet: cannot find -lComctl32.lib

Ich habe den jetzigen Code mit Pelles ausprobiert und wollte die lib eintragen, da war das sogar schon erledigt. Damit funktioniert es einwandfrei.

Den kompletten Pfad anzugeben wird schwierig, da ich die lib über den Explorer nicht gefunden habe, das Verzeichnis also nicht kenne. Kennt ihr es?

Da das eigentliche Problem gelöst ist, da es mit Pelles funktioniert, markiere ich das Thema mal als erledigt. Vielen Dank bisher.

@sheel:
Mir ist schon einmal irgendwo aufgefallen, dass es eine Art Wiki auf dieser Seite geben muss. In dem Pfad des von dir geposteten Screens taucht das auch wieder auf, doch ich finde keines. Was hat es damit auf sich?

Gruß,
Neonof

Edit:
Pfad gefunden: "C:\PoR\Windows Kits\10\Lib\10.0.14393.0\um\x86"
Doch trotz Angabe findet er die Lib nicht. Ich habe ausprobiert den Pfad wie oben in das Pfadfeld zu packen - dabei tauchen dann ganz viele andere Fehler auf, bei denen er libs nicht findet - oder (natürlich mit abschließendem Backslash) vor den Dateinamen.

Es liegt auch nicht an dem Leerzeichen im Pfad. Mit Leerzeichenlosen Pfad findet er die auch nicht.
 
Zuletzt bearbeitet:
CodeLite meldet: cannot find -lComctl32.lib
Was ist die Build-Ausgabe?
Es ist nicht unüblich für IDEs, das -l selbst anzuhängen, sodass es bei dir wohl ein -l"-lComctl32.lib" wird, wenn es nur ein -lComctl32.lib sein sollte.
Ansonsten musst du entweder den vollen Pfad angeben oder den Bibliothekspfad entsprechend angeben (-L), aber dafür müsstest du wissen, wo die Comctl32.lib liegt.

Ich habe den jetzigen Code mit Pelles ausprobiert und wollte die lib eintragen, da war das sogar schon erledigt.
Ja, Visual Studio macht das auch automatisch, macht auch Sinn bei den allermeisten Windows-Projekten. Apropos: Gibt es einen bestimmten Grund, warum du VS meidest? Gerade für Windows-Only-Programme ist VS recht gut (für Cross-Platform/Low-Level-Projekte ist es ziemlich beknackt).

Gruss
cwriter
 
Es ist nicht unüblich für IDEs, das -l selbst anzuhängen, sodass es bei dir wohl ein -l"-lComctl32.lib" wird, wenn es nur ein -lComctl32.lib sein sollte.
Ich habe das -l nie selbst angehängt. Das macht CodeLite von selber.

Ansonsten musst du entweder den vollen Pfad angeben oder den Bibliothekspfad entsprechend angeben (-L), aber dafür müsstest du wissen, wo die Comctl32.lib liegt.
Genau die beiden Möglichkeiten habe ich probiert. Beides lieferte keinen Erfolg.
Einmal den Pfad des Verzeichnisses für mehr Fehler und einmal den Pfad vor den Dateinamen.

Hier die Build-Ausgabe:
C:\Windows\system32\cmd.exe /C C:/PoR/TDM-GCC-64/bin/mingw32-make.exe -j4 SHELL=cmd.exe -e -f Makefile
"----------Building project:( AnagramTools - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'C:/Users/Neonof/Documents/c/Projekte/AnagramTools'
C:/PoR/TDM-GCC-64/bin/g++.exe -o ./Debug/AnagramTools @"AnagramTools.txt" -L. -l"C:\PoR\PellesC\Lib\Win\comctl32.lib" -mwindows
C:/PoR/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lC:\PoR\PellesC\Lib\Win\comctl32.lib
collect2.exe: error: ld returned 1 exit status
mingw32-make.exe[1]: *** [Debug/AnagramTools] Error 1
AnagramTools.mk:78: recipe for target 'Debug/AnagramTools' failed
mingw32-make.exe[1]: Leaving directory 'C:/Users/Neonof/Documents/c/Projekte/AnagramTools'
mingw32-make.exe: *** [All] Error 2
Makefile:4: recipe for target 'All' failed
====1 errors, 0 warnings====
Das war jetzt ein zweiter Versuch mit einem alternativen Pfad. Erst probierte ich es mit der comctl32.lib aus dem SDK.

Gibt es einen bestimmten Grund, warum du VS meidest? Gerade für Windows-Only-Programme ist VS recht gut (für Cross-Platform/Low-Level-Projekte ist es ziemlich beknackt).
VS nutzte ich ursprünglich. Ich erinnere mich ehrlich gesagt nicht mehr genau welche, aber es machte irgendwann nur noch Probleme. Auch gefiel mir nicht, dass es so viele eigene Funktionen verwendet, die sonst nirgends bekannt sind. Außerdem sind die damit kompilierten exe-Dateien immer relativ groß und - denke ich - nicht einmal sehr effizient. Bei den kleinen Programmen, die ich bisher schreibe, ist das sicherlich nicht weiter relevant. Es machte wie gesagt Probleme, wegen derer ich mich nach Alternativen umsah. Die Kompatibilität des damit geschriebenen Codes mit anderen Compilern war dabei auch ein Punkt. Außerdem bin ich kein Freund von Monopolen. Ich gehe eher von Anfang an in die Richtung, meine Programme möglichst plattformunabhängig zu schreiben. Gerade für Entwickler ist es doch Mist, wenn sie bei dem was sie nutzen wollen, dauernd an ein System oder eine Software gebunden sind - von der wirtschaftlichen Perspektive mal ganz abgesehen, Microsoft kein Monopol zu gönnen. :-]

Low-Level ist auch wieder so eine Sache. Ich finde C so klasse, weil es sehr hardwarenah ist und sich rechenaufwändigere Algorithmen damit effizienter umsetzen lassen. Daher wollte ich besser gleich Funktionen lernen, die nicht so abstrahiert sind. Bei VS kam es mir immer ziemlich so vor, als ob hinter jedem eigenen Befehl noch zusätzlich tausend Zeilen Code steckten, die zwar das Programm sicherer gestalteten - aber mir zum lernen dann doch weniger brächten. Klar ist das schreiben von Programmen in C nach verbreiteter Meinung sehr mühselig, aber das ist mir der Aufwand dann wieder wert und ich will ja bei Fehlern mit dem System in Konflikt geraten um sie verstehen zu können. (Auch wieder ein Grund, weshalb ich eure Erklärungen auch in fremden Threads gerne verfolge. Da ist immer viel Hintergrundwissen mit bei.)

Eigentlich wäre ich wohl nicht einmal ein Windowsfan. iOS noch weniger. Eigentlich tendiere ich zu Linux. Aber mit Windows bin ich aufgewachsen und kenne das nun einmal am besten.

Gruß,
Neonof
 
Zuletzt bearbeitet:
Pfad gefunden: "C:\PoR\Windows Kits\10\Lib\10.0.14393.0\um\x86"
Das sieht mir aber stark nach dem (Standard)-VS-WinSDK-Pfad aus.
Daher auch:
Doch trotz Angabe findet er die Lib nicht. Ich habe ausprobiert den Pfad wie oben in das Pfadfeld zu packen - dabei tauchen dann ganz viele andere Fehler auf, bei denen er libs nicht findet - oder (natürlich mit abschließendem Backslash) vor den Dateinamen.
Die verschiedenen Compiler/Linker verstehen einander dabei wahrscheinlich nicht, sodass mehr Fehler entstehen.

Ich habe das -l nie selbst angehängt. Das macht CodeLite von selber.
Ja, das meinte ich auch. Ich war von der Fehlermeldung verwirrt, die sagte, dass der Linker "-lcomctl32.lib" nicht finden könnte.
Hast du es mit "comctl32" (ohne .lib-Zusatz, ohne vollem Pfad) probiert? Eigentlich müsste die Bibliothek so gefunden werden (wenn man denn dem Internet glauben schenken kann).

Das war jetzt ein zweiter Versuch mit einem alternativen Pfad. Erst probierte ich es mit der comctl32.lib aus dem SDK.
Hm. Ist Pelles C nicht IDE und Compiler, also nicht MinGW? Eigentlich sollte auch diese Mischung nicht gehen dürfen.

Zu VS: Hey, deine Arbeit, dein Werkzeug :)
Einige Punkte möchte ich dennoch ansprechen:
Auch gefiel mir nicht, dass es so viele eigene Funktionen verwendet, die sonst nirgends bekannt sind.
Ja, VS ist lascher, was den Standard angeht. Allerdings fand ich das nie schlecht, wenn man keinen anderen Compiler nutzen wollte (bzw. Clang hat die Microsoft-Extensions sogar als option übernommen).

Außerdem sind die damit kompilierten exe-Dateien immer relativ groß und - denke ich - nicht einmal sehr effizient.
Das ist interessant - meine Kompilate waren immer sehr klein (~50KB), da VC Redistributable quasi alles auslagert. Hier kommt es wohl vor allem auf die Einstellungen an. Zur Effizienz: Ich sehe bei einem sehr performance-kritischen Programm, an dem ich gerade arbeite, keinen Unterschied in Performance zwischen GCC und VS (viele Bit-Operationen, Bitfields, Random Reads, Sequential Reads (beides RAM)).

Ich gehe eher von Anfang an in die Richtung, meine Programme möglichst plattformunabhängig zu schreiben.
Das ist gut so (Portierungen sind immer teuer), allerdings ist dein Programm ja ziemlich an Windows gebunden (WinAPI). Die Logik ist dank mehr oder weniger vollständiger C++14-Unterstützung auch in VS machbar, und portabel, sofern man nicht zu viele VS-Features aus versehen nutzt (das ist zugegebenermassen ziemlich schwer).

, Microsoft kein Monopol zu gönnen.
Microsoft hat sich (glücklicherweise) ja stark geöffnet; z.B. kann man in VS (IDE) mittlerweile Clang statt VS (Compiler) verwenden.

Daher wollte ich besser gleich Funktionen lernen, die nicht so abstrahiert sind. Bei VS kam es mir immer ziemlich so vor, als ob hinter jedem eigenen Befehl noch zusätzlich tausend Zeilen Code steckten, die zwar das Programm sicherer gestalteten - aber mir zum lernen dann doch weniger brächten.
Falls du auf die "sicheren" _s-Funktionen ansprichst: Ja, damit hat man sich sehr in den Fuss geschossen. Allerdings ziehen sich diese "sichereren" Funktionen durch alle Compiler, nur war Microsoft so blöd*, mit errors um sich zu werfen, was viele vergraulte.
Codemässig generiert VS nicht nennenswert mehr Code, es sei denn, du sprichst die C++-Chimären (C++/CX, C++/CLI) an, diese sind tatsächlich Schund.

*: Aus einem marketingtechnischen Sinn machte das übrigens durchaus Sinn: Der Nutzer assoziiert BSoDs mit Microsoft, gibt MS die Schuld daran, obwohl es die Gerätetreiber sind, die die allermeisten BSoDs verursachen. Diese "sichereren" Funktionen (zusammen mit vielen anderen Massnahmen) sollten sichereren Code ergeben und die Gerätehersteller zwingen, korrekten Code zu schreiben.

Klar ist das schreiben von Programmen in C nach verbreiteter Meinung sehr mühselig, aber das ist mir der Aufwand dann wieder wert und ich will ja bei Fehlern mit dem System in Konflikt geraten um sie verstehen zu können.
Gerade hier finde ich die eingebauten Diagnosetools konkurrenzlos. Klar, Valgrind/Callgrind funktioniert auch sehr gut, aber VS hat alles direkt verfügbar und stellt alles sehr übersichtlich dar.

Eigentlich wäre ich wohl nicht einmal ein Windowsfan. iOS noch weniger. Eigentlich tendiere ich zu Linux. Aber mit Windows bin ich aufgewachsen und kenne das nun einmal am besten.
Falls du Fensteranwendungen für alle Plattformen machen willst, kann ich Qt nur empfehlen. Es ist nicht das schönste und auch nicht das effizienteste Framework, aber es ist gut genug, und der QtCreator ist die einzige IDE, die zumindest ansatzweise an VS herankommt.

Schlussendlich finde ich VS am bequemsten: Alles ist da und das meiste wird dir gemacht, ohne, dass du dich darum kümmern musst. Sobald man volle Kontrolle will, führt aber kein Weg an Linux / GCC / Makefiles / Linkerscripts vorbei.

Ich brachte VS auch nur auf den Tisch, weil ich es für die allermeisten Windowsprojekte schlicht für am einfachsten halte, was Einrichtung und Co. angeht, sodass man sich auf das Programmieren selbst fokussieren kann. VS ist einfach das Rundum-Sorglos-Paket, das Problem ist das "zu sorglos", was eben die lasche Standardeinhaltung, die Einschränkungen (z.B. kein inline-Assembly) und die teils grotesk verformten Funktionen zur Folge hat.
Ich selbst nutze VS nur noch selten (Linuxnutzer), aber wenn, dann merke ich, was ich verpasse.

Naja, alles ein bisschen OT. Wenn es bei dir jetzt funktioniert, ist ja alles gut.

Ok, zwischenzeitlich sind die Testkompilate durch:
(Beides Releasemode / O2)
MinGW 32bit:
194 KB
VS2017 64bit:
187 KB

(Habe keinen MinGW 64bit zur Hand).
32bit Programme müssten eigentlich kleiner sein als 64bit-Programme, aber die Programme sind hier praktisch gleich gross. Wie gesagt, die Compiler schenken sich da nichts, und VS muss sich nicht vor der Konkurrenz verstecken (ausser in Standardkonformität ;))

Gruss
cwriter
 
Zurück