Follow Us
Categories
Archives
- February 2024
- January 2024
- August 2023
- December 2022
- November 2022
- October 2022
- February 2022
- October 2021
- September 2021
- August 2021
- July 2021
- June 2021
- May 2021
- January 2021
- November 2020
- October 2020
- August 2020
- April 2020
- February 2020
- January 2020
- October 2019
- September 2019
- July 2019
- May 2019
- April 2019
- March 2019
- February 2019
- January 2019
- December 2018
- October 2018
- September 2018
- August 2018
- July 2018
- April 2018
- February 2018
- January 2018
- December 2017
- November 2017
- October 2017
- September 2017
- August 2017
- July 2017
- June 2017
- May 2017
- April 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- April 2016
- January 2016
- December 2015
- November 2015
- October 2015
- September 2015
- August 2015
- July 2015
- June 2015
- May 2015
- January 2015
- December 2014
- November 2014
- October 2014
- September 2014
- August 2014
- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- November 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- February 2013
- January 2013
- November 2012
- October 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- December 2011
- November 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
Author Archives: Glennan Carnie
The C build process
In this article we look at the C build process – that is, how we get from C source files to executable code, programmed on the target. It wasn’t so long ago this was common knowledge (the halcyon days of the hand-crafted make file!) but modern IDEs are making this knowledge ever-more arcane.
Compilation
The first stage of the build process is compilation.
The compiler is responsible for allocating memory for definitions (static and automatic) and generating opcodes from program statements. A relocatable […]
Posted in C/C++ Programming
Tagged build process, C Declarations, C Definitions, C90, C99, compiler, linker, pre-processor, Toolchain, translation unit
20 Comments
Adapter pattern memory models
Following on from the article on Adapter patterns (Read more here) I’ve decided to explore the memory models of each of these patterns.
We’ll start with the simple case of a UtilityProvider class being a simple class with no virtual methods. Then we’ll look at what happens when the UtilityProvider has virtual functions added.
To flesh out the memory models I’ve added (arbitrary) data to both the UtilityProvider class and its adapters.
These memory models are based on the IAR Embedded Workbench C++ […]
Posted in C/C++ Programming
Tagged adapter, facade, memory, pattern, Virtual Functions, wrapper
1 Comment
Interface adaption, and private inheritance
A problem with code re-use
It’s a common situation in software development: you’ve acquired a class – either from a third-party source, or inherited from another project – that’s got some really useful features, but its interface doesn’t quite meet your immediate needs. Two typical scenarios are:
The interface is too big; you just want your clients to have a small subset of the facilities on offer.
The interface signatures don’t match what your client code needs (and you don’t want to – […]
The Five Orders of Ignorance
It’s not often you read a paper that has something unique and fresh to say about a topic, and expresses it in a clear and concise way.
Somehow, Phillip Armour’s The Five Orders of Ignorance had eluded me, until I found it referenced in another paper.
It really is an interesting point of view on software development. You can read the paper here.
Armour’s central tenet is software is a mechanism for capturing knowledge. That is, (correct) software is the result of having […]
Effective Testing: The “Swiss Cheese” model
Why do we test?
Software development is a collaborative effort. You bring in input from customers, managers, developers, and QA and synthesize a result. You do this because mistakes in requirements or architecture are expensive, possibly leading to lost sales.
When we develop products we want them to be successful. We want our customers to buy, enjoy, and recommend our products or services. In other words, we want to build quality products. In this case, quality means four inter-related things:
Compliance quality– Can […]
Posted in Testing
Tagged black-box, quality, review, Static Analysis, Swiss Cheese, unit test, white-box
3 Comments
More appalling user interface design
I came across a wonderfully counter-intuitive piece of user interface design this week.
The room I was in had a sliding shutter (that, for reasons best known to the architects, opened into the main building and not outside). The two halves of the shutter are controlled independently – that is, you can close one side or the other, or both. Each shutter is controlled with independent switch panels.
Common sense would suggest a single rocker switch: pushing one side would close the […]
Releasing Code
The Release process
The Release process defines the actions required to deliver a software product to an external customer. The external customer is any entity outside the development department. This may be a true (paying) customer, or may be another engineering department, for example Testing or Production.
The Release process is a triggered activity. The trigger events are scheduled as part of project planning. Defining a release is a project milestone which must define
What will be released
When it will be released […]
Posted in Design Issues
Tagged Alpha, Beta, Change Management, CM, Configuration Management, Release, Release Management, Revision Control, Testing
3 Comments
Change Management
Change Management is concerned with the proposal, selection and scheduling of changes during the lifecycle of a project.
Change Management is interlinked with, but separate to, Revision Control.
Change Management is the core to controlling your development processes. Without effective Change Management the management of your project is subject to slavish adherence to a (fixed, and pre-determined) project plan, with no mechanism for dealing with inevitable changes in requirements, design, implementation or testing.
It is no surprise that Change Management is at the […]
Posted in Design Issues
Tagged Change Management, Change Policy, Change Request, CM, Configuration Management, CR, Revision Control
Leave a comment
Baselines and Branching
A baseline is an identified set of files and directories in which there is one and only one version of each file and directory.
A baseline identifies one particular configuration of the software (or a subset thereof)
The baseline represents a fixed point in the development; that may be recreated as required.
Specifying a Baseline
A baseline defines a set of files, each at a particular version. These need not be the latest (most recent) version. A baseline label uniquely identifies the configuration. Files […]
Posted in Design Issues
Tagged Baseline, Branching, CM, Configuration Management, pattern, Revision Control
1 Comment
Configuration Items
A Configuration Item (sometimes referred to as a Computer System Configuration Item, or CSCI) is an artefact (hardware and/or software) that has an end-user purpose – that is, it contributes, in some way, towards the attributes of a system or product, or the development processes followed to produce the system or product. A Configuration Item (CI) is an artefact that is treated as a self-contained unit for the purposes of identification and change control. For example:
Specifications
Design models
Source code […]
Posted in Design Issues
Tagged Change Management, Change Policy, CM, Configuration Item, Configuration Management, CSCI, lifecycle, Review Policy, Revision Control
1 Comment