Category Archives: C++ Code

Examples of SFINAE (by Jonathan Wakely at ACCU 2013)

I’m currently attending ACCU2013 at Bristol and saw Jonathan Wakely’s presentation on SFINAE (Substitution Failure Is Not An Error) this morning.

This is a traditional SFINAE example using type traits.  true_type and false_type just need to have different sizes, then we can use function template specialization to differentiate between two cases.

typedef char true_type;
typedef double false_type;
template<class T>
true_type is_iter( typename T::iterator_category* t );
template<class T>
false_type is_iter(...);
template<class T>
struct is_iterator
{
  static const bool value =
    (sizeof(is_iter<T>(0)) == sizeof(true_type));
};

void testTypeTrait()
{
 std::cout
    << "Try int " << is_iterator<int>::value << "\n";
    << "Try vector<int>::iterator "
    << is_iterator<std::vector<int>::iterator>::value << "\n";
}

This example later in the presentation really stood out – a step towards Concepts, it shows syntax available today for restricting the types that will compile with a given template (thanks to C++11 aliasing and default arguments for template parameters):

class WidgetBase
{};

class Widget : public WidgetBase
{};

class Bodget
{};

class Decorator
{
private:
template<class T>
using IsDerivedWidget = typename std::enable_if<
        std::is_base_of<WidgetBase, T>::value>::type;

public:
template<class T,
class Requires = IsDerivedWidget<T>>
Decorator( const T& )
{}
};

So if I instantiate Decorator with Widget, it compiles (because Widget derives from WidgetBase), but instantiating with Bodget yields a compiler error (because Bodget does not inherit from WidgetBase).

Widget w;
Decorator decoratedWidget( w );
Bodget b;
Decorator decoratedBodget( b ); // Error

This code all compiles with recent versions of gcc (e.g. 4.7).  Under Visual Studio, only the traditional example compiles (default arguments for function templates are not yet supported, neither is aliasing, not even with the Nov ’12 CTP).

1 Comment

Filed under C++ Code

Implementing operator<() for strict weak ordering

Overload113Cover
The latest edition of Overload Magazine (a publication by the ACCU) includes a recipe for implementing operator<, as is often required when you want store some class in an STL associative container.

bool operator<( const T& rhs ) const
{
if ( a != rhs.a ) return a < rhs.a;
if ( b != rhs.b) return b < rhs.b;
...
return false;
}

This assumes that operator!= exists on that class and in my view muddies the waters between equivalence (the property you test in a std::set or std::map with operator<) and equality (the test in std::vector or std::list with operator==). Of course, if operator== exists, you can easily amend the recipe accordingly, but again neither operator== nor operator!= have default implementations so may not be provided.

Where necessary, you can fall back onto this more verbose recipe:

bool operator <(const T& rhs) const
{
  if ( a < rhs.a )
    return true;
  else if (rhs.a < a)
    return false;

  if ( b < rhs.b)
    return true;
  else if (rhs.b < b)
    return false;

  // repeat for all child elements c, d, e etc
  return false;
}

Leave a comment

Filed under C++ Code

Concurrency with C++11

Having watched Herb Sutter’s C++ Concurrency video, I wanted to try out a few of the techniques for myself. The first step was to write a simple synchronised queue, which he left as an exercise for the reader.  The key feature is that pop() blocks until an element is pushed into the queue – then it returns the element.  This turns out to be pretty succinct using C++11 features like std::mutex and std::condition_variable:

namespace musingstudio
{
  template<typename T>
  class SynchronizedQueue
  {
    std::deque<T> m_queue;
    std::mutex m_mutex;
    std::condition_variable m_wait_for_non_empty;

  public:
    // When an element of T is pushed onto the queue,
    // one caller waiting in a pop() call will be notified
    void push( const T& t )
    {
      std::unique_lock<std::mutex> lock(m_mutex);
      m_queue.push_back(t);
      m_wait_for_non_empty.notify_one();
    }

    // Calls to pop() will block until an element of T is 
    // pushed onto the queue
    T pop()
    {
      std::unique_lock<std::mutex> lock(m_mutex);
      while(m_queue.empty())
      {
        m_wait_for_non_empty.wait(lock);
      }
      T tmp(m_queue.front());
      m_queue.pop_front();
      return tmp;
    }
  };
}

and here’s some code to exercise it:

void testConcurrentQueue()
{
  musingstudio::SynchronizedQueue<int> elements;

  std::thread pusher([&]()
  {
    for (int i = 0; i < 5; ++i)
    {
      wait();
      std::cout << "Pushing " << i << '\n';
      elements.push(i);
    }
  });

  std::thread popper([&]()
  {
    for (int j = 0; j < 5; ++j )
    {
      int popped = elements.pop();
      std::cout << "Popped " << popped << "\n";
    }
  });

  pusher.join();
  popper.join();
}

Output:

SynchronizedQueueOutput

The next item that caught my eye was a template class that wraps an instance of T so that access to it becomes transactional across threads. No need to explicitly take a lock for each group of calls to the object – instead, you express each transaction on on the instance of T as a lambda. A mutex blocks and the command (expressed as a lambda) is executed in the calling thread.  Herb called his example Monitor<T>, but I preferred Sequential<T> as a partner to Concurrent<T> (see below).  Also, I replaced operator() with excute() (in my opinion it’s easier to read).  Typical use looks like this:

Sequential<T> t( ... ); 
t.execute([&](T& u)
{  
  /* perform multiple operations in this lambda as one synchronised transaction*/  
});

So much for the context – here’s the implementation:

namespace musingstudio
{
  template<typename T>
  class Sequential
  {
    mutable T m_t;
    mutable std::mutex m_mutex;
  public:
    Sequential( T t ) : m_t( t )
    {
    }
    template<typename F>
    auto execute( F f ) const -> decltype(f(m_t))
    {
      std::unique_lock<std::mutex> lock(m_mutex);
      return f(m_t);
    }
  };
}

And here’s the code in action, using Sequential<ostream&> to synchronise calls to std::cout:

void testSequential()
{
  musingstudio::Sequential<std::ostream&> sync_cout( std::cout );
  auto doPush = [&]() 
  {
    for ( int i = 0; i < 10; ++i )
    {
      sync_cout.execute([&](std::ostream& os)
      {
        os << i << i << i << i << i << "\n";
      });
    }
  };
  std::thread thread1(doPush);
  std::thread thread2(doPush);
  thread1.join();
  thread2.join();
}

Output:

SequentialOutput

Now that we’ve got SynchronizedQueue<T> and Sequential<T>, here’s Concurrent<T> which provides a way to perform a series of synchronised operations on some object in parallel with the activity on the main thread.  For example, if you need to keep a GUI thread responsive.  I love the idea of pushing a “Done” event onto the message queue in the destructor so that queued work is concluded and then Concurrent<T> returns.  This is also a very nice use for std::future and std::promise – allow the caller to keep the return value as a future, but don’t block until it’s needed.

template<typename T>
class Concurrent
{
  mutable T m_t;
  mutable SynchronizedQueue<std::function<void()>> m_queue;
  bool m_done;
  std::thread m_worker;
  // Assign value to the promise where there's a 
  // non-trivial return type
  template<typename Ret, typename Ftn, typename T>
  void setValue( std::promise<Ret>& promise, Ftn& f, T& t ) const
  {
    promise.set_value( f(t) );
  }
  // Assign void to the promise - trivial void return type
  template<typename Ftn, typename T>
  void setValue( std::promise<void>& promise, Ftn& f, T& t ) const
  {
    f(t);
    promise.set_value();
  }
public:
  Concurrent( T t ) : m_t(t), m_done(false), 
    m_worker( [=](){ while(!this->m_done){ m_queue.pop()(); }} )
  {}
  ~Concurrent()
  {
    m_queue.push( [=]{ this->m_done = true; } );
    m_worker.join();
  }
  // In order to return a value from the operation that we 
  // process on another thread, use async, promises and futures 
  // - we can't just return the calculated value,
  // because then the caller would have to block.
  template<typename F>
  auto execute( F f ) const -> std::future<decltype(f(m_t))>
  {
    auto promise = 
      std::make_shared<std::promise<decltype(f(m_t))>>();
    auto return_value = promise->get_future();
    m_queue.push( [=]()
    { 
      try
      {
        setValue( *promise, f, m_t );
      }
      catch(...)
      { promise->set_exception( std::current_exception() ); }
    });
    return return_value;
 }
};

Here’s some code to exercise Concurrent<T>:

void testConcurrentReturningFunction()
{
  musingstudio::Concurrent<std::string> words("Concurrent<T> - ");
  std::vector<std::future<std::string>> values;
  // Set off the calculations in a worker thread, storing future return values
  for ( size_t i = 0; i < 10; ++i )
  {
    values.push_back( 
      words.execute( [=]( std::string& in )
      {
        in += std::to_string(i);
        return in;
      }) );
  }
  // Now collection the return values and display them
  std::for_each( values.begin(), values.end(), [](std::future<std::string>& f)
  {
    std::cout << f.get() << "\n";
  });
}

Output:

ConcurrentOutput

7 Comments

Filed under C++ Code

Writing C++11 concurrency code on Linux Mint with gcc 4.7.2

I’ve written some C++11 concurrency code in VS2012 with the November CTP and wanted to test if it would also run on Linux compiled with gcc – hence the effort to upgrade my laptop over the last couple of days. The upgrade worked fine – I’m quite impressed with Linux Mint and with CodeBlocks. Unfortunately, gcc 4.7.2 has left me disappointed.

Firstly, I tried to compile my whole concurrency project – I was expecting a few minor tweaks (gcc was stricter on how I declare my template functions), then I hit this Internal Compiler Error:

Concurrency.cpp:156:1: internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035

Apparently, this bug has been fixed but not yet released – it’s due to calling a member function from a lambda in a templated class. So I thought I’d cut my code down, eliminate the lambdas and focus on std::thread and std::condition_variable. Still no joy, this time the program aborted:

LinuxAbort1

In fact, it seems this is a long standing issue. And the code to provoke it is hardly pushing the boundaries of threading:

void sayHelloWorld()
{
    std::cout << "Hello World\n";
}

int main()
{
    std::thread talk( sayHelloWorld );
    talk.join();
    return 0; 
}

Looking on the bright side, gcc 4.8 should be along soon and I’m sure the support for std::thread and lambdas will be working by then. In the meantime, I’ll be hanging out with VS2012 Nov CTP.

1 Comment

Filed under C++ Code

Memory corruption due to C++ code incompatible with C++11 standard

I’m a big fan of C++11 and the new features that have become available, including move semantics.  However, our team found today that a code optimization which worked under VS 2005 was causing memory corruption under VS 2010.

The story goes back to a string holder class a bit like this (if you think BSTRs you’ll be on the right lines, but taking COM out of the picture makes the example clearer):

class CDeepCopy
{
protected:
  char* m_pStr;
  size_t m_length;

  void clone( size_t length, const char* pStr )
  {
    m_length = length;
    m_pStr = new char [m_length+1];
    for ( size_t i = 0; i < length; ++i )
    {
      m_pStr[i] = pStr[i];
    }
    m_pStr[length] = '';
  }

public:
  CDeepCopy() : m_pStr( nullptr ), m_length( 0 )
  {
  }

  CDeepCopy( const std::string& str )
  {
    clone( str.length(), str.c_str() );
  }

  CDeepCopy( const CDeepCopy& rhs )
  {
    clone( rhs.m_length, rhs.m_pStr );
  }

  CDeepCopy& operator=( const CDeepCopy& rhs )
  {
    if (this == &rhs)
      return *this;

    clone( rhs.m_length, rhs.m_pStr );
    return *this;
  }

  bool operator<( const CDeepCopy& rhs ) const
  {
    if (m_length < rhs.m_length)
      return true;
    else if (rhs.m_length < m_length)
      return false;

    return strcmp( m_pStr, rhs.m_pStr ) < 0;
  }

  virtual ~CDeepCopy()
  {
    delete [] m_pStr;
  }
};

CDeepCopy was used as the key into a map. For large data sets with heavily overlapping key values, this was inefficient because each lookup would entail the cost of a copy constructor – this was particularly expensive due to the heap operations. As an optimization, the following technique was used to avoid the copy constructor call in the event of an update operation, yet worked correctly if the operator[]() call led to an insertion.

class CShallowCopy : public CDeepCopy
  {
  public:

  CShallowCopy( const std::string& str ) : CDeepCopy()
  {
    m_pStr = const_cast<char*>(str.c_str());
    m_length = str.length();
  }

  ~CShallowCopy()
  {
    m_pStr = nullptr;
  }
};

So you could do an efficient lookup like this that only caused a deep copy if an insertion into the map was required instead of an update:

int _tmain(int argc, _TCHAR* argv[])
{
  std::map<CDeepCopy, int> entries;
  std::string hello( "Hello" );

  CDeepCopy key( hello );
  entries[key] = 1;

  // Named variable
  CShallowCopy key2( hello );
  entries[key2] = 2;

  // Unnamed temporary variable
  entries[ CShallowCopy( hello ) ] = 3;

  return 0;
}

This code worked as intended in VS2005. However, compiled under VS2010 we were seeing memory corruption in the final case (the one with the unnamed temporary). After some debugging, we realised that under C++11, std::map has an operator[]( KeyT&& key ), that is the key is an rvalue reference – and this form is called for our unnamed temporary case. That avoids calling our CDeepCopy copy constructor, and so the key in the map can be left referencing deallocated memory.

A simple workaround prevents this happening again – declare CDeepCopy( CDeepCopy&& ) as private but omit the definition – this means that the unnamed temporary usage does not compile.

Leave a comment

Filed under C++ Code

Delegating Constructors in C++11

Here’s some code that tries out C++ 11 delegating constructors.  These were announced as part of Visual Studio in the November CTP and avoid the need to refactor common code out of constructors into an “init” function.  There are examples of their use in Stephan Levavej’s excellent video series too.

class Request
{
public:
  enum class Priority{ High, Medium, Low };
  static const Priority defaultPriority(){ return Priority::Low; }

  // Constructor with all parameters fully specified
  Request( Priority priority, const std::string& requestId ) :
      m_priority( priority ),
      m_requestId( requestId )
  {
    std::cout 
    << "Request( Priority priority, const std::string& requestId ) called: "
    << "RequestId " << m_requestId << ", "
    << "Priority " << toString( m_priority ) << "\n";
  }

  // Delegate to fully specified constructor above
  Request( const std::string& requestId ) : 
    Request( defaultPriority(), requestId )
  {
    std::cout 
      << "Request( const std::string& requestId ) called: "
      << "RequestId " << requestId << "\n";
  }

  // Contrived example to demonstrate chaining delegating constructors
  Request( const std::vector<int>& requestId ) : 
    Request( toString( requestId ) )
  {
    std::cout << "Request( const std::vector<int>& requestId ) called\n";
  }

  // Contrived example to show that ~Request() is called if the delegating constructor completed
  Request( Priority priority ) : 
    Request( priority, "Empty" )
  {
    throw std::exception( "This constructor is deprecated, RequestId field is now mandatory." );
  }
  ~Request()
  {
    std::cout 
      << "~Request() called:"
      << "RequestId " << m_requestId << ", "
      << "Priority " << toString( m_priority ) << "\n";
  }
private:
  std::string toString( const std::vector<int>& requestId )
  {
    std::string tmpId;
    for (auto elem : requestId)
    {
      if ( elem < 0 || 9 < elem )
        throw std::exception("Invalid request id, should be digits");
      tmpId.push_back(static_cast<char>(elem + '0'));
    }
    return tmpId;
 }

 std::string toString( Priority p )
 {
   if (p == Priority::Low ) return "Low";
   else if ( p == Priority::Medium ) return "Medium";
   else if ( p == Priority::High ) return "High";
   else
     throw std::exception( "Unexpected Priority" );
 }
 Priority m_priority;
 const std::string m_requestId;
};

And here’s a program that exercises the Request class (this uses musingstudio::initialize to conveniently initialize a standard container):

int _tmain(int argc, _TCHAR* argv[])
{
  std::cout << "\nCall fully specified constructor\n";
  Request fullySpecified( Request::Priority::High, "HeartTransplant-749553" );

  std::cout << "\nCall a delegating constructor\n";
  Request defaultPriority( "BookDelivery-5542" );

  std::cout << "\nCall chained delegating constructors\n";
  Request legacy( musingstudio::initialize<std::vector<int>>( { 1, 6 } ) );

  std::cout << "\nThis should throw without executing the destructor...\n";
  try
  {
    // This should throw due to -ve input, but does NOT execute ~Request()
    // because no constructor call completed
    Request invalid( musingstudio::initialize<std::vector<int>>( {-1} ) );
  }
  catch( const std::exception& exc )
  {
    std::cout << "ERROR: " << exc.what() << std::endl;
  }

  std::cout << "\nThis should throw and execute the destructor...\n";
  try
  {
    // This will throw because no requestId is not specified
    // (contrived example to show that ~Request() is executed
    // because the delegating constructor succeeded).
    Request noRequestId( Request::Priority::Low );
  }
  catch( const std::exception& exc )
  {
    std::cout << "ERROR: " << exc.what() << std::endl;
  }

  std::cout << "\nRemaining destructors...\n";

  return 0;
}

DelegatingConstructorsOutput
As with other Nov CTP features, Visual Studio intellisense hasn’t caught up yet, so expect to see red squiggly lines all over the code if you try this out.

What’s interesting is that it’s now possible for ~Request() to be called if a constructor fails to complete, as long as the delegatee (inner) constructor does complete.

Leave a comment

Filed under C++ Code

Experimental code for simulating Reflection in C++

Motivation for looking at Reflection in C++

At work, we have two frameworks for developing new components – one in C++ and the other in F#. The F# framework is newer and benefits from the insight of previous years working with the C++ framework. In particular, the new F# framework only requires developers to implement a reduced, strongly typed interface in F# by defining a few types (e.g. records) and associated functions between them. This reduced interface is inflated into a full model by the framework, making heavy use of .NET Reflection.

The F# framework has delivered productivity improvements (development time down to a third compared to the previous C++ framework). But the philosophical question remains – how much of that is due to the new architecture developed with the benefit of hindsight? And could we replicate that architecture in C++? The main functionality gap comes down to this: in F# you can use .NET Reflection to discover the names and types of fields in F# types such as unions, records and options, but in C++ you can’t.

Requirements

A full implementation of Reflection for C++ would include ability to discover type information, field names, properties and methods, as well as being able to create instances of types and invoke methods.  I’m interested in a small subset of that scope – the ability to discover the names and values of fields in a C++ struct.

Solution

#include "stdafx.h"

#include <iostream>
#include <string>

#include <boost\preprocessor.hpp>
#include <boost\preprocessor\variadic\size.hpp>
#include <boost\type_traits.hpp>

#include <boost\mpl\range_c.hpp>
#include <boost\mpl\for_each.hpp>

#define REMOVE_BRACKETS(...) __VA_ARGS__
#define REMOVE_NEXT(x)
#define STRIP_TYPE(x) REMOVE_NEXT x
#define DECLARE_DATA_MEMBER(x) REMOVE_BRACKETS x
#define TYPE_ONLY(x) x REMOVE_NEXT(

#define REFLECTABLE(...) \
  static const int number_of_fields = BOOST_PP_VARIADIC_SIZE(__VA_ARGS__); \
  friend struct Reflector; \
  \
  template<int N, class Parent = void> \
  struct FieldData {}; \
  \
  BOOST_PP_SEQ_FOR_EACH_I(REFLECT_EACH, data, BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__))

#define REFLECT_EACH(r, data, i, x) \
  DECLARE_DATA_MEMBER(x); \
  template<class Parent> \
  struct FieldData<i, Parent> \
  { \
    Parent & parent; \
    FieldData(Parent& p) : parent(p) {} \
    \
    TYPE_ONLY x ) & get() const \
    { \
      return parent.STRIP_TYPE(x); \
    }\
    const char * name() const \
    {\
      return BOOST_PP_STRINGIZE(STRIP_TYPE(x)); \
    } \
  }; \

struct Reflector
{
  // Get a FieldData instance for the N'th field in type T
  template<int N, class T>
  static typename T::template FieldData<N, T> getFieldData(T& x)
  {
    return typename T::template FieldData<N, T>(x);
  }

  // Reflector is a friend of T, so has access to the private member T::number_of_fields
  template<class T>
  struct FieldCounter
  {
    static const int count = T::number_of_fields;
  };
};

// FieldDispatcher - calls Visitor::visit for each field in T
template<class T, class Visitor>
struct FieldDispatcher
{
  FieldDispatcher( T& t, Visitor visitor ) :
  t(t),
  visitor(visitor)
  {
  }

  template<class FieldIterator>
  void operator()(FieldIterator)
  {
    auto field = Reflector::getFieldData<FieldIterator::value>(t);
    visitor.visit( field );
  }

  T& t;
  Visitor visitor;
};

template<class T, class Visitor>
void for_each_field(T& t, Visitor visitor)
{
  typedef boost::mpl::range_c<int, 0, Reflector::FieldCounter<T>::count> FieldList;
  FieldDispatcher<T, Visitor> field_dispatcher( t, visitor );

  // For each field in T, dispatch the visitor to that field
  boost::mpl::for_each<FieldList>( field_dispatcher );
}

struct PrintNameValueVisitor
{
  template<class FieldData>
  void visit( FieldData field )
  {
    std::cout << field.name() << "=" << field.get() << std::endl;
  }
};

struct Person
{
  Person(const char *first_name, int age, const char* street, const char* town) :
    first_name(first_name),
    age(age),
    street_name(street),
    town(town)
    {
    }

  REFLECTABLE
  (
    (const char *) first_name,
    (int) age,
    (std::string) street_name,
    (std::string) town
  )
};

int _tmain(int argc, _TCHAR* argv[])
{
  Person p("John", 31, "Electric Avenue", "Harrogate" );
  for_each_field(p, PrintNameValueVisitor());

  return 0;
}

Output

Output

Conclusions

The code above ‘works’ – it satisfies the requirements by providing a way to decorate a struct with metadata that can be used to return the names and values of each field. However, in Visual Studio 2010 and 2012, it produces compiler warnings (due to the macro hackery in TYPE_ONLY) and confuses intellisense (which doesn’t cope with the REFLECTABLE macro). In practical terms, that makes it unsuitable, because the productivity benefits are lost when intellisense and auto-complete stop working.

2 Comments

Filed under C++ Code

std::initializer_list – an even better way to populate a vector

Visual Studio 2012 November CTP does provide us with support for initializer lists, even though standard library containers like vector<T> do not yet implement constructors that accept an initializer list.  However, that doesn’t stop us writing code like this to make populating containers easy:

namespace musingstudio
{
  template<typename Container>
  Container initialize( 
    std::initializer_list<typename Container::value_type> items )
  {
    return Container( items.begin(), items.end() );
  }
}

And call it like this:

auto evens = musingstudio::initialize<vector<int>>({2,4,6,8,10});

I like the way this reads “initialize vector of int( values )” – and it’s pretty efficient too, if your container supports move semantics (which the standard library containers do).

2 Comments

Filed under C++ Code

Variadic Templates – example that simplifies populating a vector

I was hoping that Visual Studio 2012 would allow us to initialise a std::vector; like this, especially with the November CTP:

std::vector<int> items = { 1, 2, 3, 4, 5 };

However, although the November CTP includes support for variadic templates and uniform initialisation, they haven’t yet decorated all standard templates with initializer lists as needed for the above. That tempted me to write a simple variadic template to avoid having to write code like this ever again:

std::vector<int> items;
items.push_back(0);
items.push_back(1);
items.push_back(2);

By writing this:

namespace musingstudio
{
  template<typename T, typename U, typename ...Args>
  void push_back(std::vector<T>& items, U item, Args ...args)
  {
    items.push_back(item);
    push_back( items, args... );
  }

  template<typename T, typename U>
  void push_back(std::vector<T>& items, U item)
  {
    items.push_back(item);
  }
}

We can then write this:

std::vector<int> items;
musingstudio::push_back( items, 0,1,2,3,4,5 );

Obviously, this is less efficient than implementing a constructor that takes initializer lists, but it’s more fun than repeatedly typing push_back the C++98/03 way.

Leave a comment

Filed under C++ Code