C++ London Meetup: Tuppence more on Standard Algorithms

This evening of talks was split into a set of Lightning Talks in the first half followed by a discussion about the Standard Library in the second half.

Part 1 – Lightning Talks
Richard Chandler – ACCU 2018 Trip Report – much on C++14 and C++17 standards to catch up on as well as introduction to Kotlin and a number of talks on diversity and inclusivity.

Phil Nash – East End Story
Phil dived into the controversial East Const v West Const debate

    void f( T const& t ) // East const
    void f( const T& )   // West const

i.e. should you put the const before or after the type. This topic was introduced by Dan Saks in 2011 – Simplifying const Syntax, Dr Dobbs and revived by Jon Kalb in A Foolish Inconsistency.

“Const applies to what is on its left, unless there is nothing to the left, in which case it applies to what is on the right.” But using east const format, it always applies to the left! West const reads more naturally from left to right, e.g. “const integer” – the East const argument is that you would always read declarations inside out and right to left!

    char const * const pc = str // pc is a const pointer to a const char, reading right to left

Developers are already accustomed to using East const for const member functions (must put const on the ‘east’ side). And there are other examples of going East:

    // moving the return type further east as a result of c++11
    auto someFunc( int i ) -> std::string; 

    // you have to put the return type on the east side
    auto lambda = [] -> double { return 0; } 

Other considerations: Swift/Haskell have trailing return type; putting auto at the start of list of function definitions, the start of the names line up; C++ standard NL.26 says use conventional const notation, endorses West Const notation, but is itself inconsistent!

Phil is now using trailing return types everywhere in production code – see his blog, East End Functions (LevelOfIndirection.com)

Stewart Becker – A Fool’s Consistency, the rebuttal (Jonathan Muller’s talk)

East const gives more consistency? If 83% of people write const T (i.e. West const), you need to be consistent with everyone else in your codebase.
Const pointer to const fallacy – with modern c++, use const std::string_view instead. Can use std::as_const(x) to get the const cast.
Right-to-left fallacy – but we read loops etc from left to right, and ‘const’ is an adjective which goes before the noun in English.
Clockwise-Spiral rule for function pointers.

const east west const – you are allowed to write const in both the East and West positions!!

Part 2 – Tuppence More on Standard Algorithms – Iakov Sergeev
Iakov believes the standard algorithms should make code easier to implement and read, but are forgotten in practice. He raised issues with inconsistencies and the learning curve to use STL (output iterator, predicates, modifying input sequences, could take both begin/end iterators).

Historically, the predicates were hard to implement where you had to supply a functor to call algorithms. Now, with lambdas, it’s much easier and localised to call algorithms.

The audience felt that Eric Niebler’s work on the Ranges TS should help a lot with adoption of standard algorithms.

Leave a comment

Filed under C++, Meetup, Programming

Book Review: A Legacy of Spies, John leCarre

I was given a lovely hardback edition of this book for my birthday. Whilst this book stands alone, I’m sure I miss much of the sentiment portrayed by the lead character, Peter Guillaume, because I haven’t read any of the George Smiley series before.

There are two main storylines. In the present day, Guillaume is interrogated by the British Secret Service as to his role in Windfall, a cold war operation. The Service is being sued for negligence by descendants of two dead agents – Guillaume is still liable even decades after the event. In the past, we follow Guillaume’s life as an agent from his recruitment through to working with his best friend Alec and the resulting fiasco that took Alec’s life.

The story is beautifully told and reveals its secrets piece-by-piece as if we’re viewing it through a fuzzy lens – perhaps as the cold war agents would have discovered the information themselves.

Leave a comment

Filed under Book Review

C++17: Lambdas

C++ has supported lambda functions since C++11, and post-C++14 even supported generic lambdas. C++17 adds a quirky feature to enable ‘copy capture’ of ‘this’. Here’s an example of it in action:

struct MyStruct
{
    auto lambda_with_this() // Before C++17, copies this pointer
    {
        auto f = [this]{ return value; };
        return f;
    }
    
    auto lambda_with_star_this() // C++17 - takes a local copy of *this
    {
        auto f = [*this]{ return value; };
        return f;
    }
    
    int value;
};

TEST( Cpp17, lambda_capture_this )
{
    MyStruct s{ 42 };
    auto f = s.lambda_with_this();
    s.value = 101;
    EXPECT_EQ( 101, f() );
}

TEST( Cpp17, lambda_capture_star_this )
{
    MyStruct s{ 42 };
    auto f = s.lambda_with_star_this();
    s.value = 101;
    EXPECT_EQ( 42, f() );
}

Notice that in the second case, we capture a copy of our object – so the lambda returns the value held at the point of capture (42) rather than the value when it is called (101). This can be very important if ‘this’ has been destroyed between the creation of the lambda and the time at which it’s called.

Now, C++14 also supported generalised lambda capture, which meant you could (re-)name variables when capturing (and provided a neat way to capture-by-move):

    auto f = [tmp = *this]{ return tmp.value; };

But the C++17 code is more concise. See this useful StackOverflow post for more discussion.

Another advance in C++17 is that lambdas are implicitly constexpr – so you can now use them in compile-time contexts, like declaration of std::array:

// lambda explicitly constexpr since C++17
auto square = []( auto v ){ return v*v; }; 

TEST( Cpp17, lambda_implicitly_constexpr )
{
    // std::array calls 'square()' at compile time
    std::array<int, square(4)> values; 
    EXPECT_EQ( 16, values.size() );
}

See also the previous C++17 post.

Leave a comment

Filed under C++, C++ Code, Programming

C++17: Nested Namespaces

Another crowd-pleaser in C++17 is the ability to declared nested namespaces without literally nesting them. In the past, you had to do this, which involves a lot of wasted whitespace:

namespace NestedNamespaces
{
    namespace Really
    {
        namespace Work
        {
            auto return_int(){ return 42; };
        }
    }
}

Happily, you can now do this instead:

namespace NestedNamespaces::Really::Work
{
    auto return_int(){ return 42; };
}

TEST( Cpp17, nested_namespaces )
{
    EXPECT_EQ( 42, NestedNamespaces::Really::Work::return_int() );
}

See also previous C++17 post.

1 Comment

Filed under C++, C++ Code, Programming

C++17: Structured Bindings

This is one of a series of posts on C++17 features – see also previous post on if initialisers.

Structured bindings are a convenient way of handling multiple return values from functions. Whilst F# has been able to do this:

let f() = 42, "Hello, World" // return a pair of values
let a, b = f() // assign a and b to the values returned by f

in C++, we’ve had to declare the variables up front and use std::tie to assign values (so not only does this take more lines, we also have to default initialise the variables then throw away the defaults).

auto t = std::make_tuple( 42, "Hello, World" );
int a, b;
std::tie( a, b ) = t;

The new structured bindings are much more concise, even if the use of square brackets came as a surprise. Even better, you can use structured bindings with structs and std::array.

int my_int{ 42 };
std::string my_string{ "Hello, World" };
bool my_bool{ true };

auto return_pair()
{
    return std::make_pair( my_int, my_string );
}

auto return_tuple()
{
    return std::make_tuple( my_int, my_string, my_bool );
}

struct MyStruct
{
    int a;
    double b;
    int c;
    
    static MyStruct Expected;
};

MyStruct MyStruct::Expected = { 1, 2.2, 3 };

auto return_struct()
{
    return MyStruct::Expected;
}

auto return_array()
{
    return std::array<int,3>{ 1, 2, 3 };
}

auto return_map()
{
    return std::map<int, std::string>{ {1, "a"}, {2, "b"}, {3, "c"} };
}

TEST( Cpp17, structured_bindings_for_pair )
{
    auto [i, s] = return_pair();
    
    EXPECT_EQ( my_int, i );
    EXPECT_EQ( my_string, s );
}

TEST( Cpp17, structured_bindings_for_tuple )
{
    auto [i, s, b] = return_tuple();
    
    EXPECT_EQ( my_int, i );
    EXPECT_EQ( my_string, s );
    EXPECT_EQ( my_bool, b );
}

TEST( Cpp17, structured_bindings_for_struct )
{
    auto [i1, d, i2] = return_struct();
    
    EXPECT_EQ( MyStruct::Expected.a, i1 );
    EXPECT_EQ( MyStruct::Expected.b, d );
    EXPECT_EQ( MyStruct::Expected.c, i2 );
}

TEST( Cpp17, structured_bindings_for_array )
{
    auto [i1, i2, i3] = return_array();
    
    EXPECT_EQ( 1, i1 );
    EXPECT_EQ( 2, i2 );
    EXPECT_EQ( 3, i3 );
}

TEST( Cpp17, structured_bindings_for_iterating_over_map )
{
    for ( const auto& [key,value] : return_map() )
    {
        switch (key)
        {
            case 1: EXPECT_EQ( "a", value ); break;
            case 2: EXPECT_EQ( "b", value ); break;
            case 3: EXPECT_EQ( "c", value ); break;
            default: break;            
        };
    }
}

For me, the best examples come when combining features – the range-based for loop with structured bindings is a thing of beauty.

See also next C++17 post.

2 Comments

Filed under C++, C++ Code, Programming

C++17: if initialiser

I attended a C++17 presentation by Nicolai Josuttis last year, but at the time, my laptop’s compiler didn’t support any of the features to try them out. After a recent update, it turns out that many are now supported, so I’ve written a few unit tests using GTest.

The first feature I tried was the if initialiser. This feature looks a bit odd at first, because C++ programmers are so conditioned to seeing if statements containing a single condition. Allowing an initialiser statement as well

if ( initialiser; condition )

means that you can initialise a variable and test it on the same line. It also prevents the variable being used outside the scope of the if statement – this prevents accidental re-use if you subsequently mis-type a variable name.

auto return_int()
{
   return 101;
}

TEST( Cpp17, if_initialiser )
{
    // NB we can use i in the body of the if or the else
    // Also, must have a variable name for the object to live in the whole statement
    // (so must name locks taken, even if not used in the body, otherwise it's a temporary).
    if ( auto i = return_int(); i < 100 )
    {
        EXPECT_TRUE( i < 100 );
    }
    else
    {
        EXPECT_TRUE( i >= 100 );
    }
}

TEST( Cpp17, if_initialiser_with_map_insert)
{
    std::map<int, std::string> my_map{ {42, "Hi" } };
    
    if ( auto[it, inserted] = my_map.insert( std::make_pair(42, "Bye" ) ); !inserted )
    {
        // See also StructuredBindings for iterating over a map
        auto& [key,value] = *it; // iterator is pair of key and value
        EXPECT_EQ( 42, key );
        EXPECT_EQ( "Hi", value );
        
        value = "Bye"; // update the value
        EXPECT_EQ( "Bye", my_map[42] );
        
        // key = 43; // compile error! - cannot assign to const key-type
    }
}

See also next post on C++17 Structured Bindings.

1 Comment

Filed under C++, C++ Code, Programming

Book Review: The Lost Fleet – Valiant, Jack Campbell

This book follows the same template as the other Lost Fleet books that I’ve read. We travel with Captain “Black Jack” Geary on Dauntless, the flag ship of his fleet, as he attempts to steer his people home after a damaging series of battles. This episode is more optimistic, the fleet is performing well in battle and Geary’s efforts to bring a humane change in culture to the personnel is succeeding (they rescue stranded enemy civilians who had been abandoned on an outpost planet). However, he still faces the growing threat of hidden enemies within the leadership who are still trying to overthrow him. Geary confronts the fact that he cannot continue to court Co-President Victoria Rione now that his growing feelings for Captain Tanya Desjani are obvious to everyone in his crew.
Three stars

Leave a comment

Filed under Book Review