You are currently browsing the archives for the C/C++ Programming category.
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.
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.
Previously we looked at template class syntax and semantics. In this article we’ll extend this to look at inheritance of template classes.
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.
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.
A new (but not so welcome?) addition
Lambdas are one of the new features added to C++ and seem to cause considerable consternation amongst many programmers. In this article we’ll have a look at the syntax and underlying implementation of lambdas to try and put them into some sort of context.
I can’t imagine anyone reading this posting hasn’t already read about the Apple “goto fail” bug in SSL. My reaction was one of incredulity; I really couldn’t believe this code could have got into the wild on so many levels.
First we’ve got to consider the testing (or lack thereof) for this codebase. The side effect of the bug was that all SSL certificates passed, even malformed ones. This implies positive testing (i.e. we can demonstrate it works), but no negative testing (i.e. a malformed SSL certificate), or even no dynamic SSL certificate testing at all?
What I haven’t established* is whether the bug came about through code removal (e.g. there was another ‘if’ statement before the second goto) or, due to trial-and-error programming, the extra goto got added (with other code) that then didn’t get removed on a clean-up. There are, of course, some schools of thought that believe it was deliberately put in as part of prism!
Then you have to query regression testing; have they never tested for malformed SSL certificates (I can’t believe that; mind you I didn’t believe Lance was doping!) or did they use a regression-subset for this release which happened to miss this bug? Regression testing vs. product release is always a massive pressure. Automation of regression testing through continuous integration is key, but even so, for very large code bases it is simplistic to say “rerun all tests”; we live in a world of compromises.
Next, if we actually analyse the code then I can imagine the MISRA-C group jumping around saying “look, look, if only they’d followed MISRA-C this couldn’t of happened” (yes Chris, it’s you I’m envisaging) and of course they’re correct. This code breaks a number of MISRA-c:2012 rules, but most notably:
15.6 (Required) The body of an iteration-statement or selection-statement shall be a compound-statement
Which boils down to all if-statements must use a block structure, so the code would go from (ignoring the glaring coding error of two gotos):
Read more »
Functions are the lifeblood of a C program. The program flow is altered by passing parameters to functions, which are then manipulated. Conceptually function parameters are defined as being either:
- Inputs (Read-only) – client-supplied objects manipulated within the function only
- Outputs (Write-only) – objects generated by the function for use by the client.
- Input-Outputs (Read-Write) – client objects that can be manipulated by the function.
Defining the use of a parameter gives vital information not only to the implementer, but (perhaps more importantly) to the user of the function, by more-explicitly specifying the ‘contract’ of the function.
Many programming languages (for example, Ada) support these concepts explicitly. C, however, does not. One has to remember that when Kernighan and Ritchie developed C structured programming was very much in its infancy and many of these ideas were still being formulated (also remember that one of the C design goals was parsimony).
Even today, though, these concepts are rarely taught to C programmers and that has often led to clumsy, insecure or even downright dangerous APIs.
If C doesn’t support these concepts explicitly, can we simulate them? The answer is (of course) yes, by using some basic language constructs and forming some idioms.
Let’s look at each parameter type in turn.
C specifies a call-by-value or call-by-copy paradigm. That is, when a C function is called the compiler sets up a call frame that holds copies of the function parameters. Therefore, when you pass parameters by value you are – in effect – creating a parameter for the function to use that in no way affects the caller’s data
This is fine for simple types, but what about user-defined types – structs? What’s the problem with passing them by value?
Passing a structure by value means allocating enough memory for the parameter and then copying the contents of the original object into the parameter. In many embedded systems, where memory is at a premium, this could easily overflow the stack – at run-time, where its consequences could be difficult to track.
Strictly, to be explicit you should specify the type of the parameter as a const:
For simple types this is unlikely to add much value; however it may provide some benefit with structures.
If a parameter is passed as a const struct the compiler has the opportunity to perform a lazy evaluation – it passes the address of the structure instead of making a copy.
Note that this optimisation may not be supported by all compilers; or might not occur at all levels of optimisation.
The resolution to the above problem is to explicitly pass a pointer to the structure:
This is clearly more efficient than copying the whole structure. OK, the syntax has got a little messier, but we can live with that.
But hang on: do we still have an Input parameter? Actually, no.
What we’ve got here is an input-output parameter. By passing a ‘raw’ pointer the function can manipulate the caller’s object. To fix this we need to prevent manipulation of the pointed-to object:
Still not quite there, though. What happens below?
Strictly we should make the pointer itself const to prevent (either accidently or maliciously) the function manipulating the caller’s object:
This is a very good general rule-of-thumb for functions: make all pointers const
An output parameter is one that the function can write to, but never read (i.e. write-only). In C the only real mechanism we have for that is the function return value.
Most programmers are happy to return simple types from functions but what about the following code?
Since C performs pass (and return!) by value this would appear very inefficient:
The original object (biiig) is constructed. Then, when makeBigStruct is called space for the return value is allocated. Inside makeBigStruct, temp is allocated. On return temp is copied into the return value then, finally, copied into biiig.
Knowing this, most programmers never return structures from functions; preferring instead to supply them as input-output parameters. However, most modern compilers provide an optimisation which does just this.
Below is the same code but showing the optimisation. Instead of returning the structure the address of the receiving object is (implicitly) passed to the function. At the end of the function the return value is copied into the receiver, negating the need for a temporary return object.
In general, then, it is OK to return a struct from a function by value (unless you’re using an ancient C compiler). If you’re not certain (or your compiler doesn’t support this optimisation) it’s probably safer for you to use input-output parameters instead.
Finally, it’s worth noting the small detail that, unlike other languages, a C function can only have one output parameter. You’ll need to use input-output parameters for the rest.
Making the world a better place.
Using these idioms consistently is a very good way to improve the quality of your code. Firstly, it allows the compiler to provide stronger checking on your code. Second, it gives the reader extra information about how to use your functions and what guarantee (or promise) they can expect from them.
You may have noticed I’ve ignored arrays in this article. Check out this blog post for passing arrays to functions.
* Or, hokey-pokey if you prefer.