Tag Archives: C++

Tech Book: A Tour of C++, Bjarne Stroustrup

A Tour of C++ This recent book was recommended by Herb Sutter at CppCon as a slim summary of all that C++ developers should be expected to know. It’s a good read, sprinkled liberally with example code to illustrate the techniques that make up modern C++. Having originally learn C++98, then spent a lot of time reading and trying our C++11 techniques, it’s interesting to see how the language looks when presented as a whole. Also, the book covers some C++14 additions.

The points I particularly found interesting were:

  • override – use this to mark virtual methods that are declared in the base class and have an implementation in the derived class (avoids declaring a new virtual method if the signature is wrong)
  • explicit – single argument constructors should by default be marked as explicit to avoid unexpected implicit conversions, unless there’s a reason not to
  • delete – when defining a base class, it’s good practice to ‘delete’ the default copy and move operations, given that the default implementations will not know how to handle derived class members
  • regex – the book covers the standard library as well as the language. A welcome addition is std::regex, and the chapter in this book is an excellent introduction
  • vector initialisation – uniform initialisation of vectors of a struct can still use initialiser lists, even if the struct members have different types e.g. string/int
  • vector::at – this method returns the same value as operator[] (subscript), but performs bounds-checking, which doesn’t happen with operator[]

Four Stars

Leave a comment

Filed under C++, Tech Book

Bjarne Stroustrup: Five Popular Myths about C++

Catching up on my C++ reading, I read through Bjarne Stroustrup’s 5 Popular Myths about C++ and why he believes they are wrong:

  1. To understand C++, you must first learn C
  2. C++ is an Object-Oriented Language
  3. For reliable software, you need Garbage Collection
  4. For efficiency, you must write low-level code
  5. C++ is for large, complicated, programs only

Worth reading for the surprising amount of hostility he reports to these arguments, which on the face of it I thought were pretty reasonable.

The comments prove yet again that the “Myths” paper was needed. People keep repeating the old hairy rationalizations. Unfortunately, many programmers don’t read long papers and dismiss short ones for being incomplete. The unwillingness of many programmers to read a long paper was the reason I released this paper in three separate parts.

Leave a comment

Filed under C++, Programming

Overload magazine: Order Notation in Practice

Overload 124Roger Orr wrote an excellent article for Overload about complexity measurement. It’s amazing how many candidate for programming roles in general, and C++ roles in particular, aren’t comfortable with order notation. This introduction should be a must read before interviewing!

Leave a comment

Filed under C++, Programming

How to speed up your C++ build

I’ve been working on a software library for some time and have seen it grow to include a large number of types. This has gradually increased the time needed to build the library – in fact, to build the whole package in our CI system recently hit an hour. At that point, I needed to take action to bring the build time back to a reasonable level.

  • Increase the number of cores on the build machine
  • Reduce the number of header includes per source file
  • Configure pre-compiled headers on the largest projects

Build

The graph above shows the improvements with each step. Doubling the number of cores on the build machine halved the build time because much of the time is spent compiling .cpp files which can be done in parallel.

Reducing the number of header inclusions also had a big effect. Initially, I’d taken the approach that all headers could be included stand-alone, and they would include their own dependencies. For this large project, though, that turned out to be expensive – so instead, I produced a single header that included all the others in the right order. Although that also has drawbacks (like, any change to any of those headers forces all the project files to be re-built), it’s reasonable for the workflow involved in this area of work.

Finally, turning on pre-compiled headers had a really noticeable improvement – particularly in building individual projects within the package (which many of our developers will be doing). From what I’ve read on MSDN, the previous step was a pre-requisite – it’s recommended to have .cpp files include the same framework header files in the same order.

Leave a comment

Filed under C++, Programming

C++: reasons to return void and/or return early

I was recently refactoring some code, leaving a function in which the most natural thing was to return a call to a void function. The code structure was like this simplified example, where I wanted to return early from a nested if statement, but it felt clumsy to put bar() and return on separate lines:

void bar()
{
    printf( "bar\n" );
}

void foo( int a, double b )
{
    if ( a > 0 )
    {
        double c = a * b;
        if ( c > 0 && c > a )
        {
            return bar();
        }
    }

    printf( "foo\n" );
}

I was surprised that this worked, because I half expected the compiler to do something sinister like optimise out the call to bar(), given that it returns void and only executes useful code via side-effects.

This post asks the same question, but it seems that this is supported in C++ and can be useful for template functions that return void.

Some readers may take issue with the early return in the code above. I admit I used to follow the mantra of maintaining a single return point in any function (except perhaps an early return after checking pre-conditions on parameters). However, the modern C++ take on this is that early returns are recommended and may lead to faster code. Herb Sutter has this to say:

allowing the function itself to return early when it knows it’s done is perfectly fine and fully under the function’s control. To put the final nail in the coffin, note that “single exit” has always been a fiction in any language that has exceptions, because you can get an early exceptional return from any point where you call something that could throw an exception

.

Leave a comment

Filed under C++

LINQ for C++ by Steve Love

The October 2013 issue of Overload includes an article by Steve Love on building a range library that enables LINQ like syntax in C++.

20140827-141310.jpg

This looks pretty good and is along similar lines to the approach in cpplinq.

Leave a comment

Filed under C++, Programming

F# equivalent of C++ ‘Most vexing Parse’

I first read of the C++ “Most Vexing Parse” in the Scott Meyers Effective C++ series. For reference, here’s the code:

double aDouble;
int i(int(aDouble)); // This doesn't do what you think

The commented line actually declares a function i that takes a single integer parameter and returns an integer. Now, today, I saw something similar in F# that made me scratch my head and I think is similar:

let func a b c =
    return a + b + c

let main () =
    let sum = func a b
    // use sum
    0

The symptom was that my function (here, called func) wasn’t being called. Yet stepping through in the debugger, I could break on the line that called it – yet it wouldn’t step into the function! Of course, by missing one of func’s parameters in the function call, I’d actually declared sum to be a new function taking one parameter (or to use functional terminology, I’d curried a and b).

This is hard to spot when the calling code and function declaration are in separate files and when you’ve added a new parameter to the function and it still compiles but doesn’t do what you expected!

Leave a comment

Filed under Programming