auto overused

I had recently read on an article on a programming subject not related to C++11 but which uses C++11 constructs to explain the point. It is nice to see that C++11 is being adopted this way. However one thing that scared me was the overuse of auto keyword.

const auto MAXSIZE = 10000;

for (auto i = 0; i < MAXSIZE; ++i)
{
...
}

This chills me to the bone. Why not use int or size_t? Of course this simple code doesn't show the complete threat that is the overuse of auto. But this introduces a culture where is OK to use auto everywhere.

My feeling about auto is that it is a tool best fitted for generic programming or where writing the type is difficult, complicated or impossible. Compare this:

std::vector<int> v;

for (std::vector<int>::const_iterator it = v.begin(); it = v.end(); ++v)
{}

with the better:

std::vector<int> v;

for (auto it = v.begin(); it != v.end(); ++v)
{}

but this is even better and clearer:

std::vector<int> v;

for (int &i : v)
{}

Excessive use of auto can lead code that is hard to read and to maintain. Maintenance is all about code reading. Please take care.

Why another XML parsing library?

Some may have noted that in the December 2012 release of my MinGW Distribution I have included yet another XML parsing library: pugixml. Why this if it already has libxml2?

Well, while libxml2 is a complete, standard-compliant XML parsing library it lacks a DOM interface. With DOM it is easier to handle and to walk through the XML representation.

I have evaluated many simple to use, fast libraries: RapidXML, FastXML, AsmXML. And, of course pugixml. However pugixml is fast, has a good documentation and a DOM-like, modern interface that fits well with STL and C++11 ranged-for and lambdas. That was I was looking for.

MinGW Distro - December 2012 Release

Some people have reported that my website is down. Unfortunately depending where in the world you are the site is accessible or not. I'm investigating this issue with my hosting provider. Because of this issue and to ease the release process, this and next releases will be published here, in this blog in addition to the website.

MinGW Distro - December 2012 Release

Updates: binutils 2.23.1, Boost 1.52.0, PNG 1.5.13, TIFF 4.0.3, cURL 7.28.1, GraphicsMagick 1.3.17, POCO 1.4.5, SQLite 3.7.14.1.
New: pugixml 1.2

MinGW-Distro.exe - 43 Mb - Full
SHA1: 92d09d316c17da21c1607ba0938f260b67c8b8b8

MinGW-Distro-Core.exe - 16 Mb - Core Components
SHA1: b3ad4e5e587c915b25acbabd1fdfa0edda69d93f

Building OpenSSL applications

An user has reported problems building an application that use OpenSSL libraries supplied with my MinGW Distro. While he didn't provide further details I think his problem was related to some missing library dependencies.
Any application using OpenSSL has to link with (in this order): ssl, crypto, ws2_32 and gdi32. ssl and crypto are the OpenSSL libraries themselves. ws2_32 is the import library for the Winsock DLL WS2_32.DLL and gdi32 is the import library for GDI32.DLL. The latter is needed because, on Microsoft Windows, OpenSSL uses windows events (eg, mouse movements) as an entropy source.
If you are using a IDE (like Codelite or Code::Blocks) make sure to add those libraries to the project settings.

DLLs for ICU and SDL

I have released last week the October 2012 edition of my MinGW Distro. Also available are a number of add-on libraries built with it. This time I also included in both ICU and SDL packages DLL versions of the libraries.
For ICU the reason is to minimize the size of generated binaries. ICU has a data library that contains charset and localization information. Statically linking the data library makes the programs too big. And if you have many programs this just makes things worse. Now you can dynamic link with the data library (and of course with the other ICU libraries) easing the deployment of your applications.
SDL is relased under LGPL license that imposes restrictions on how to distribute your application. Basically: according to LGPL you have to distribute the source code of your application if you (statically) link with the library. Dynamic link does not impose this restriction.

Exceptions and Destructors: The Saga Continues

Still on the subject of exceptions and destructors, I wondered what is the behavior when using threads. Note that exceptions do not propagate across threads, so catching exceptions in your main thread is not enough. You also have to catch in each and every thread.
Let's take the sample from the original article and introduce threads with a little help of Boost:

#include <iostream>
#include <stdexcept>
#include <boost/thread.hpp>

struct A {
  A () { std::cout << "A\n"; }
  ~A () { std::cout << "~A\n"; }
};

void myfunc() {
  A temp;
  throw std::runtime_error("moo");
}

void mythread() {
  myfunc();
}

int main() {
  try {
    boost::thread t(mythread);
    t.join();
  }
  catch (...) {
  }
}

This still will not call the destructor unless you catch in the thread:

void mythread() {
  try {
    myfunc();
  }
  catch (...) {
  }
}

So, it is a good practice to have a catch clause for all your threads.

With Visual C++ 11 and Gnu C++ 4.7.1 (with --std=c++11 option) std::thread class you don't need the catch clause to get the destructor called. I couldn't find if this is standard or a side effect of the implementation of std::thread on C++ standard libraries for those compilers.

GCC macros for portable development

While GCC define a large number of macros only some of them are useful for portable development. The use of pre-processor macros is a well-known technique for selecting which portions of your code can only be compiled on a specific platform.

The most interesting macros are:

• __GNUC__: always defined for GCC
• __GNUG__: always defined for G++
• WIN32: defined on Windows only

This code:

#ifdef __GNUC__
  #ifdef WIN32
    std::cout << "GCC on Windows\n";
  #else
    std::cout << "GCC not on Windows\n";
  #endif
#endif

Outputs:

GCC on Windows

when built with MinGW on Windows and

Outputs:

GCC not on Windows

when built with GCC in other platforms.

Alternatively with MinGW you can also use __MINGW32_VERSION which is defined if _mingw.h is directly or indirectly (e.g. by including any standard header file) included.

Unexpected skip of a destructor

This is so important I feel obligated to share. If you program C++ for a living please read: http://efesx.com/2012/07/31/unexpected-skip-of-a-destructor/

Why the MinGW Distro? Some interesting background

In 2011 the new C++ standard was about to be released. I then challenged myself to study it, if not the entire beast at least the most interesting parts. This of course demanded a compiler with the latest features of the new standard. At that time the only compiler available that was being updated frequently was GCC. But while it was released very often the MinGW port was not so fast. So, I realized that the best way was to build it myself. A fast search and I found Stephan T. Lavavej's build. It has everything I needed and more. OK. But I don't need all that more so I took his distro, removed some things, added others. And why not release it for others? Then it evolved from a small packaged archive with instructions on how to setup it to a simple, easy-to-use installer. I had already some experience with InnoSetup and it was simple to build an setup package.
And now we are here. Do you have any comments or suggestions to the distro? Things you'd like to see? Please let me know. While I have limited time and resources to play with it I promise to kindly evaluate any request.
Visit the MinGW Distro homepage to download the latest version.