Array notation in C is a lie!
Sorry, dear reader*, but I cannot participate in this conspiracy any longer. You have been lied to, manipulated and coerced into thinking arrays are a construct of the C language. I feel it is my solemn duty to blow the whistle on this charade and expose the dirty secrets of C’s so-called arrays.
(* It is statistically possible that more than one person might read this, of course)
This time, we’ll have a more detailed look at one of those everybody-knows-that elements of C++ – virtual destructors.
More specifically, I want to reinforce under what circumstances you should make your destructor virtual; and when you don’t need to (despite what your compiler might say)
(*there’s no death)
Automatic type-deduction is perhaps one of the more divisive features of Modern C++. At its core it’s a straightforward concept: let the compiler deduce the type of an object from its initialiser. Used in the right way this can improve the readability and maintainability of your code.
However, because auto is based on template type-deduction rules there are some subtleties that can catch the unwary programmer.
In this article we’ll have a look at auto in the context of the template type-deduction rules to see where all these subtleties come from.
Posted in C/C++ Programming
Tagged auto, C++, C++0x, C++11, C++1y, l-value, l-value references, r-value, r-value references, reference collapsing, type deduction
It’s hard to believe another year has passed and it’s time once again for the Embedded Linux Conference, and next week I’ll be off to Berlin to join a couple thousand other Linux enthusiasts for our annual bash.
A lot has happened in the past 12 months especially in the fields of security and the Internet of Things (IoT). A lot of people were talking about the IoT a year ago, we’re now seeing a lot more projects being completed, especially in industrial IoT, and there have been a number of high-profile hacking cases in the past 12 months (baby monitors, automotive (Tesla this time) and industrial (Ukraine National Grid)) to give food for thought about security.
Previously, we’ve looked at the basic concepts of function parameter passing, and we’ve looked at the mechanics of how parameters are passed at the Application Binary Interface (ABI) level.
Far too often we focus on the mechanisms and efficiency of parameter passing, with the goal: if it’s efficient then it’s good; that’s all there is to it. In this article I want to move past simple mechanics and start to explore function parameter design intent – that is, what can I expect (to change) about the objects I use as function arguments; and what can I expect to be able to do with an object as a function implementer.
To that end, we’ll take a look at parameter passing from the perspective of the mutability (ability to be modified) of the parameters from both a caller’s and a function’s (callee’s) point of view.
In the previous article we looked at the memory consistency problem that occurs when writing multi-threaded code for modern multi-processor systems.
In this article is we’ll have a look at how we can solve the sequential consistency problem and restore some sanity to our programming world.
The C++11 memory consistency model is probably one of the most significant aspects of Modern C++; and yet probably one of the least well-understood. I think the reason is simple: it’s really difficult to understand what the problem actually is.
The memory consistency problem is a concurrency problem. That is, it’s a problem that occurs when we start writing multi-threaded code. More specifically, it’s a parallelism problem – the real subtleties occur when you have two or more processors executing code.
In the first part of this two-part article we’ll have a look at the causes of the memory consistency problem.
Nearly all our Feabhas courses now have their tools/lab exercises on a bootable Linux USB stick, either Fedora or Ubuntu. These USB sticks were designed to boot laptop PCs, but Macbook Pros are becoming increasingly popular in the laptop market, with 10% of the market in 2015.
Our USB sticks won’t boot a Macbook Pro, but we can run them in a virtual machine on a Mac.
Here I’ll talk you through what needs to be done in nine easy steps to get one of our EL-503 or EL-504 Fedora 19 USB sticks working with a Macbook Pro with Virtual Box, so that you can do all the Lab exercises in our courses including firing rockets from the USB rocket launchers!
My thanks to Niall Cooling – evangelist of all things Mac – for taking the plunge and getting a USB stick booting on his Macbook pro!
There’s a vast amount of material out there on boot times and people showcasing boot times of as little as one second . But the reality is often different for many devices in the field: some devices boot in 10s or less, others take over 3 minutes. Here’s a handful of devices I measured:
Raspberry Pi 2 Model B with Raspbian GNU/Linux 8
|11s to shell prompt
|Garmin Nüvi 42 Sat Nav
||14s (detects power off after 9s)
|Beaglebone Black with Angstrom Distribution
||17s to shell prompt
|PC booting Ubuntu 14.04 with KDE UI (no login)
|Android 5.1 Moto X smart phone
|PC booting Fedora 19 with Gnome UI from a USB Stick
|PC booting Mint 17.2 KDE from USB stick
|Pace Linux set top box with secure boot, middleware + UI
Virgin Media TiVo box with secure boot, middleware + UI
There’s a number of reasons why these boot times vary so drastically, and a number of things we can do to optimise boot time, but there is always a trade-off with functionality, and the development time and effort expended to make reductions.
Posted in Linux
Tagged Android, boot, linux