C++ on UberMongoose

How Compilers Work - The Problem of Parsing

Mon, 17 Apr 2017 19:51:43 +0530

Parsing is the second stage of compilation, it comes right after lexical analysis. While lexical analysis focuses on breaking down the input text into a set of tokens, parsing focuses on ensuring that the relationships between those tokens are valid. Lexical analysis is about valid words, parsing is about grammatically correct sentences.

The problem with parsing, is that at this point during most discussions, the text moves headfirst into theory - and there is quite a bit of it. To make matters worse, it’s quite abstract and quite disconnected from much of what comes afterwards (namely parser generation). So instead of going theoretical, let’s jump straight into implementing a parser by hand and then come back to the theory. Let’s take a look at an example of the Cunning language.

How Compilers Work - Lexical Analysis

Thu, 12 Feb 2015 08:20:12 +0530

Compilers are wonderful, if somewhat under appreciated programs. Like the foundations of great buildings, they form the latticework on which modern computing is built. Unfortunately, they have been a bit neglected of late. Writing code tends to be more about innovating and creating exciting new businesses than the actual pleasure of knowing how things work, how to break them and how to fix them again. The modern day queen of compilers, Grace Hopper[1] , started life by taking clocks apart and trying to put them back together.

C++ Constructors and Move Semantics

Sat, 12 Apr 2014 10:12:06 +0530

In order to do almost anything with a class in C++, you need to define a few constructors. If you don’t, depending on usage, the compiler will generate those constructors for you. For example, consider the following code:

class Person
{
public:
    string name;
    int age;
};

The above class does not explicitly define a constructor of any kind and if you don’t use the class at all, the compiler will just ignore it. However on the other hand if you do the following:

CMake Platform Specific Actions

Sun, 22 Dec 2013 10:13:40 +0530

Sometimes you need to link one library on Windows and another on Linux (or vice versa). CMake has a number of variables that allow you to do this easily:


UNIX	TRUE on all UNIX-like OS’s including Apple OS X and CygWin
WIN32	TRUE on Windows including CygWin
APPLE	TRUE on Apple systems. **
MINGW	TRUE when using the MinGW compiler in Windows
MSYS	TRUE when using the MSYS developer environment in Windows
CYGWIN	TRUE on Windows when using the CygWin version of cmake

** Note this does not imply the system is Mac OS X only that APPLE is #defined in C/C++ header files. Obtain more specific system information via CMAKE_SYSTEM_VERSION. I.e. IF(${CMAKE_SYSTEM_NAME} MATCHES “Darwin”) then it’s Mac OS X

CMake find_package

Wed, 04 Dec 2013 10:05:36 +0530

In the last scroll on CMake we discussed adding libraries that you write to your own code. This time, we look at using third party libraries out of the box. This turns out to be fairly easy with CMake - though there are exceptions (alternatively spelled “bugs”). Adding a third party package such as the precious Boost libraries for C++ is fairly easy with CMake. In your CMakeLists.txt file add a call to FIND_PACKAGE like so:

CMake add_library

Mon, 29 Jul 2013 09:57:52 +0530

In the last post we built an executable from a source file and a header only library. However, sometimes we need to build shared library binaries that can be linked into an executable. This is fairly simple with CMake. Instead of using add_executable like the last time we now simply need to use add_library like so:

# Sources 
file(GLOB Library_SOURCES *.cpp)
file(GLOB Library_HEADER *.hpp) 

# Executable
add_library(LibProject ${Library_SOURCES} ${Library_HEADERS})

CMake will now get the build system that you choose to create a shared library that can be linked into an executable one. You would end up with .lib files with Visual Studio and typically .a files with Unix make. Note that the name Library_SOURCES is chosen for clarities sake. The variable can be named anything.

CMake Include Directories

Sat, 20 Jul 2013 11:19:39 +0530

To do almost anything today with C++ requires the use of a number of different third party libraries. Some of these come in the form of header only libraries containing only include files (.h and .hpp). The references to these libraries are easy to resolve with CMake, let’s contrive an example.

Consider the following folder structure.

[CMakeHome] [CMakeHome]\src
Contains all the source code for the project

[CMakeHome]\headerlib\
Contains a small header only library with a number of different applications

CMake The Beautiful Beast

Wed, 17 Jul 2013 09:17:29 +0530

CMake is a mix of things. It’s a cross platform makefile generator that makes porting your C/C++ code from one OS to another or from one compiler to another inside the same OS really simple. However it complicates things a bit as well as now you need to write an extra “CMakeLists.txt” file for each of your code directories in order to allow CMake to generate those files for you. It doesn’t really help that the CMake documentation is rather dense and that there are a number of caveats that you really don’t see until you get to actually implementing it. Learning CMake therefore can be a harrowing experience and sometimes you might be tempted to give up half way and stick to the warm consolation of the Visual Studio IDE. That’s where this guide will hopefully help you as a starting point in your CMake journey that is not too steep to learn.

CMake Trickery - Platform Specific Linking

Wed, 26 Jun 2013 08:52:57 +0530

Quite often when your working on cross platform code you need to build applications that use one set of libraries when compiled under Microsoft Windows and another set when compiled under Unix/Linux. Fortunately CMake is a cunning tool to help you on your way. It has a bunch of predefined constants that you can use to switch libraries based on the platform like so:

# SomeCoolLibrary
IF (WIN32)
   message(STATUS "Building on Microsoft Windows.")
   set (SomeCoolLibrary someCoolWindows.lib)
ELSEIF (UNIX AND NOT MINGW)
   message(STATUS "Building on Linux/Unix.")
   set (SomeCoolLibrary someCoolLinux.so)
ENDIF()

Notice we check for the enviorenment being Unix but not MinGW. This is because CMake reports the enviorenment as Unix even if it’s MinGW running on Windows (which I suppose makes sense), but it pays to be specific. Finally you can target the generic link library that you’ve mentioned here:

Unicode on Linux

Sun, 26 May 2013 14:52:45 +0530

At first the place of Unicode in Linux looks simple. It is deceptively so. Linux C/C++ has support for both char and wchar_t. Let’s take a look at the char version:

#include <cstring>
#include <iostream>
 
int main(int argc, char* argv[])
{
    const char text[] = "Άλφα";
    std::cout << text << std::endl;
    std::cout << "sizeof(char): " << sizeof(char) << std::endl;
    std::cout << "sizeof(text): " << sizeof(text) << std::endl;
}

This results in the output:

Άλφα
sizeof(char): 1
sizeof(text): 9

Notice that the console prints out the characters correctly and that the size of a char is 1 byte. On the other hand the size of the text buffer is 9 bytes, though manifestly it only contains 4 (+1 for the null terminator). The reason for this is that each character is encoded as a couple of UTF-8 characters. This is important. All char buffers in Linux supports Unicode by default because GCC by default encodes literal text as UTF-8 streams. On the down side now some of the old string handling functions – for example strlen – which are not UTF-8 aware start returning bovine excrement as results and require replacement but we will return to that.

The pImpl Idiom – Hiding Private Implementation Details

Thu, 17 Jan 2013 16:16:31 +0530

One key principle behind the design of classes is that of the encapsulation of the implementation from the clients using the code. Here a client is any bit of source code that uses the classes that you write. C++ provides an imperfect implementation of this idea in the way it defines rules for classes. Consider the following class which is declared in event.hpp.

#include "system_clock.hpp"
 
class Event
{
 
private: 
    SystemClock mClock;
    std::string mMessage;
 
public:
    Event(std::string message);
    ~Event();    
};

The Event class models an event that can happen at some point in time. It uses “system_clock.hpp” which defiles a class called SystemClock to see what time it is. Notice that both the message and the current time as defined by the member variable mClock in Event is private. This should mean ideally that any changes to the variables in the private section of the class is not exposed to the client code and indeed to an extent it is. No client can create an instance of Event and then access it’s private members like so:

Unicode and Windows

Tue, 06 Nov 2012 13:46:55 +0530

Unicode string support in Windows is a strange beast.

When Microsoft hired Dave Cutler and others to write a new OS for them they were thinking about writing a new version of OS/2. In fact the new Microsoft OS was a combined effort by Microsoft and IBM that would have resulted in OS/2 version 3.0 if not for the success of Microsoft’s own Windows 3 which made them reconsider that approach. At the eleventh hour they shifted their API from the extended OS/2 API that was to be the way things got done on the new OS to an extended version of the Windows API. This last minute change was possible due to some clever trickery on the part of the programmers who wrote the new Windows OS but it resulted in a strange API, especially when it came to string handling in the new OS known to history as Windows NT 3.1.

Unicode

Fri, 12 Oct 2012 09:32:22 +0530

For many years programmers and strings existed in a state of balance, as much balance as could have been possible under the constant threat of undefined behaviour that sociopathic string functions threatened in any case. It was not to be however for their lives of relative stability was forever changed with the advent of Other Languages into string buffers. In this part of our continual study of strings we delve into intriguing world of internationalisation, multi byte character sets and Unicode.

The Private Lives of Strings

Sat, 15 Sep 2012 16:14:33 +0530

Ah, Strings. Surprisingly simple for most C# and Java programmers yet so complex for those of us left behind in the world of C and C++, Strings are perhaps one of the strangest beasts in the programming landscape. Yet they began so simple, perhaps deceptively so like a chameleon on a plain coloured leaf waiting to deceive the observer with its next background. Yet I have tracked this beast down through the ages, yea, verily I have identified its habits and its lair and here I present to you in true Attenboroughish fashion the Private Life of Strings. To understand the habitat of strings one must go back to their distant ancestors. The typewriters.