My motivation to start this blog mainly was to have a memory hook for myself.
I'm experiencing to investigate repeatedly on the same problems multiple times in slightly different contexts, when these appear in e.g. new project setup cycles.
May be my markers might also be helpful for other software developers ...


I have a dream ...

I'm dreaming of so called C++ courses/classes/curriculae will stop teaching (requiring) their students to use:

  • char arrays to build up data structures containing C-style strings, instead of using std::string
  • Raw multiple dimensional arrays like T matrix[Row][Col];
  • new / new[] and delete / delete[], instead of teaching how to use RAII correctly, or just use the features available from the C++ standard libraries, like the available data Containers, or at least from Dynamic Memory Management
  • ancient compilers like Turbo C++, or Borland C++ Builder, which are outdated for any C++ standard, that are actually in use (seems to be broadly applying for e.g. India)

May be I'll have even more points in future, but these are my foremost ones.

Teachers lacking competence, just make the world of C++ programming worse, and all of us professionals will have to deal with junior engineers, that had bad ideas implanted to their brains.

If any student hits this post, and is feeling the same, just point your teacher/lecturer/professor here, and let them argue with me. I'm pretty sure I can convince them, that it's way too costly to act like this in the long term for any educational system.
For nations that are trying to play a significant role in the software development industry, we should expect that they are equipped with the most actual knowdlege about the programming language.


C++11 simple lambda predicate syntax sample

I have done a simple sample how to use a C++11 lambda expression as predicate for a particular algorithm.

pred1 demonstrates the result type of a lambda expression is a function pointer.
pred2 demonstrates how to shorten the lengthy type declaration.


Conditional type selection using C++ template specializations

One of the very basic techniques of C++ meta-programming is to provide simple selector classes that provide to refer to a type from a (public) typedef member.

The basic pattern for type selections based on a condition applied to the template parameters passed, or even independently looks like the following code demonstrates:

A compiled and running example of the above code can be found here.


Building GCC ARM cross toolchain on Suse Linux

I needed to have a GCC 4.7.1 toolchain for ARM (Cortex-M3) with the C++11 standard features.
So I tried following another blog post to compile the toolchain myself. Though, modifications were necessary, here's what to do step by step:

1. Ensure to have the necessary headers & libraries installed
I have used YAST's 'Install Software' feature, to install the following packages that will be necessary to complete all the build steps (just search for the package names, select and accept):
  • gmp-devel
  • mpfr-devel
  • mpc-devel
  • texinfo
  • ncurses-devel
  • termcap

2. Create a directory skeleton

    cd ~
    mkdir arm-none-eabi arm-none-eabi-src
    cd arm-none-eabi
    mkdir src build
    cd ~/arm-none-eabi-src
    mkdir src build

3. Download the the source packages and extract them

    cd ~/arm-none-eabi-src/src


    tar -xf gcc-4.7.1.tar.bz2
    tar -xf binutils-2.22.tar.bz2
    tar -xf gdb-7.4.tar.bz2
    tar -xf newlib-1.20.0.tar.gz

4. Build the binutils

    cd ~/arm-none-eabi-src/build
    mkdir binutils-2.22
    cd binutils-2.22
    ../../src/binutils-2.22/configure \
      --target=arm-none-eabi \
      --prefix=$HOME/arm-none-eabi \
      --with-cpu=cortex-m3 \
      --with-no-thumb-interwork \
    make all install
    export PATH="$PATH:$HOME/arm-none-eabi/bin"

5. Build GCC (Part1)

    cd ~/arm-none-eabi-src/build
    mkdir gcc-4.7.1
    cd gcc-4.7.1
    ../../src/gcc-4.7.1/configure --target=arm-none-eabi \
      --prefix=$HOME/arm-none-eabi --with-cpu=cortex-m3 \
      --with-mode=thumb --disable-multilib \
      --with-no-thumb-interwork \
      --enable-languages="c,c++" --with-newlib \
    make all-gcc install-gcc

The --enable-cxx-flags configure option might be additionally used to control the build flags of the libstdc++ (included in this step):

    --enable-cxx-flags='-fno-exceptions \
        -ffunction-sections -fno-omit-frame-pointer'

In general the same C++ compile flags should be used as they'll appear when building the intended target code.

6. Build GCC newlib with the cross compiler (Part2)

    cd ~/arm-none-eabi-src/build
    mkdir newlib-1.20.0
    cd newlib-1.20.0
    ../../src/newlib-1.20.0/configure --target=arm-none-eabi \
      --prefix=$HOME/arm-none-eabi --disable-multilib \
    make all install
A note about the --disable-newlib-supplied-syscalls option:
Disabling the default newlib syscall stub implementation is generally a good idea when you intend to compile for targets without using a linux like operating system, or no OS at all. It will leave you with linker errors on unimplemented stub functions you'll need to provide for newlib.
Removing the option will still enable you to override the newlib provided stubs with your own implementations.

Though, when you plan to use the cross-toolchain in conjunction with CMake, you should omit this option. CMake does some basic tests using the specified compiler definitions (e.g. from a toolchain.cmake file), that'll fail without the default stub implementations supplied.

7. Complete installing GCC

    cd ~/arm-none-eabi-src/build/gcc-4.7.1
    make all install

8. Build GDB

    cd ~/arm-none-eabi-src/build
    mkdir gdb-7.4
    cd gdb-7.4
    ../../src/gdb-7.4/configure --target=arm-none-eabi \
    make all install

The same works pretty well for GCC 4.8.2 also.