Best C++ Compiler?

[kim366]

Hi! I am looking for a light-weight C++ Compiler for Windows like GCC under Linux. I don't want IDEs, because I have my desired text editing program already and they create unnecessary files, make the projects and executables bigger than they should be and you need to install that IDE to be able to run the program.

Just post any Compilers you have good experiences with.

Thank you!

[TarikNeaj]

You can use GCC on windows.

[Computergeek01]

Are you playing a joke on us here OP? http://sourceforge.net/projects/mingw-w64/

[Disch]

I don't want IDEs, because I have my desired text editing program already

IDEs are less about the text editor and more about all the other stuff they have built in. Most importantly: the interactive debugger.

You can't [easily] set breakpoints and step through code and examine var contents at runtime with a general text editor. You'd need an interactive debugger. This is the big selling point of IDEs and is why I would never even consider coding in a language like C++ without one.

and they create unnecessary files,

Define "unnecessary"?

They typically create one or 2 files to house the project... but apart from that the only things they create are object files -- which every compiler needs to create regardless of whether or not you use an IDE.

make the projects and executables bigger than they should be

Neither of those are true.

and you need to install that IDE to be able to run the program.

That is not true either.

[Computergeek01]

You know, I didn't even read up to your absurd objections to using an IDE. I honestly didn't even get passed the stupidity of your first sentence. I smell a troll, and now I'm moving on.

[kbw]

light-weight C++ Compiler for Windows like GCC under Linux

Nothing's lightweight under Linux anymore. Have you looked at the 4.8 or 4.9 compiler chain?

I don't want IDEs

Good for you, but GUI developers working in a GUI expect one, "so try it, you'll like it".

Just post any Compilers you have good experiences with.

On Windows, you really should be using Visual Studio, forget the rest.

[kim366]

You can use GCC on windows.

Thank you very much! I installed it.

Good for you, but GUI developers working in a GUI expect one, "so try it, you'll like it".

What are GUI developers? I am a general developer who also creates GUIs, so why are you so specific? And I don't care about other people. Guys, I asked you about Compilers and not about your opinion!

make the projects and executables bigger than they should be


Neither of those are true.

and you need to install that IDE to be able to run the program.


That is not true either.

So I installed VC++ 2010 just for you to proove you wrong. I mde a little project

#include <iostream>

int main(int argc, char const *argv[])
{
	std::cout << "It works!";
	std::cin.get();
	return 0;
}

I compiled it with GCC and VC++. I got one little 48KB executable with GCC. With VC++ on the other hand I got a whole folder with 2 Debug folders, an ipch folder and some weird .vcxproj and .vcxproj.filters files. I don not need that crap. The folder size was 22MB. So if that is not a difference for you, then you are weird. And without the VC++ Redistributable the exe will just not run!

[Disch]

Don't rag on a tool because you don't know how to use it.

With VC++ on the other hand I got a whole folder with 2 Debug folders, an ipch folder and some weird .vcxproj and .vcxproj.filters files. I don not need that crap.

Yeah I don't know what the ipch thing is. I'll concede that.

But the vcxproj and filters file are project files. Those are expected. They're basically the IDE's version of a build script or makefile.

And without the VC++ Redistributable the exe will just not run!

You must have done a debug build and not a Release build.

Debug builds have debugging symbols exported and use clunkier versions of runtime libs to make debugging easier.

When you do a Release build, all that crap is stripped and you get a lean executable.

And without the VC++ Redistributable the exe will just not run!

Again... debug build.

Though you do need runtime libs in Release as well -- however these days the libs come bundled with Windows, so anyone running Windows will already have them installed.

Furthermore, GCC uses runtime libs too.



I built your example program in MSVS 2013 with optimized settings and got these results:


1) 11 kB executable using external runtime libs (again these libs come with Windows installations so people will have them). This is comparable to the executable GCC is producing for you, as GCC is also relying on external DLLs for the runtime.


2) 142 kB executable using statically linked runtime libs (no external DLLs needed). This is an option if you are paranoid about people not having the runtime libs installed.





Yeah IDE projects are going to use more HD space, but that's because they do more. Again, it's about getting an interactive debugger. The final executable does not suffer from it at all, though. It just makes development easier.

[kim366]

I still prefer Sublime Text 3.

[ArmunAlam]

I prefer using an IDE! kim366, it is your choice though, but you can try using an IDE ~ I guess you'll like it after using it a while. So far I know, great developers use IDEs. After all, it is your choice!

[Disch]

I still prefer Sublime Text 3.

That's fine. Use whatever you want. Sublime is a great text editor.

But coding without a debugger is masochism.

[kbw]

Yeah I don't know what the ipch thing is. I'll concede that.

Pre-compiled Header database.

I bought a memory card for my phone a few months ago; 128G. The last trading system I worked on had more memory than disk space. Dev laptops at work ship with 16/32G for running Linux hosted VMs as needed. Who cares about a few k these days?

[Disch]

kbw: ah, that explains why it's there for my big project but not for the test one I created to run that guy's program.

And I can understand not wanting bloat. That's perfectly reasonable. But coding C++ without a debugger? That's insanity.

[freddie1]

The material I'm going to present may be pertinent to the discussion. For the past two years I've been converting my 'mission critical' enterprise software from PowerBASIC to C++. We're talking several hundred thousand lines of pure SDK Win32 Api code. My intent has been to be able to create x86/x64 code compileable with both Microsoft VC++ and GNU GCC. I'm only doing wide character builds.

In a nutshell, it hasn't been that hard to do, but unlike most here at this site probably, I'm old and pretty much know what I'm doing (its the old part that is pretty much unlike others here - not that you don't know what you are doing). I started coding on mainframe computers back in the mid 70s. Used various versions of BASIC back in the 80s and 90s; taught myself C and C++ during the 90s. Since 2000 I've mostly used C/C++ for Windows CE coding, and PowerBASIC SDK code for desktop/laptop Windows use. Now for the particulars.

This very simple program won't compile with VC9...

// g++ Ar1.cpp -oAr1_x64.exe -mconsole -m64 -s -Os   // < x64
// cl Main.cpp
#include <cstdio>

int main(void)
{
 int x,y;

 y=3, x=4;
 int iAr[y][x];
 getchar();

 return 0;
}

Other day I downloaded the Windows 7 SDK which is VC10 maybe? But hadn't tested with that yet (not on this computer). But either in the IDE or command line compiling it won't work. Here are the error messages...

C:\Code\VStudio\VC++9\MultiDimArray\MultiDimArray>cl Main.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

Main.cpp
Main.cpp(9) : error C2057: expected constant expression
Main.cpp(9) : error C2466: cannot allocate an array of constant size 0
Main.cpp(9) : error C2057: expected constant expression
Main.cpp(9) : error C2466: cannot allocate an array of constant size 0
Main.cpp(9) : error C2087: 'iAr' : missing subscript
Main.cpp(9) : error C2133: 'iAr' : unknown size

The bare C++ language of course has very, very poor dynamic multi-dimensional array capabilities. If one can get past the horrible syntax, the C++ Std. Lib. has the capabilities to handle this stuff.

On the other hand, that program above compiles and runs fine in any version of GCC C++ I have. So in that one instance GCC comes out a bit in front of MS VC++.

Moving on, consider this ...

#ifndef   UNICODE
   #define   UNICODE
#endif
#ifndef   _UNICODE
   #define   _UNICODE
#endif
#include <windows.h>
#include <cstdio>
#include "Strings.h"


int main()
{
 String s1,s2;

 s1 = L"iNumber = " + Str(123456789);
 wprintf(L"%s\n",s1.lpStr());
 getchar();

 return 0;
}

This ...

String

...is my String Class - not the one in the C++ Std. Lib. As might be typical, my String class has a lot of constructors, and I handle conversions of numbers in binary format to strings through operator= calls or constructors. This ...

Str(123456789);

...is simply a function call that returns a String (my String Class - not shown). This is the function ...

String Str(int iNum)
{
 return iNum;
}

That operates through the return statement calling one of my overloaded String constructors as such ...

String::String(int iNum)
{
 this->lpBuffer=new TCHAR[16];
 this->iCapacity=15;
 this->iLen=_stprintf(this->lpBuffer,_T("%d"),iNum);
}

... so this ...

s1 = L"iNumber = " + Str(123456789);

...is simply a line to assign a string literal plus a function that returns one of my String Objects to another one of my String Objects. The result of course should be ...

iNumber = 123456789

VC9 does it without a whimper. GCC refuses to compile it. Says it can't resolve operator+ call.

So you see the way these things can go. Each compiler is just a bit different. They are very highly compatible. I'd say like 99.99999% compatible. But you will come across differences. In my large code conversion projects I'm handling the slight differences through conditional compilation statements. Pertaining to these two compilers I've found I can get by with just two, which I have defined like so...

#define VSTUDIO
#define NEW_GCC 

What the VSTUDIO define is used for is that GCC doesn't seem to know anything about High DPI (Dots Per Inch) coding - at least up to the 4.8 series compilers. I know 4.9 came out fairly recently, but I haven't gotten around to trying that yet. SetProcessDPIAware() and IsProcessDPIAware(), as well as some others were added to the Api with VC9 and Vista. These calls are not present on Win 2000/XP, so to use my code on those OSs I use the typical LoadLibrary()/GetProcAddress() call sequence. So that's what the VSTUDIO define is mostly used for (although it is used for something else on another one of my apps).

On GCC these calls do not seem to exist. At least they are not declared in winuser.h Perhaps I could get it to work if I simply declared the function. I really don't know how the MinGW organization came by their libs. Maybe somebody very knowledgable like kbw or disch could enlighten me on that. All I can say for sure is that the function calls won't compile, and if the High DPI Aware setting is put in the manifest it has no effect. So I guess that's another plus in favor of MS VC++.

In terms of my need for 'NEW_GCC', that seems to be a POSIX compliance thing, which I believe is an unresolved issue for MinGW. And its really dumb and is the single biggest nuisance in organizing my code to be compilable by both VC and GCC. Here's an example from one of my apps ...

#ifdef MyDebug
   fprintf(fp,"    Sql.ODBCConnect() Succeeded!\n");
   fprintf(fp,"    hMain                           = %p\n",hMain);
   fprintf(fp,"    pDBPaths                        = %p\n",pDBPaths);
   #ifdef NEW_GCC
      fwprintf(fp,L"    pDBPaths->ActiveDB.szDescriptor = %S\n",pDBPaths->ActiveDB.szDescriptor);
      fwprintf(fp,L"    strDate                         = %S\n",strDate.lpStr());
   #else
      fwprintf(fp,L"    pDBPaths->ActiveDB.szDescriptor = %s\n",pDBPaths->ActiveDB.szDescriptor);
      fwprintf(fp,L"    strDate                         = %s\n",strDate.lpStr());
   #endif
#endif 

You can stare at that and stare at it and not likely see what the difference is. Its a real nuisance! In wide character compiles GCC wants a capital 'S' in printf family functions as the format specifier where character strings are output. And it wants a small 's' for ansi output! VC doesn't seem to care much. And the even wierder thing is it only applies to the newer GCC compilers. The older ones like the 4.4 series behave like VC in this - they don't care! So for the newer GCC builds I have to uncomment my 'NEW_GCC' #define.

I get a kick out of Disch. He's a holder of strong opinions. Like his one that anybody who tries to do C++ coding without a debugger is insane or a masochist. I guess that's me because the last time I used stepping debuggers is when I was teaching myself assembler coding ages ago. Its not that I have anything against them. Its just that I do a lot of database related work with tables of values and a trace/output log file seems to work better for me in showing tabular values and the history of how I got to where I'm at in the code. I'd also have to say that for many of the types of data entry/editor type applications I've done over the years debuggers simply didn't work well.

continued...

[freddie1]

That being the case (that I don't use stepping debuggers), I'm very sympathetic to the original poster's case against IDEs. I prefer the most 'lightweight' one I can find. And that ain't Visual Studio! I recall a humorous blog Charles Petzold made years ago on his website something to the effect that Visual Studio makes you go 'brain dead'. I absolutely abhor their or anybody else's wizard generated code. I abhor the whole pre-compiled header thing. I detest class frameworks of any kind, and I won't even use anything from the C++ Standard Library because in my mind its all bloatware (that's why I have my own String Class, my own template based multi-dimensional array class, my own ODBC Database Class, etc.).

But kbw's comment that if you are writing Windows programs you should be using VC rather than GCC interested me. And I'm not saying he's wrong, for truth be told I've had more 'issues' with GCC than with MS VC. But for the most part I've been able to work around them and to me at least the value of setting up my projects to be compilable with a bunch of C++ compilers was worth the extra work and hassle. For I really want as bug free and perfect code as possible, and compiling with multiple compilers helps find problems I think. Also it gives one perspective.

The reason I've been converting this code to C++ is because the creator of PowerBASIC, which has been far and away my favorite Windows development language for a long time, passed away a couple years ago, and I don't believe further development of that language is a possibility. And Bob never ported to 64 bit. So its pretty much the ultimate Win32 SDK x86 development environment but its stuck in time and can't move forward.

Using PowerBASIC Windows Version 10 kim's and Disch's little console program above "It Works!" compiles to 8192 bytes and that's with no runtime or other requirements other than a 2000/XP/Vista/7/8 machine...

#Compile Exe                    ' 8192 bytes memory, 8192 on disk
#Dim All
#Include Once "Windows.inc"
#Include Once "WinError.inc"    ' For WAIT_TIMEOUT

Sub Waitkey()
  Dim ir(128) As INPUT_RECORD
  Local dwInputEvents As Dword
  Local blnContinue As Long
  Local hStdInput As Dword
  Register i As Long

  hStdInput=GetStdHandle(%STD_INPUT_HANDLE)
  blnContinue=%TRUE
  Do While blnContinue=%TRUE
     If(WaitForSingleObject(hStdInput,%INFINITE)=%WAIT_TIMEOUT) Then
        Exit Sub
     Else
        ReadConsoleInput(hStdInput,Byval Varptr(ir(0)),128,dwInputEvents)
        For i=0 To dwInputEvents-1
          If ir(i).EventType=%KEY_EVENT And ir(i).Event.KeyEvent.bKeyDown Then
             Exit Sub
          End If
        Next i
     End If
  Loop
End Sub

Function PBMain() As Long
  Local hStdOutput,dwWritten As Dword

  AllocConsole()
  hStdOutput=GetStdHandle(%STD_OUTPUT_HANDLE)
  WriteConsole(hStdOutput,"It Works!",9,dwWritten,0)
  WaitKey()

  PBMain=0
End Function

Using GCC C++ 4.8 series compilers, here is a C++ translation of the above ...

#include <windows.h>  // 16896  20480

void WaitKey(HANDLE hStdInput)
{
 INPUT_RECORD ir[128];
 DWORD nRead;

 do
 {
   if(WaitForSingleObject(hStdInput,INFINITE)==WAIT_TIMEOUT)
      break;
   else
   {
      ReadConsoleInput(hStdInput,ir,128,&nRead);
      for(size_t i=0;i<nRead;i++)
      {
          if(ir[i].EventType==KEY_EVENT && ir[i].Event.KeyEvent.bKeyDown)
             return;
      }//end for
   }//end if
 }//end do
 while(true);
}

int main(void)
{
 HANDLE hStdInput,hStdOutput;
 DWORD dwWritten;

 hStdInput=GetStdHandle(STD_INPUT_HANDLE);
 hStdOutput=GetStdHandle(STD_OUTPUT_HANDLE);
 WriteConsole(hStdOutput,"It Works!",9,&dwWritten,NULL);
 FlushConsoleInputBuffer(hStdInput);
 WaitKey(hStdInput);

 return 0;
}

As can be seen, its about double the size of the PowerBASIC exe. If compiled with VC++ 9 as /MT without runtime dependencies it compiles to 41472 bytes with 45056 on disk. Not wanting C++ compilers to be seen in such a bad light, I will admit with the old 4.4 series GCC compiler I was able to get 6144 bytes, with 8192 bytes on disk. That's the compiler that shipped with CodeBlocks 10.05 circa 2008 or so. However, if I went back to my older PowerBASIC compilers I'm sure I could get a 6k build on that instead of the 8k one I presented first. In fact, with PowerBASIC I can load msvcrt.dll and call printf() and getchar() just as with a C program! That's kind of fun, using the C Std. Lib's functions from PowerBASIC!!!

But getting back to the original poster's points about IDEs, I'm pretty much in agreement with him. Actually, the best of all worlds is just to use the MS VC compiler by itself and just do command line compiling or use another IDE with it. About two years ago I translated my PowerBASIC created ActiveX Grid Control to VC++ and I've never used an IDE to compile it. I build it strictly using the command line tools midl.exe (Microsoft Interface Definition Language Compiler), rc.exe, cvtres.exe, and cl.exe. For a long time I was just using Notepad, then that got burdensome so I used the Code::Blocks IDE for a project setup, but did command line compiling with MS VC9. That was convenient for project organization as there were about 15 files involved, and I could switch between them easier using CodeBlocks than having 15 instances of Notepad open! Maybe this will give you some idea of my animosity toward Visual Studio.

continued....

[freddie1]

By the way, my grid control lovingly built with PowerBASIC involves about 3300 lines of code which compiles to 49k and compacts with UPX to 22k! The way that's coded is all low level the way it would be done in C. When I decided to convert it over to C or C++ I agonized over whether I should use C or C++. Finally, I decided on C++ because of the simple fact that there was a lot of complex string manipulation code involved, which my String Class could easily handle. But at that time and as of yet I have no C code to do what needed done and low level character string buffer manipulations a la C were out of the question. But I might revisit that someday, and redo it in C. So I really didn't have a choice in the matter - it had to be C++, at that time at least. I knew I'd never match the 22k PowerBASIC size but I wanted to do the best I could. I even made a special build of my String Class to remove everything that wasn't used. I ended up with something like a 90k dll which compacted with UPX down to 43k. In other words, about double the size of the PowerBASIC binary. And it really pis*** me off here recently when I added just a couple lines of code to the source to make the grids High DPI Aware and I must have went over some internal allocation boundary for the compiler and now I've got a 50k dll instead of 43 k. But such is life! That's still not too bad. And the x86/x64 sizes are about the same. So now I have an x64 dll for my projects, which I can't have with PowerBASIC much to my dismay.

For me its a real PIA to set up projects quickly with Visual Studio. And I do that a lot to test snippets of code. Sometimes just 5 or 10 line programs to test out some Api function or bit of logic. The first thing MS did that got me torqued off was that character set thing. There shouldn't be an IDE setting for that. MS VC 6 doesn't do it and neither does CodeBlocks.

Gripe #2 is Microsoft trying to enforce 'political correctness' by throwing warning messages over just about everything in the C Std. Lib. relating to string buffers. I'm talking about the 'secure' verses 'unsecure' functions. Everytime I compile I get millions of warning messages so to turn them off I've got to go into Project Properties and paste CRT_SECURE_NO_WARNINGS and CRT_NON_CONFORMING_SWPRINTFS into the right place in the myriads of configuration options. More lost time.

Gripe #3, the thing defaults to Debug builds, which are useless to me since I don't use a stepping debugger, so I've got to waste another five minutes deleting all options to produce Debug builds from the project. By the time I'm done going through all this crazy stuff I've got about ten minutes wasted and all to test out maybe a few lines of code.

And the thing is - all that crap is just the Visual Studio IDE itself. Compiling at the command line is as slick as can be and none of the above distractions are enforced there. Perhaps there are capabilities within Visual Studio itself where the global environment can be changed to not require all that stuff for each project, and if that's the case then I guess I can be faulted for not taking the time to explore and learn how to do that.

The situation is much better with the CodeBlocks editor. I can probably set up a project in two minutes or so. That editor basically just wants to set up a folder/directory for the solution.

But the best and quickest project setup is with the PowerBASIC language. The reason for that is that there isn't any project setup at all. You open the editor then open a new source code screen. To compile you are simply presented with an open file dialog box which asks you to save the file somewhere. It doesn't even care where or require a unique project directory. It compiles it wherever you save it and it compiles it fast - generally compiling 10,000,000 to 20,000,000 lines per minute of source code. The compiler was written in pure asm, which I believe may be unique nowadays. That's why there is no need for pre-compiled headers to speed things up. So after the compile you have only two files - your source and the executable.

continued...

[freddie1]

Since the original poster mentioned program size and Disch even mentioned that it was a worthwhile thing to minimize (which surprised me to hear him say that - I thought C++ coders were immune to such considerations), I'd like to close this lengthy gripe session by mentioning that Matt Pietrek of 'Microsoft Systems Journal' fame worked and wrote a lot on this back in the late 90s. Recently I reviewed some of his work to see if I could use it to minimize the size of x64 executables produced by my newest MS VC compiler, which at the time was VC9. That compiler, like all Microsoft C++ compilers, produces pretty bloated Release executables with the /MT switch - even with Os and O1 optimazations. So I downloaded Matt's LibCTiny.lib source to see if I could compile it with x64. There were a couple glitches I had to fix related to x64 variable types (mostly substituting size_ts for ints if I recall) but I fixed them and got it to compile. You're not going to believe how small I finally got a SDK GUI down to! Are you ready? Here it is....5k!!! Unbelievable! Here are the links to Matt's article....

https://msdn.microsoft.com/library/bb985746.aspx

And I've posted a bit on it here ...

http://www.jose.it-berater.org/smfforum/index.php?topic=5000.0

I should mention that AggressiveOptimize.h is from Todd C. Wilson, who has also done a lot of work on this, but I believe Matt Pietrek's work was his original source of inspiration. Here is the code (except for libctiny.lib) that compiled to 5 k through Matt's work ...

// AggressiveOptimize.h
//////////////////////////////
// Version 1.10
// Jan 23rd, 2000
// Version 1.00
// May 20th, 1999
// Todd C. Wilson, Fresh Ground Software
// ([e-mail])
// This header file will kick in settings for Visual C++ 5 and 6 that will (usually)
// result in smaller exe's.
// The "trick" is to tell the compiler to not pad out the function calls; this is done
// by not using the /O1 or /O2 option - if you do, you implicitly use /Gy, which pads
// out each and every function call. In one single 500k dll, I managed to cut out 120k
// by this alone!
// The other two "tricks" are telling the Linker to merge all data-type segments together
// in the exe file. The relocation, read-only (constants) data, and code section (.text)
// sections can almost always be merged. Each section merged can save 4k in exe space,
// since each section is padded out to 4k chunks. This is very noticable with smaller
// exes, since you could have only 700 bytes of data, 300 bytes of code, 94 bytes of
// strings - padded out, this could be 12k of runtime, for 1094 bytes of stuff!
// Note that if you're using MFC static or some other 3rd party libs, you may get poor
// results with merging the readonly (.rdata) section - the exe may grow larger.
// To use this feature, define _MERGE_DATA_ in your project or before this header is used.
// With Visual C++ 5, the program uses a file alignement of 512 bytes, which results
// in a small exe. Under VC6, the program instead uses 4k, which is the same as the
// section size. The reason (from what I understand) is that 4k is the chunk size of
// the virtual memory manager, and that WinAlign (an end-user tuning tool for Win98)
// will re-align the programs on this boundary. The problem with this is that all of
// Microsoft's system exes and dlls are not tuned like this, and using 4k causes serious
// exe bloat. Very noticable for smaller programs.
// The "trick" for this is to use the undocumented FILEALIGN linker parm to change the
// padding from 4k to 1/2k, which results in a much smaller exe - anywhere from 20%-75%
// depending on the size. 


#ifdef NDEBUG
// /Og (global optimizations), /Os (favor small code), /Oy (no frame pointers)
#pragma optimize("gsy",on)

#pragma comment(linker,"/RELEASE")

// Note that merging the .rdata section will result in LARGER exe's if you using
// MFC (esp. static link). If this is desirable, define _MERGE_RDATA_ in your project.
#ifdef _MERGE_RDATA_
#pragma comment(linker,"/merge:.rdata=.data")
#endif // _MERGE_RDATA_

#pragma comment(linker,"/merge:.text=.data")
#pragma comment(linker,"/merge:.reloc=.data")

#if _MSC_VER >= 1000
// Only supported/needed with VC6; VC5 already does 0x200 for release builds.
// Totally undocumented! And if you set it lower than 512 bytes, the program crashes.
// Either leave at 0x200 or 0x1000
#pragma comment(linker,"/FILEALIGN:0x200")  
#endif // _MSC_VER >= 1000

#endif // NDEBUG 

//Main.h  -- my code now
#ifndef Main_h
#define Main_h

#define dim(x) (sizeof(x) / sizeof(x[0]))

struct WndEventArgs
{
 HWND                         hWnd;
 WPARAM                       wParam;
 LPARAM                       lParam;
 HINSTANCE                    hIns;
};

long fnWndProc_OnCreate       (WndEventArgs& Wea);
long fnWndProc_OnDestroy      (WndEventArgs& Wea);

struct EVENTHANDLER
{
 unsigned int                 iMsg;
 long                         (*fnPtr)(WndEventArgs&);
};

const EVENTHANDLER EventHandler[]=
{
 {WM_CREATE,                  fnWndProc_OnCreate},
 {WM_DESTROY,                 fnWndProc_OnDestroy}
};
#endif 

// Main.cpp
// cl Main.cpp libctiny.lib Kernel32.lib User32.lib Gdi32.lib /MT /O1 /FeForm1.exe   
#include <windows.h>
#include <tchar.h>
#include "AggressiveOptimize.h"
#include "Form4.h"


long fnWndProc_OnCreate(WndEventArgs& Wea)
{
 Wea.hIns=((LPCREATESTRUCT)Wea.lParam)->hInstance;
 return 0;
}


long fnWndProc_OnDestroy(WndEventArgs& Wea)
{
 PostQuitMessage(0);
 return 0;
}



LRESULT CALLBACK fnWndProc(HWND hwnd, unsigned int msg, WPARAM wParam, LPARAM lParam)
{
 WndEventArgs Wea;

 for(unsigned int i=0; i<dim(EventHandler); i++)
 {
     if(EventHandler[i].iMsg==msg)
     {
        Wea.hWnd=hwnd, Wea.lParam=lParam, Wea.wParam=wParam;
        return (*EventHandler[i].fnPtr)(Wea);
     }
 }

 return (DefWindowProc(hwnd, msg, wParam, lParam));
}


int WINAPI WinMain(HINSTANCE hIns, HINSTANCE hPrevIns, LPSTR lpszArgument, int iShow)
{
 TCHAR szClassName[]=_T("Form4");
 WNDCLASSEX wc;
 MSG messages;
 HWND hWnd;

 wc.lpszClassName=szClassName;                wc.lpfnWndProc=fnWndProc;
 wc.cbSize=sizeof (WNDCLASSEX);               wc.style=CS_BYTEALIGNCLIENT|CS_BYTEALIGNWINDOW;
 wc.hIcon=LoadIcon(NULL,IDI_APPLICATION);     wc.hInstance=hIns;
 wc.hIconSm=LoadIcon(NULL, IDI_APPLICATION);  wc.hCursor=LoadCursor(NULL,IDC_ARROW);
 wc.hbrBackground=(HBRUSH)COLOR_BTNSHADOW;    wc.cbWndExtra=0;
 wc.lpszMenuName=NULL;                        wc.cbClsExtra=0;
 RegisterClassEx(&wc);
 hWnd=CreateWindowEx(0,szClassName,szClassName,WS_OVERLAPPEDWINDOW,75,75,320,305,HWND_DESKTOP,0,hIns,0);
 ShowWindow(hWnd,iShow);
 while(GetMessage(&messages,NULL,0,0))
 {
    TranslateMessage(&messages);
    DispatchMessage(&messages);
 }

 return messages.wParam;
}

You can find the command line compilation string I used near the top of Main.cpp. Note that my message cracker scheme hardly adds anything to executable size. I redid the above program with the typical switch but it didn't affect anything. If you are interested in this work let me know and I'll help.