C++

C++11 (and beyond) Exception Support

Wednesday, 27 Sep 2017 - 16:26 +0100 by Ralph McArdell code, C++

Introduction C++11 added a raft of new features to the C++ standard library and errors and exceptions were not left out. In this article we will start with a quick overview of the new exception types and exception related features. While the nitty gritty details are not covered in great depth in most cases a simple usage example will be provided. The information was pulled together from various sources[1][2][3], and these, along with others, can be used to look up the in depth, detailed, specifics.

Raspberry Pi Linux User Mode GPIO in C++ - Part 3

Wednesday, 30 Sep 2015 - 12:33 +0100 by Ralph McArdell Raspberry Pi, Linux, code, C++, GPIO

The previous instalments[1][2] have described creating the rpi-peripherals[3] library to access general purpose input output (GPIO) on a Raspberry Pi running Raspbian Linux in C++ from user space. They covered creating the phymem_ptr class template that utilises RAII (resource acquisition is initialisation[4]) to manage mapped areas of physical memory, setting up the library project and the implementation of support for basic general purpose input and output of single bit Boolean values, clocks and pulse with modulation (PWM).

Raspberry Pi Linux User Mode GPIO in C++ - Part 2

Wednesday, 29 Jul 2015 - 18:04 +0100 by Ralph McArdell Raspberry Pi, Linux, code, C++, GPIO

Previously[1] I described the initial stage of developing a library called rpi-peripherals[2] to access general purpose input output (GPIO) on a Raspberry Pi running Raspbian Linux in C++ from user land – that is there are no kernel mode parts to the library. The library was built on memory mapping the physical memory locations of the Raspberry Pi’s BCM2835 processor’s peripherals’ control registers using the dev/mem device accessed via a RAII (resource acquisition is initialisation[3]) resource managing class template called phymem_ptr.

Raspberry Pi Linux User Mode GPIO in C++ - Part 1

Thursday, 26 Mar 2015 - 15:22 +0100 by Ralph McArdell Raspberry Pi, Linux, code, C++, GPIO, mmap

I started experimenting with Raspberry Pi GPIO using Python[1][2]. Then the original Gertboard[3] kit was released so I ordered and built one which enabled me to play with BCM2835 peripheral IO beyond basic GPIO. At the time the Gertboard had test and example C code available[4] that, as with the Python case, I felt could be expressed more cleanly. I thought it would be interesting to see what advantages C++, hopefully C++11, features and idioms might provide.

Comments on Comments…part 2: Some Example Code…

Sunday, 4 Aug 2013 - 15:49 +0100 by Ralph McArdell code, C++, GotW, concurrency

I have posted some example code on GitHub showing the Shared Immutable, Exclusive Setup ideas discussed in the Comments on comments to Herb Sutter’s updated GotW #6b solution (part 2) blog post to demonstrate the ideas: https://github.com/ralph-mcardell/dibase-blog-sharedimmutable-exclusivesetup My thought was to create a type that was not just a simple chunk of memory, create wrapper types to add support for the intrusive Shared Immutable, Exclusive Setup pattern discussed in the blog post that allowed for easy specification of atomic and memory order policy.

Comments on comments to Herb Sutter's updated GotW #6b solution (part 2)

Monday, 8 Jul 2013 - 15:53 +0100 by Ralph McArdell code, C++, GotW, concurrency

Previously[1] I wondered, from musing when reading Herb Sutter’s updated Guru of the Week 6b[2] article, how one might – in C++11 – enforce a concurrent usage pattern in which an object can only be modified after creation by the creating thread until all modifications are done when the object becomes immutable and concurrently accessible. Concurrent access before an object becomes immutable is considered an error as are attempts to modify an object that is immutable.

Comments on comments to Herb Sutter's updated GotW #6b solution (part 1)

Friday, 31 May 2013 - 16:49 +0100 by Ralph McArdell code, C++, GotW, concurrency

I have been following Herb Sutter on his Sutter’s Mill[1] website and while reading the solution and comments to the posted solution to GotW #6b Solution: Const-Correctness, Part 2[2] some thoughts popped into my head. First to catch my eye were some comments on the overhead that may be incurred by std::atomic being only to do with what liberties the compiler can take with respect to optimising writes. This raised an eyebrow as I was under the impression that the need to force atomic operation effects to be globally and consistently visible has more of an effect on performance than reordering write restrictions.