Tag Archives: C++

C++11 noexcept

Someone on ISOCpp re-awakened an old question on StackOverflow about noexcept, dynamic v static checking and differences between noexcept and the (now deprecated) throw specifiers.

Throw specifiers were the subject of Item 14 – Use Exception Specifications Judiciously in Scott Meyers’ More Effective C++. The drawbacks he mentions are: the standard prohibits compilers from rejecting calls to functions that might violate the exception specification (including if there is no specifier on the called function – this to allow integration with legacy code libraries that lack such specifications); you cannot know anything about the exceptions thrown by a template’s type parameters – so templates and exception specifications don’t mix; they’re easy to violate inadvertently (e.g. via callback functions); they lead to abrupt program termination when violated.

Stroustrup wrote this about noexcept in his C++11 FAQ:

If a function declared noexcept throws (so that the exception tries to escape the noexcept function) the program is terminated (by a call to terminate()). The call of terminate() cannot rely on objects being in well-defined states (i.e. there is no guarantees that destructors have been invoked, no guaranteed stack unwinding, and no possibility for resuming the program as if no problem had been encountered). This is deliberate and makes noexcept a simple, crude, and very efficient mechanism

This post gives a history of noexcept,

If the noexcept feature appears to you incomplete, prepared in a rush, or in need of improvement, note that all C++ Committee members agree with you. The situation they faced was that a safety problem with throwing move operations was discovered in the last minute and it required a fast solution

There are however important differences [between noexcept and throw()]. In case the no-throw guarantee is violated, noexcept will work faster: it does not need to unwind the stack, and it can stop the unwinding at any moment (e.g., when reaching a catch-all-and-rethrow handler). It will not call std::unexpected. Next, noexcept can be used to express conditional no-throw, like this: noexcept(some-condition)), which is very useful in templates, or to express a may-throw: noexcept(false).

One other non-negligible difference is that noexcept has the potential to become statically checked in the future revisions of C++ standard, whereas throw() is deprecated and may vanish in the future.

and this comment on SO from Jonathan Wakely also makes sense:

template code such as containers can behave differntly based on the presence or absence of noexcept (and equivalently throw()) so it’s not just about compiler optimizations, but also impacts library design and choice of algorithm. The key to doing that is the noexcept operator that allows code to query how throwy an expression is, that’s the new thing, and all that cares about is a yes/no answer, it doesn’t care what type of exception might be thrown, only whether one might be thrown or not

Leave a comment

Filed under C++

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

Bjarne Stroustrup’s Tour of C++

I’m reading through Bjarne Stroustrup’s Tour of C++, which Addison-Wesley have graciously allowed him to post ahead of its inclusion in the fourth edition of The C++ Programming Language.

stroustrup

It starts with The Basics. It was refreshing to see new features of C++11 introduced alongside the most rudimentary aspects of the language – rather than being viewed as a whole new language that teams might choose to adopt/ignore. I’m sure if you start learning C++ today, features such as enum class, auto, constexpr will seem natural, begging the question “What did you do without them?”.

I thought this code snippet was especially cute:

for (auto x : {10,21,32,43,54,65})
    std::cout << x << '\n';

I’m used to writing code in F# like this,

[| 10; 21; 32; 43; 54; 65 |] 
  |> Array.iter (fun i -> printf "%d\n" i)

but it’s great to see such concise code in C++ at well.

The second part concerns abstractions. This includes summaries of copy and move semantics. This note on move semantics is helpful because many explanations focus on how to move data into a new instance of a class rather than the state in which to leave the old object:

After a move, an object should be in a state that allows a destructor to be run. Typi- cally, we should also allow assignment to a moved-from object

Preventing copy and move:

Using the default copy or move for a class in a hierarchy is typically a disaster: Given only a pointer to a base, we simply don’t know what members the derived class has (§3.3.3), so we can’t know how to copy them. So, the best thing to do is usually to delete the default copy and move operations; that is, to eliminate to default definitions of those two operations

where C++11 provides the delete annotation to tell the compiler not to write a default copy/move operation, but you could follow today’s practice and declare it private and omit the implementation until your compiler catches up.

If you need to copy an object in a class hierarchy, write some kind of clone function. [Note that] a move operation is not implicitly generated for a class where the user has explicitly declared a destructor. Furthermore, the generation of copy operations are deprecated in this case. This can be a good reason to explicitly define a destructor even where the compiler would have implicitly provided one.

There are also useful examples of where to use type aliasing, for example this one that uses the assumption that STL containers provide a value_type alias (or typedef):

template<typename C>
using Element_type = typename C::value_type; 

template<typename Container> void algo(Container& c)
{
  Vector<Element_type<Container>> vec;
  // ... 
}

You can also use aliasing to define new templates by binding arguments on existing templates:

template<typename Value>
using String_map = Map<string,Value>;

String_map<int>m; //alias for Map<string,int>

Part three is about algorithms and containers.

The example for how to write operator>>(), read from, is particularly verbose – I’m sure it would have been better to show a regex solution alongside. Worth a look anyway for this mechanism for indicating a streaming failure (typically I would throw an exception):

is.setf(ios_base::failbit);

Similarly, I hadn’t realised before that range-checked random access to a std::vector was possible via the at(size_t i) method:

T& operator[](int i) { return vector::at(i); } // range-checked

The final part is about concurrency and utilities.

One of the main utilities now available in C++11 is std::shared_ptr (which was sorely lacking from the previous standard).  However, Stroustrup hints that in many cases it’s sufficient to create an object on the stack with a local variable:

Unfortunately, overuse of new (and of pointers and references) seems to be an increasing problem.

When you do need to manage heap objects, std::unique_ptr is very lightweight with no space or time overhead compared to a built-in pointer.  You can pass or return unique_ptr’s in or out of functions, because the implementation uses move semantics (whereas std::shared_ptr is copied).

One concurrency topic that always causes problems is how to define a convention between locks so that deadlock cannot occur due to acquiring the locks in the wrong order.  There’s a neat example of how to avoid that:

// Initialise lock guards with their mutexes, but don't lock yet
std::lock_guard<std::mutex> lock1(mutex1, defer_lock);
std::lock_guard<std::mutex> lock2(mutex2, defer_lock);
std::lock_guard<std::mutex> lock3(mutex3, defer_lock);
// other preparation
std::lock( lock1, lock2, lock3 );
// Implicitly release all mutexes when locks go out of scope.

Stroustrup also introduces the concepts of futures and promises:

The important point about future and promise is that they enable a transfer of a value between two tasks without explicit use of a lock; “the system” implements the transfer efficiently.

The absence of locks is key and is also mentioned when introducing std::packaged_task and std::async.  This section might be better written in reverse, with the simpler async concept introduced first and locks/mutexes in context as the advanced technique.

Under <utilities>, a boon is likely to be std::tuple, a heterogenous sequence of elements (I’ve added the use of std::tie to show how to unpack the values):

auto myTuple = std::make_tuple(std::string("Hello"), 10, 1.23);
std::string a;
int b;
double c;
std::tie( a, b, c ) = myTuple;

I wouldn’t use std::tuple in an externally visible interface, but it’s useful to avoid defining types for passing multiple return values.

I like this example of using the new standard <random> library to simulate a die:

using my_engine = default_random_engine; // type of engine
using my_distribution = uniform_int_distribution<>; 
my_engine re {}; // the default engine
my_distribution one_to_six {1,6}; 
auto dice = bind(one_to_six,re); // make a generator
int x = dice(); // roll the dice: x becomes a value in [1:6]

 

Leave a comment

Filed under C++

Using the compiler to answer calling convention questions

Raymond Chen points out that you can help yourself by using the compiler to output assembly listings which can help to answer questions such as which parameter comes first under the current calling convention.

Leave a comment

Filed under C++

Explicit user-defined conversion operators

You can now mark user-defined conversion operators as explicit:

        explic­it oper­a­tor bool() const;

This is an improvement over previous idioms that have been employed to avoid a class of bugs that occur when a type is inadvertently converted.

Leave a comment

Filed under C++

Online C++ Compilers

Today I took a look at some Online C++ compilers – this would have been very useful when checking portability of some code in my recent post on C++11 Concurrency.

First, here’s LiveWorkspace.org which makes g++ 4.72 and 4.8 available as well as clang 3.2:

MutableReferenceMemberClang

Second, Rise4Fun allows you to try Visual Studio:
MutableReferenceMemberVS

As anticipated, the Counter class (which contains a mutable member of type int&) compiles under Visual Studio, but doesn’t under clang 3.2 or gcc (which is correct according to the C++ standard). What’s great about LiveWorkspace is how quickly you can switch between compilers to see how they like the same code. For example, the amended code that treats int& as a template parameter compiles under g++ 4.7.2 and 4.8, but doesn’t under clang 3.2:

#include <iostream>

template<typename T>
class Counter
{
  mutable T m_t;
public:
  Counter(T t) : m_t(t){}
  void Increment() const { ++m_t; }
};

int main()
{
  int count = 0;
  Counter<int&> counter(count);
  counter.Increment();
  std::cout << count << "\n";
  return 0;
}

Leave a comment

Filed under C++

How to write managed C++ using templates

Occasionally, I write some managed C++ code as a glue-layer between C++ and F#. Today was such an occasion, and I found myself writing the same piece of code in several places with different types. Obviously, my reaction was to refactor to share the common code – given that the behaviour was common and independent of the underlying type, a template class seemed appropriate – but can you use templates with managed C++?

It turns out that you can – here’s the code, the aim of which was to take some COM object from native code and wrap it as an option of some expected strong type. If you haven’t seen managed C++ before, the syntax looks pretty ghastly – it may help to mentally substitute & for ^. If you aren’t familiar with F# option, it’s like boost::optional;.

template<typename T>
FSharpOption<T^>^ getOptional( IUnknown* raw )
{
  FSharpOption<T^>^ optionalValue = 
    optionalValue = FSharpOption<T^>::None

  if ( raw != nullptr )
  {
    T^ cooked = (T^)Marshal::GetObjectForIUnknown(IntPtr( raw ));
    if (cooked != nullptr)
      optionalValue = FSharpOption<T^>::Some(cooked);
  }
  return optionalValue;
}

Here’s how you would call the template function to get back the managed C++ equivalent of the F# type MyType option:

FSharpOption<MyType^>^ myValue = getOptional<MyType>( _rawValue );

Leave a comment

Filed under C++

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

Programming C++ on Linux Mint

First of all, let me say how easy it was to install CodeBlocks and CodeLite on Linux Mint using the Software Manager.  The user guide makes a terrific case for the Linux package management approach, but putting this UI on top (instead of using the command line as I was in Kubuntu) takes it to the next level.  For a start, it’s browsable and you can read reviews from other users.  I’ve installed CodeBlocks, CodeLite and g++.  I really like the way that the sections in Software Manager match the groupings from the start menu (so that my programming related applications are together and easily visible).

CodeBlocks
First impressions – not bad, it detected that I wanted to use gcc as my compiler.  I created a simple Hello World project and it compiled first time.  When I tried to add C++11 features, I got compile errors – but those were resolved by editing the Project build options and enabling “Have g++ follow the coming C++0x ISO C++ language standard”, i.e. -std=c++0x.  I rather like this dialog – it offers other useful compiler options too like “-Weffc++” to turn on Effective C++ warnings, with each compiler flag neatly explained.  As soon as I’d enabled -std=c++0x, the lambda and auto that I’d added compiled and ran just fine.

CodeLite

Oh dear.  Firstly, it offered to download a new version of CodeLite for me.  Given that I only just did it in Software Manager, that seemed a bit odd.  Next, I tried to create a new workspace – it crashed.  I tried to open the workspace it had created – crashed again.  This is probably because Software Manager needs to be updated to download the latest version, but I’ve uninstalled it for now.

Leave a comment

Filed under C++, Programming