We created a simple Makefile in the previous section. Let's explore the GNU Make utility's behavior and the syntax of Makefile in more detail.

You can run the GNU Make utility from the command shell with the make command. It will search one of the Makefile, GNUmakefile, or makefile named files and start to build the first line target. For changing this behavior, type the following command:

$ make -f OtherMakefile other_target

This leads to reading OtherMakefile as input file of rules and executing commands to build other_target.

In the previous section we created the following Makefile:

win32-app.exe: main.cpp resource.rc.res.o
  g++ -o win32-app.exe main.cpp resource.rc.res.o

resource.rc.res.o: resource.rc
  windres -o resource.rc.res.o -i resource.rc

clean:
  rm -f *.o win32-app.exe

This works, but it has some problems. First of all the main.cpp and resource.rc.res.o files are specified several times. You must rename these in several places if one of these has been changed. This violates one of the most important principles of software development, Don't repeat yourself (DRY). Variables can help you to avoid this problem. The GNU Make variables are often used to save constant values and change behavior during the build process. Our Makefile with variables will be as follows:

EXE=win32-app.exe
CPP=main.cpp
RES=resource.rc 

$(EXE): $(CPP) $(RES).res.o
  g++ -o $(EXE) $(CPP) $(RES).res.o

$(RES).res.o: $(RES)
  windres  -o $(RES).res.o -i $(RES)

clean:
  rm -f *.o *.exe

The variable definition contains the name and variable value after the equals sign. You must use the dollar sign before the variable name within parentheses to access its value after the variable definition.

The source, resource, and executable files are defined as variables in our example. Now you should change the variable value in one place only to rename any of these files.

GNU Make allows the user to define variables, but there are several special automatic variables. These variables are computed for each rule that is executed. You can use the $@ variable to specify the previously defined target and the $^ variable to specify all the prerequisites of this target. After doing all this Makefile will look as follows:

CPP=main.cpp
RES=resource.rc

win32-app.exe: $(CPP) $(RES).res.o
  g++ -o $@ $^

$(RES).res.o: $(RES)
  windres -o $@ -i $^

clean:
  rm -f *.o *.exe

The automatic variables can be used just like the user-defined ones. Now output files of g++ and the windres command are declared with the $@ variable and source files with the $^ one.

Suppose you want to link your application with a third-party library. The library is supplied with the header file and a dynamic-link or static-link library. You must inform the compiler about these files' paths and the library to link with. The simplest way to do it is using the GNU Make environment variables.

An environment variable is a variable that comes from the command shell in which GNU Make runs. There are several predefined environment variables with standard names. You can add custom environment variables from your command shell, but the most common practice is to operate with the standard one in Makefile. Environment variables affect target producing commands in Makefile (for example, additional compiler options are usually passed through environment variables).

The following Makefile is a linking example with the static-link boost program options library (the file path of the library is C:\MinGW\lib\libboost_program_options.a):

OBJ=main.o options.o
RES=resource.rc

CXXFLAGS+=-IC:\MinGW\include
LIBS+=-LC:\MinGW\lib -lboost_program_options

win32-app.exe: $(OBJ) $(RES).res.o
  g++ -o $@ $^ $(LIBS)

$(RES).res.o: $(RES)
  windres -o $@ -i $^

clean:
  rm -f *.o *.exe

CXXFLAGS is a predefined environment variable that contains command line options for the C++ compiler. This variable can be used to specify the paths of additional header files required for source compilation. Paths to headers are specified there with the -I prefix. You can specify several paths separated by a space as follows:

CXXFLAGS+=-IC:\first_include_path -IC:\second_include_path

LIBS is a simple variable with a list of static-link libraries to link with. This variable is passed to the C++ compiler explicitly in the win32-app.exe target producing rule. Libraries to link are specified with the -l prefix, and without the first three letters (lib), as well as the suffix (.a). The full path to linked libraries must be specified too with the -L prefix.

The following command is used to print all the predefined GNU Make environment variables:

$ make -p

Notice that the additional options.cpp source file has been added to the project in this example. Also the CPP variable has been renamed to OBJ and contains object files list now. GNU Make will compile object files from source files automatically if they have same names (for example, main.o and main.cpp).

The following Makefile is a linking example with a dynamic-link zlib library (the file path of the library is C:\MinGW\git\bin\libz.dll):

OBJ=main.o
RES=resource.rc

CXXFLAGS+=-IC:\MinGW\include
LIBS+=-LC:\MinGW\git\bin –lz

win32-app.exe: $(OBJ) $(RES).res.o
  $(CXX) -o $@ $^ $(LIBS)

$(RES).res.o: $(RES)
  windres -o $@ -i $^

clean:
  rm -f *.o *.exe

Dynamic-link libraries are described in the LIBS variable by the same rules as for static-link libraries.

CXX is an environment variable with the C++ compiler's application name. This is equal to g++ by default.

You can call the GNU Make utility for the Makefile subdirectory's processing. This is an example of the root project directory, Makefile, that performs the GNU Make utility for subdirectories (foo and bar):

SUBDIRS = foo bar

.PHONY: subdirs $(SUBDIRS)

subdirs: $(SUBDIRS)

$(SUBDIRS):
  $(MAKE) -C $@

The .PHONY rule is a special rule. It is used to specify the fact that the target is not a file. This is required in our case because subdirectories always exist and the GNU Make will not rebuild targets whose files already exist. MAKE is an environment variable with GNU Make application name. This is equal to C:\MinGW\bin\make by default if the installation path of MinGW software is equal to C:\MinGW.

Makefiles can include comments. All lines starting with the # symbol will be considered by GNU Make as comments.

Makefiles can be complex and consists of several separated files. To include external file content in Makefile use include directive, for example:

include Makefile.mingw

GNU Make is a great instrument for compiling small projects with a couple of source files and headers. There are more powerful instruments for building complex applications that consist of several libraries and executables. Some of them are based on the GNU Make utility and produce Makefiles as the output (for example, GNU Autotools and CMake). I strongly recommend you to study and use one of these for your daily projects.

The MinGW compiler behavior is highly dependent on command line options. These options are usually set through GNU Make environment variables. The following is a list of commonly used predefined environment variables:

The following is a list of commonly used MinGW C and C++ compilers' command line options:

You can use MinGW software even if you already have your project developed with Visual C++. The importing process from Visual C++ to MinGW is quite simple. All you need is to remove unusable headers and create Makefiles to compile and link existing C++ sources.

This process will be described in detail in this section by an example application. The application is a simple command-line archiving utility based on the zlib compression library. The boost library is also used for command-line option parsing. The application consists of the core static-link library and the z_pack executable. This separation by library and executable is required for complex project linking example with several modules.

You can see the Visual C++ project structure in the Solution Explorer window in the following screenshot:

First of all, let's look at the source code of the core library. This library contains the implementation of most of the application's functionality. The command-line parsing and compressing mechanisms are implemented here. Each of these mechanisms are encapsulated in a separate class. The Options class implements the command-line options' parsing. The Packer class implements the compressing and decompressing algorithms.

Let's look at the Options class. The following code shows the class declaration in the options.h file:

namespace po = boost::program_options;
class Options
{
public:
    Options(int argc, char* argv[]);

    std::string GetString(std::string option_name);
    po::options_description& GetDescription();
    bool IsUnzip();
    bool IsComplete();

private:
    po::variables_map options_;
    po::options_description description_;
};

The following code shows the constructor definition of the Options class in the options.cpp file:

Options::Options(int argc, char* argv[])
{
    description_.add_options()
        (kHelp.c_str(), "produce help message")
        (kInFile.c_str(), po::value<string>(), "input file name")
        (kOutFile.c_str(), po::value<string>(), "output file name")
        (kUnzip.c_str(), "unzip the archive");

    try
    {
        po::store(po::parse_command_line(argc, argv, description_),
                       options_);
    }
    catch(...)
    {
        cout << GetDescription() << "\n";
        exit(1);
    }
}

The constructor's input parameters are the count of command-line arguments and the vector with arguments' values. First of all the object from the boost library of the options_description class with the description_ name is configured here with the available command-line arguments. This object is a field of the Options class.

All available command-line arguments are defined as global constants of the string type in the options.h file:

static const std::string kHelp = "help";
static const std::string kInFile = "in";
static const std::string kOutFile = "out";
static const std::string kUnzip = "unzip";

These arguments with descriptions are passed to the add_options method of the description_ object to configure it. Now this object stores information about available command-line arguments. After that, arguments passed to the constructor input parameters are parsed and saved to the variables map. This map is an object from the boost library of the variables_map class with the options_ name. This object is a field of the Options class.

The available command-line arguments are printed if any exception occurs in the arguments' parsing operation. The application's termination will be caused with the exit function in this case.

The following code is the GetString method's definition of the Options class in the options.cpp file:

string Options::GetString(string option_name)
{
    if ( options_.count(option_name) == 0 )
        return string();

    return options_[option_name].as<string>();
}

The method returns the specified program option value of the string type or an empty string if the option has not been passed as a command-line argument. I suggest you name command-line arguments as program options after parsing them in the constructor of the Options class.

The following three methods of the Options class are quite simple. These perform a check on the existence of specific program options or return them:

The second class of the core library is Packer. The compressing and decompressing algorithms are implemented here. This class contains the Compress and Decompress static methods. The static class methods may be very helpful to implement algorithms without state and mutable data. You don't need the object of the class to call static methods.

The following code shows the declaration of the class in the packer.h file:

class Packer
{
public:
  static void Compress(std::string in_file, std::string out_file);
  static void Decompress(std::string in_file, std::string out_file);
};

The following code shows the Compress method's definition in the packer.cpp file:

void Packer::Compress(string in_file, string out_file)
{
  io::filtering_ostreambuf out;
  out.push(io::zlib_compressor());
  out.push(io::file_sink(out_file.c_str(), ios::binary));
  io::copy(io::file_source(in_file.c_str(), ios::binary), out);
}

The input parameters of this method are strings with filenames of source and target files.

The compression is performed with the copy function from the boost library that copies one stream content to another. The stream of the file_source class from the boost library is used in this function as input parameter. The copy function produces the object of the filtering_ostreambuf class with the out name as the result. The stream of the file_source class is anonymous and is created from the source filename and stream type. This is the binary type in our case. The out object has been configured by the compression filter of the zlib_compressor type and anonymous stream of the file_sink boost library class. This anonymous stream represents the target file.

After performing the Compress method, the compressed file with the specified target filename will be created.

The following code shows the Decompress method's definition of the Packer class in the packer.cpp file:

void Packer::Decompress(std::string in_file, std::string out_file)
{
  io::filtering_istreambuf in;
  in.push(io::zlib_decompressor());
  in.push(io::file_source(in_file.c_str(), ios::binary));
  io::copy(in, io::file_sink(out_file.c_str(), ios::binary));
}

This method is similar to the Compress method, but the filter of the zlib_decompressor type has been used here. The decompressed file with a specified target filename will be created after this method is performed.

The rest of the core library source files have been automatically generated by Visual C++.

Another solution's project is z_pack. This project binds the core library classes' functionality in to use them in the complete application. The z_pack project consist of one source file with the main function implementation and several autogenerated files by Visual C++.

The following code shows the main function's definition in the z_pack.cpp file:

int main(int argc, char* argv[])
{
    Options options(argc, argv);

    If ( ! options.IsComplete() )
    {
        cout << options.GetDescription() << "\n";
        return 1;
    }

    if ( options.IsUnzip() )
        Packer::Decompress(options.GetString(kInFile), options.GetString(kOutFile));
    else
        Packer::Compress(options.GetString(kInFile), options.GetString(kOutFile));
    return 0;
}

The input parameters of this function are the same as the Options class constructor. These are count of command-line arguments and vectors with argument values. First of all the object of the Options class with the options name is created here. The next operation is checking the source and target filenames for correctness using the IsComplete method of the options object. The available command-line arguments will be printed and the application will be terminated if this checking fails. The specified compression or decompression operation is performed if command-line arguments are correct. The IsUnzip method of the options object defines what kind of operation must be performed. The Compression and Decompression operations perform as per the Packer class static methods.

The input parameters for these methods are available from the GetString method of the Options class execution result.

Full Visual C++ project sources are available in the code bundle uploaded on the Packt website.

You can build this project and check its functionality. The Visual C++ versions of the boost and zlib libraries are required to compile the project. The comfortable distribution of both libraries is available at the following website:

http://www.boostpro.com/download

You can test the functionality of our example application after building one. Type the following command to compress the existing file:

$ z_pack.exe --in test.txt --out test.zip

The following command is used to decompress the existing archive:

$ z_pack.exe --unzip --in test.zip --out test.txt

Now you have the necessary information about our example Visual C++ project to import it to the MinGW software. The following are step-by-step instructions to do this:

This is all you need to import our example Visual C++ project to the MinGW software. You will get the z_pack.exe executable file after building it.

It is quite simple to change the libcore.a static-link library to the dynamic-link variant one. All you need is to change the Makefile files for the z_pack executable and the core library.

The following Makefile will create the dynamic-link core library variant:

OBJ=options.o packer.o

MINGW_DIR=C:\MinGW
CXXFLAGS+=-I$(MINGW_DIR)\include
LIBS+=-L$(MINGW_DIR)\lib -lboost_program_options -lboost_iostreams -L$(MINGW_DIR)\git\bin -lz

libcore.dll: $(OBJ)
  $(CXX) -shared -o $@ $^ $(LIBS)

clean:
  rm -f *.o *.dll

The C++ compiler and linker will be called here unlike the static-link core library variant. Furthermore, the -shared compiler option must be specified to create the dynamic-link library.

The following Makefile is for the z_pack executable to link with the core library dynamically:

OBJ=z_pack.o

CXXFLAGS+=-I..\core
LIBS+=-L..\core -lcore

z_pack.exe: $(OBJ)
  $(CXX) -o $@ $^ $(LIBS)

clean:
  rm -f *.o *.exe *.dll

Linking with external libraries (boost and zlib) is not required here because it has occurred in the core library building.

You must copy the libcore.dll library and the z_pack.exe executable files into one directory to run the application.

It is important to note that libraries, objects, and executable files compiled with Visual C++ and MinGW software are incompatible. This means that you need the MinGW version of all static-link and dynamic-link libraries that you want to link with your application compiled with MinGW software. You must check the existing MinGW version of all third-party libraries that have been used in your project before importing this to MinGW software.

MinGW software contains GNU Debugger (GDB). This is a standard tool to debug applications developed with MinGW software. You can't use GDB to debug projects compiled with the Visual C++ compiler.

You can install GDB manually if it doesn't exist in your MinGW software distribution. Perform the following instructions to do the same:

GDB has been installed correctly if you see the application using information. Now you have the necessary debugger utility to start debugging your MinGW-based application.

Let's debug the example application with GDB. The application is a simple program with anull-pointer assignment.

The following code shows the content of the source file named segfault.cpp:

#include <string.h>

void bar()
{
  int* pointer = NULL;
  *pointer = 10;
}

void foo()
{
  bar();
}

int main()
{
  foo();

  return 0;
}

The null-pointer assignment operation occurs in the bar function. The bar function is called from foo and the foo function is called from the main function.

The following Makefile is to compile the example:

OBJ=segfault.o

CXXFLAGS+=-g

segfault.exe: $(OBJ)
  $(CXX) -o $@ $^

clean:
  rm -f *.o *.exe

The MinGW C++ compiler doesn't include debug information in output binary files by default. We need to add the -g compiler option to do it in this Makefile.

You will get the segfault.exe executable file with debugging symbols after compilation. It means that GDB can inform you not only about memory addresses but also the names of routines and variables.

Type the following command to start debugging our example application:

$ gdb segfault.exe

To start the application with command-line arguments use the --args GDB option. For example:

$ gdb --args z_pack.exe --in test.txt --out test.zip

The input and output filenames will be passed to the z_pack.exe application in this case.

You will see the GDB command prompt after launching the debugger. Type the r command to run the loaded application:

(gdb) r

This is the short variant of the run command. Most of the GDB commands have common and short variants. All future commands will be described with short variants because they are easy to remember and type.

You will see this program crash message after the application starts running, as shown in the following screenshot:

You can see that the program abortion is receiving the SIGSEGV signal by application. The POSIX system sends this signal to process when it makes an invalid virtual memory reference or segmentation fault. Furthermore the source file's line, where the error has occurred, is displayed here. The following is the sixth line of the segfault.cpp file:

*pointer = 10;

Our example program execution has stopped after the crash. You can interact with the debugger through the command line when the program is stopped. For example, you can get the stack backtrace to explore the nested functions' calls. Type the bt command as follows:

(gdb) bt

You will see something like the following screenshot:

You will see called functions' names and source file lines, where these have been called by the program just before it crashed.

Moreover, you can get a list of source file lines in the error place by the l command:

(gdb) l

You will see the bar function source code. Now you have enough information to fix the segmentation fault error.

To quit from GDB type the q command:

(gdb) q

And type y to confirm.

GDB allows you to set breakpoints to stop program execution in a predefined place. There are several breakpoint types. The simplest types are a breakpoint at entry to the function and a breakpoint at a line in a source file. You need to specify the application source files directory to provide access to these for GDB. The command to start the application debugging in this case will look like the following:

$ gdb --directory=. segfault.exe

The --directory command-line option defines the source files directory. The current directory has been added in this example (the current directory equals to point symbol).

All the loaded directories are available by typing the following command:

(gdb) show directories

The following command is used to set a breakpoint at the foo function from the segfault.cpp source file:

(gdb) b segfault.cpp:foo

To set a breakpoint at the fifth line of the segfault.cpp source file type the following command:

(gdb) b segfault.cpp:5

A list with information about all the current defined breakpoints is available by using the following command:

(gdb) i b

You can run our example program after setting breakpoints:

(gdb) r

Program execution will be stopped at the first breakpoint in the foo function after that. You can continue execution by using the c command:

(gdb) c

Type this and the next breakpoint at the fifth line of the segfault.cpp source file will be achieved. The backtrace information and source file lines are available at each breakpoint.

Watchpoint is a special breakpoint type to detect read and write variable operations. This command is used to set a watchpoint for the pointer variable:

(gdb) aw pointer

GDB can set such watchpoints if variables have been defined in the current context. This means that you must stop program execution at the bar function and then set a watchpoint for its local pointer variable. The program can be stopped in the main function to set a watchpoint for any global variable.

Moreover, you can configure GDB to display a list of variables with the current values at each breakpoint hit. To add the pointer variable in this list type the following command:

(gdb) display pointer

The value of the pointer variable will be displayed at the next breakpoint program stop.

You can disable a breakpoint of any type to prevent the program from stopping at it. The following is the command to do it:

(gdb) disable 1

The specified number is a breakpoint identifier. This identifier is declared in the breakpoints information list.

To enable the breakpoint type the following command:

(gdb) enable 1

The breakpoint can be removed if it is no longer needed:

(gdb) d 1

There are several useful commands for tracing a program:

These commands can be used after the program has run and been stopped by breakpoint.

You can rebuild your application without debug information to produce release variants of executable files and libraries. But there is a possibility to remove debug information from existing binary files. Use the strip command as follows:

$ strip segfault.exe

GDB is quite useful to debug abnormal program behavior (segmentation faults, for example). But using the same approaches as the test suite and event logging can complete the GDB capabilities for the algorithms' correctness checking.

MinGW software contains the gprof performance analyzing tool. This instrument can be useful for tracking down an application's bottlenecks. The gprof tool is a part of the GNU Binutils collection and therefore it is present in all MinGW distributions. You can't use gprof to analyze the performance of applications compiled with Visual C++ compiler.

Let's profile an example application with gprof. This application reads bytes from a file to an STL vector type container, sorts them, and writes the result to an output file. The application source code is present in the file named sorting.cpp.

The following is the main function definition:

int main()
{
  ReadData();

  SortData();

  WriteResult();

  return 0;
}

You can see the basic application algorithm in this function. First of all, the data is reading from the input text file. Then the data is sorted and written to the output file. Each of these steps are implemented in the separate function.

The following code shows the ReadData function's definition:

void ReadData()
{
  ifstream in_file("source.txt", ios::in | ios::binary);

  copy(istream_iterator<char>(in_file), istream_iterator<char>(), 
     back_inserter(gData));
}

The stream of the ifstream class with the in_file name is used here to read the source.txt input file content. Then the STL copy algorithm is used to copy the in_file stream content to the global gData container of the vector<char> class. We use the iterator of the istream_iterator class to access elements of the in_file stream in the copy algorithm.

The SortData function implements the simplest bubble sort algorithm:

void SortData()
{
  char temp;
  size_t size = gData.size();
 
  for (int i = (size - 1); i > 0; i--)
  {
    for (int j = 1; j <= i; j++)
    {
    if (gData[j-1] > gData[j])
    {
      temp = gData[j-1];
      gData[j-1] = gData[j];
      gData[j] = temp;
    }
    }
  }
}

This sort algorithm processes the elements of the gData container.

The following is the WriteResult function definition:

void WriteResult()
{
  ofstream out_file("result.txt", ios::out | ios::binary);
  out_file.write(&gData[0], gData.size());
}

The stream of the ofstream class with the out_file name is used here to write the gData container content to the output result.txt file. The write method of the out_file stream is called here to perform the file writing operation. An empty file with the result.txt name will be created to write if this file already exists. The sorting.cpp file is available in the code bundle uploaded on the Packt website.

The following is Makefile for the example application:

OBJ=sorting.o

CXXFLAGS+=-pg

sorting.exe: $(OBJ)
  $(CXX) -o $@ $^ $(CXXFLAGS)

clean:
  rm -f *.o *.exe *.out *.dot

Profiling information is needed for performance analyzing. This information can be generated by an executable file's extra code. The same kind of extra code creation is an optional feature of the compiler and this feature can be specified by the compiler -pg option. This option must be specified for each object file compilation and final linking. The CXXFLAGS environment variable is used to do this in our Makefile.

You can test our example application after compilation. Just copy any plain text file to project directory with, name it source.txt, and run the sorting.exe executable file. You will get the result.txt file with the sorted source file content after the application finishes its work. Perform the following steps to profile our example application:

These gprof utility options have been used in the preceding:

You have got a text report with the profiling data in the profile.txt file. It can be opened in any text editor. But this text representation of the profiling information is not comfortable to discovery. There are handy tools for visualizing a gprof report.

For visualization we need the following tools:

You can download Python version 2.7 from the following official website:

http://python.org/download

Python can be installed with the standard Windows Installer. To do this just run the downloaded MSI file.

The script to convert a gprof report text file to dot format is available on the following developer page:

http://code.google.com/p/jrfonseca/wiki/Gprof2Dot

This script is a free software and you can use, distribute, and modify it as you want. To install this script copy it to C:\MinGW\bin or C:\MinGW\git\bin.

The Graphviz package is available at the following official website:

http://www.graphviz.org/Download_windows.php

Graphviz can be installed with Windows Installer in the same way as Python interpreter.

Now you have the necessary scripts and the visualization utility to visualize our profiling results. Perform the following steps to do this:

You will see a call-graph of the program as shown in the following screenshot:

You can see a call-graph in the preceding screenshot. Nodes of this graph are represented as colored edges. These nodes represent called functions of the analyzing program. Each edge contains the following information:

Moreover, nodes have temperature-like colors according to the total time percent value. Most time expensive functions display as red (hot-spot) edges and the most cheap ones as dark blue.

The most execution time of our example application has been spent in the red colored SortData function. Statistic information about the SortData function at graph confirms it:

We can use the STL sort algorithm instead of the bubble one to optimize our example application. Let's change the code of the SortData function as follows:

void SortData()
{
  sort(gData.begin(), gData.end());
}

Now you need to rebuild the application, run the application, and run gprof and the gprof2dot.py script. Open the resulting dot file in the Graphviz application. You will see the call-graph as shown in the following screenshot:

The red edges disappear from the graph. This means that we don't have any explicit bottleneck. All program execution time has been evenly distributed between several functions.

You can remove the profiling extra code from executable files and libraries after profiling with the strip command:

$ strip sorting.exe

Profiling is a significant technique that allows you to find and remove bottlenecks in your applications. This may be very helpful for performance analyzing of the complex systems with many components and libraries. MinGW software allows you to include this technique in your software development process in a simple and fast manner.

MinGW software allows you to develop applications based on any library compiled with the MinGW C++ compiler. Open source libraries are often supplied in Visual C++ and MinGW compilation variants. Moreover, you can always get the source code of these libraries and build them with your MinGW software. Several well-known open source cross-platform frameworks and toolkits are described as follows:

The same functionality example application will be developed with each of these libraries. The goal of these examples is to show the first steps to deploy and to start working with these libraries.

Our example application consists of a window with two buttons. A click on the first button leads to the display of a message and a click on the second button leads to the application termination. This functionality is the same as the one described in the Quick start section.

int main(int argc, char* argv[])
{
  QApplication application(argc, argv);
  
  QMainWindow* window = CreateWindow();

  CreateMsgButton(window);

  CreateQuitButton(window, application);
  
  return application.exec();
}

QMainWindow* CreateWindow()
{
  QMainWindow* window = new QMainWindow(0, Qt::Window);
  
  window->resize(250, 150);
  window->setWindowTitle("Qt Application");
  window->show();

  return window;
}

void CreateMsgButton(QMainWindow* window)
{
  QMessageBox* message = new QMessageBox(window);
  message->setText("Message text");
  
  QPushButton* button = new QPushButton("Message", window);
  button->move(85, 40);
  button->resize(80, 25);
  button->show();
  QObject::connect(button, SIGNAL(released()), message, SLOT(exec()));
}

void CreateQuitButton(QMainWindow* window, QApplication& application)
{
  QPushButton* quit_button = new QPushButton("Quit", window);
  quit_button->move(85, 85);
  quit_button->resize(80, 25);
  quit_button->show();
  QObject::connect(quit_button, SIGNAL(released()), &application, SLOT(quit()));
}

$ mingw32-make release

int main(int argc, char* argv[])
{
  gtk_init(&argc, &argv);

  GtkWidget* window = CreateWindow();

  GtkWidget* box = gtk_vbox_new(FALSE, 0);
  gtk_widget_show(box);

  CreateMsgButton(box);

  CreateQuitButton(box);

  gtk_container_add(GTK_CONTAINER(window), box);
  gtk_widget_show(window);
  gtk_main();

  return 0;
}

GtkWidget* CreateWindow()
{
  GtkWidget* window = gtk_window_new(GTK_WINDOW_TOPLEVEL);

  gtk_window_set_title(GTK_WINDOW(window), "Gtk+ Application");
  g_signal_connect(window, "delete-event",                           G_CALLBACK(gtk_main_quit), NULL);
  g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit),               NULL);

  return window;
}

void CreateMsgButton(GtkWidget* box)
{
  GtkWidget* button = gtk_button_new_with_label("Message"); 
  gtk_widget_show(button);	
  g_signal_connect(G_OBJECT(button), "clicked",
                     G_CALLBACK(ShowMessage), NULL);
  gtk_container_add(GTK_CONTAINER(box), button);
}

void ShowMessage(GtkWidget* widget, gpointer data)
{
  GtkWidget* message = gtk_message_dialog_new((GtkWindow*)data, GTK_DIALOG_MODAL, GTK_MESSAGE_INFO, GTK_BUTTONS_OK, "Message text");
  gtk_dialog_run(GTK_DIALOG(message));
  gtk_widget_destroy(message);
}

void CreateQuitButton(GtkWidget* box)
{
  GtkWidget* button = gtk_button_new_with_label("Quit"); 
  gtk_widget_show(button);	
  g_signal_connect(G_OBJECT(button), "clicked",
                     G_CALLBACK(gtk_main_quit), NULL);
  gtk_container_add(GTK_CONTAINER(box), button);
}

OBJ=main.o

CXXFLAGS+='pkg-config --cflags gtk+-win32-2.0'
LIBS+='pkg-config --libs gtk+-win32-2.0'

gtk.exe: $(OBJ)
  $(CXX) -o $@ $^ $(LIBS)

clean:
  rm -f *.o *.exe

class MyApp : public wxApp
{
public:
  virtual ~MyApp() {}

private:
  virtual bool OnInit();
};

bool MyApp::OnInit()
{
  MyDialog* dialog = new MyDialog(NULL, 0, _("wxWidgets application"));

  wxSizer* sizer = dialog->CreateButtonSizer(wxOK | wxCANCEL);
  sizer->SetDimension(175, 50, 100, 100);

    while ( dialog->ShowModal() == wxID_OK )
    {
      wxMessageBox(_("Message text"), 
                    _("Information"),
                    wxOK | wxICON_INFORMATION, dialog);
  }

  dialog->Destroy();
  return true;
}

class MyDialog : public wxDialog
{
public:
  MyDialog(wxWindow* parent, wxWindowID id,
              const wxString& title) : wxDialog(parent, id, title) {}
  virtual ~MyDialog() {}
};

IMPLEMENT_APP(MyApp)

OBJ=main.o

CXXFLAGS+='wx-config --cxxflags --wxcfg=gcc_dll/mswu'
LIBS+='wx-config --libs --wxcfg=gcc_dll/mswu'

wxwidgets.exe: $(OBJ)
  $(CXX) -o $@ $^ $(LIBS)

clean:
  rm -f *.o *.exe

MinGW software can be integrated with a lot of well-known free IDE systems. Integration with the following systems will be described here:

Integration in this case means the ability to edit MinGW-based project source code, building this project, and debugging it from the IDE. This integration provides a comfortable interface to interact with the most commonly used MinGW instruments.

Eclipse

Eclipse is a cross-platform open source IDE with multi-language support. There are a huge amount of plugins that have been developed for this IDE. Eclipse supports many compilers, interpreters, debuggers, version control systems, unit testing frameworks, and so on. You can use Eclipse for developing applications in any popular programming language and framework.

Eclipse is an excellent IDE for comfortable application developing, but it has been developed in Java and has a massive architecture. Therefore there are high demands on the performance of your computer.

This is not the Eclipse IDE system distribution that contains the MinGW software. You must install it separately to integrate with Eclipse.

The following are instructions to install and configure the Eclipse IDE system:

1. Download Java Runtime Environment (JRE) from the official website:

   http://www.oracle.com/technetwork/java/javase/downloads/index.html

2. Install it with the setup wizard. Just run the downloaded exe file to do it.

3. Add the path of the JRE executable files to the PATH Windows environment variable (for example, C:\Program Files\Java\jre7\bin).

4. Download the Eclipse IDE for C/C++ Developers version archive from the official website:

   http://www.eclipse.org/downloads

   Note what you need the 32-bit Eclipse IDE system version for 32-bit JRE and 64-bit one for 64-bit JRE.

5. Unpack the Eclipse archive to any directory (for example, C:\Program Files)

Now you are ready to use the Eclipse IDE system. The MinGW software utilities will be integrated automatically thanks to Windows environment variables. Therefore the MinGW bin subdirectory with executable files must be specified there.

The following are instructions to create an example application in Eclipse IDE:

1. Run Eclipse IDE. You will see the Welcome screen.

2. Select File | New | C++ Project from the main menu. You will see the project configuration dialog as shown in the following screenshot:

   

3. Select the Hello world C++ Project item in the Project type selection field. Select the MinGW GCC item in the Toolchains selection field. Click on the Next button. You will see the Basic Settings dialog. The author, copyright notice, and source files directory can be specified here.

4. Click on the Next button. This is the Select Configurations dialog. Debug, release, or both build configurations availability can be selected here.

5. Click on the Finish button.

After that you get a template C++ console project with the source files placed at the src subdirectory of the project directory. Now you see the Eclipse IDE window as shown in the following screenshot:

The Project Explorer panel is placed at the left-hand side of the window. You can find all the project source files here. The source file editor is placed in the middle part of the window. You can find the messages' output panel at the bottom of the window.

Select Project | Build Project from the main menu to build our example application. After that the executable file will be created in the Debug subdirectory of the project directory. You can switch to the release configuration to build the project. Click on the build icon (hammer icon) at the main menu and select Release configuration to build. The Release subdirectory will be created with the compiled executable file.

Select Run | Run from the main menu or press Ctrl + F11 to launch our example application. You will see the result of the application execution in the console output panel at the bottom of the Eclipse window.

You can debug applications with the Eclipse IDE system. Press Ctrl + Shift + B key to set the breakpoint at the current line of a source file. After setting the breakpoints select Run | Debug from the main menu or press the F11 key to start debugging. You will see panels with call-stack, variable values, CPU registers values, breakpoints, and loaded modules in the debugging mode. Use the Step Over (F6) and Step Into (F5) Run submenu items to continue application execution.