Template specialisation

September 4th, 2014

Introduction

Welcome back to the wonderful world of templates.

So far, we have looked at what are known as base templates. In this article we’re going to look at one of the more confusing aspects of templates – specialisation. The choice of the word specialisation is unfortunate, as many confuse it with inheritance and sub-typing; in this case specialised means “more specific”.

Read more »

Templates of templates

August 21st, 2014

Introduction

In this brief article we’ll have a look at the topic of building template classes whose parameters are themselves templates.

I’m assuming you’re reasonably familiar with template classes.  If not, here’s a quick introduction.

Read more »

Variadic templates

August 7th, 2014

Introduction

In this article we’re going to look at a new feature of templates in C++11 – the concept of the variadic template.

Variadic templates allow us to create functions and classes, not only with generic types, but also a variable number of generic types.

Read more »

Template member functions

July 24th, 2014

Introduction

Previously we’ve looked at template functions and we’ve looked at template classes. This time, let’s look at what happens when you combine them.

Read more »

Templates and polymorphism

July 10th, 2014

Introduction

Template functions and classes tend to cause consternation amongst programmers. The conversation tends to go something like this:

  • I understand the syntax of templates (although it’s ugly)
  • I get the idea of replacing function-like macros with template functions
  • I can see the application of template classes for containers
  • Most containers and generic functions are library code
  • I don’t write libraries
  • What’s the point of me using templates?

In this article we’re going to look at an application of templates beyond writing library code – replacing run-time polymorphism (interfaces) with compile-time polymorphism. This idea is known as a Policy. The idea is reminiscent of the Strategy Pattern, but uses templates rather than interfaces.

Read more »

Template inheritance

June 19th, 2014

Introduction

Previously we looked at template class syntax and semantics. In this article we’ll extend this to look at inheritance of template classes.

Read more »

Template classes

June 12th, 2014

Introduction

Last time we looked at template functions, which introduced the concept of generic programming in C++.

This time let’s extend the idea of generic programming to classes.

Read more »

An introduction to C++ templates

May 29th, 2014

Introduction

Templates are a very powerful – but often very confusing – mechanism within C++. However, approached in stages, templates can be readily understood (despite their heinous syntax).

The aim of this series of articles is to guide beginners through the syntax and semantics of the foundation concepts in C++ template programming.

Read more »

Static and Dynamic Libraries on Linux

April 4th, 2014

A Quickstart Guide

We’re going to look at how to create and use libraries on Linux and try to gain some insight on how libraries work behind the scenes.

Decisions Decisions!

Often when working with 3rd party code you may be limited on the options available. Some well known open-source projects have dual-licensed binaries that dictate different terms for static or dynamic linking.

Writing a library is a good way to provide an interface to customers, get code reuse and can be a major source of headaches!. To understand what’s best for your usecase it’s worth looking at what each type provides.
Static libraries (.a files) are precompiled object code which is linked into other executables at compile time and become part of that final application. These libraries load quickly, have less indirection and don’t run the risk of dependency hell which can beset their dynamic peers.

Library
Read more »

Rapid Application Development with Python

March 11th, 2014

Following on from my previous post on Python and our new course on Python for Test Engineers which takes an elementary approach, I felt it was time to pay homage to that wonderful language once again but this time focusing on its applicability for Rapid Application Development.

The Higher Level the Language; The More Productive the Programmer

I love writing Python. I’ll be honest, it’s the closest I’ll get to writing executable pseudo-code which best mirrors how my mind works and I’m sure I can’t be alone in this. When coding in Python, its dynamic nature means you can sculpt and remodel your code as you express your ideas; this process gives a better understanding of the codes impact as well as providing more accurate estimates for how long a given task will take as there are fewer unknowns in the language itself.

“But Python is for high level applications!” – sorry but the world of embedded is evolving, Embedded Linux is everywhere with its “everything is a file” interface for things that were predominantly the domain of device drivers – I can manipulate framebuffers, SPI and I2C busses and GPIO using Python and even microcontrollers, that last bastion of embedded, are getting in on the action with the recently Kickstarted Micropython which brings Python further into traditional “deeply embedded” territory.

Python as a System Programming Language

An argument I get from other developers is that Python isn’t a real systems programming language – yes, you can script in it but that’s not how “Real coders” write software. Well, when those real Scotsmen, uh, coders take time from etching ones and zeroes directly into their hard disc platters and explain what they mean it typically comes down to a misunderstanding of Pythons capabilities.

“I need threading”

Cool, we’ve got you covered but was that plain threading, process-based threading or maybe just a few recurrent timers?

“Uh, swell, but I also need IPC/Networking”

Sockets, Signals etc? Pick one, pick all of them? Maybe you just need to serialise some data?

“I also need serial comms”

OK, not built in but how about the cross-platform PySerial?

“And what about my existing programs?”

Nice, did you want to extend Python by wrapping your code in a library? Interacting with your program? Or why not embed Python into your existing program?

Python can handle all of those things with aplomb and also affords you ready-to-roll web services, file handling, parsing of data in XML/JSON form or plain text using regular expressions. Maybe you want to interact with the latest pluggable devices using PyUSB and you’ll lose track of the many ways to show a Graphical User Interface that it’s more akin to a beauty pageant.

As we move forward, multimedia is increasingly a key part in product development, many devices need to push and manipulate video and sound and once again, Python provides a huge leg up whether via simple graphics manipulation using Pillow, image processing using scikit-image or even live and post-processing of video using gstreamer or MoviePy respectively.

Mmm, a delicious cinemagraph that’s generatable in ~3 lines of Python with MoviePy

Reducing Time to Market

Time to market is the phrase that pays in the world of product development – it defines our coding deadlines, the features we can ship with and the very nature of our products and we’re always under pressure to reduce it.
Research indicates [1] that designing and writing a program in Python (or similar scripting language) typically takes half as long and requires half as much code as an equivalent C or C++ program.

Given that the number of lines we, as programmers, can write in a given time is constant and not dependent on the language or its type we can infer that with a higher level language such as Python, we get a much higher instructions-per-line metric and developers only have to spend half as long coding as our C++ wielding brethren. I can be more productive than if I was using C++ safe in the knowledge that the same task will require less code in Python.

This is how we get our minimum viable product, this is how we crush our time to market – we code smarter, not harder.

Of Data Types and Paradigms

Data types are important as they define the information we can hold in a variable. Built-in types are a godsend in Python – we have lists, dictionaries, sets and many more and we don’t need to track down and incorporate 3rd party libraries to provide neither them, nor the functions to manipulate them.

This ability to develop as you prototype means that you can develop supporting routines as you go and so to do the types of data you will need to handle which means you can pivot and rearchitect as you develop your software.

Python is a multi-paradigm language (urgh, sorry!) that allows us as programmers to use procedural, object-oriented and functional where it makes sense without shoe-horning one into the other.

One thing that has been on the increase is that Python is entering into areas traditionally aligned with domain specific tools such as Matlab and similar but as the power of Python is becoming apparent, modelling in one language and porting it to something like C is losing out to the decision to model, develop and code in just one language.

Add-on Libraries such as NumPy, SciPy and many others allow a combined model of modelling and deployment that affords huge benefits in a multi-disciplinary team as everyone speaks the same language: Python.

Good enough is good enough

Python isn’t just a prototyping language – you don’t need to throw away any of your code, companies are readily using Python for their deployed products as they evolve from RAD ideas to fully-fledged, production ready programs.

Python may not be everyone’s cup of tea and it has its limitations – it’s never going to offer the performance per watt you’d get from hand-coded assembly – but more often than not it’s good enough to get to market and, as companies are finding out, it’s good enough to keep you in the market.

Inquire today about how we can help you kick start your development process with Python.

[1] http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf

%d bloggers like this: