Category Archives: C++

April 12, 2013 · 12:26 pm

Herb Sutter – complex initialisation for a const variable

Herb Sutter provided this handy use of lambdas to initialise a const variable that needs some logic:

const int i = [&]{

    int i = some_default_value;

    if(someConditionIstrue)
    {
        Do some operations and calculate the value of i;
        i = some calculated value;
    }

    return i;

} (); // note: () invokes the lambda!

It requires that the compiler can determine the type of the lambda even though it isn’t a simple return – that’s due to be finalised in C++14 but is supported in some compilers already.

Leave a comment

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

Tagged as ,

April 11, 2013 · 8:30 pm

Scott Meyers – Draft TOC for concurrency topics

Scott Meters has posted tentative item titles for the concurrency section in his upcoming Effective C++11 book.

Leave a comment

Filed under C++, Programming

Tagged as , ,

April 11, 2013 · 7:49 pm

More interesting topics from ACCU 2013

  • Aleksander Fabijanic talked about Dynamic C++, with reference to rival approaches to representing dynamic types: boost::any, boost::variant, boost::type_erasure, Facebook folly::dynamic and poco::dynamic::var.
  • Stig Sandres presented a way to use boost::coroutines and std::future to emulate “await” from N3564.  This follows on from N3558, which includes the ability to add “.then(…)” to a std::future.
  • I hadn’t heard of reference-qualifiers, which C++11 allows you to put on a method declaration to restrict its use to either l-value or r-value references.  See this post on Stack Overflow.  In particular, there was a proposal to restrict standard library assignment operators to l-values (since it makes no sense to assign to an r-value reference).
  • Russell Winder used std::iota from the standard <numeric> library in an example to populate a container with sequentially increasing values
std::vector<int> elements(10);
std::iota( elements.begin(), elements.end(), 0 );
std::for_each( elements.begin(), elements.end(), 
    [] (int i){ std::cout << i; }); // prints 0123456789

Leave a comment

Filed under C++

Tagged as

April 11, 2013 · 2:52 pm

Using std::tie to implement operator< (by Anthony Williams at ACCU 2013)

I’ve used std::tie to unbind the underlying data from a std::tuple in the past:

auto t = std::make_tuple( 1, 42, 100 );
int a, b, c;
std::tie( a, b, c ) = t;

But I hadn’t seen this handy trick for using std::tie to implement operator<

#include <tuple>

struct S
{
  S(int a_, int b_, int c_) : a(a_), b(b_), c(c_)
  {}

  int a;
  int b;
  int c;
};

bool operator<( const S& lhs, const S& rhs )
{
  return std::tie( lhs.a, lhs.b, lhs.c )
       < std::tie( rhs.a, rhs.b, rhs.c );
}

int main()
{
  S s1( 1, 2, 3), s2 ( 1, 2, 4 ), s3 ( 0, 2, 3);

  std::cout << "s1 should be less than s2: " << (s1 < s2) << "\n"
            << "s3 should be less than s1: " << (s3 < s1) << "\n";

  return 0;
}

Notice that std::tie does not copy the variables (as per the earlier example, it takes them by reference). You can also mimic the use of use of underscore in F#

let f i = (i, i*2, i*4)
let a, _, c = f 5

using std::ignore

auto f = []( int i){ return std::tuple(i, i*2, i*4); }
int a, b;
std::tie( a, std::ignore, b ) = f( 5 );

5 Comments

Filed under C++ Code

Tagged as , , ,

April 10, 2013 · 8:25 pm

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

Tagged as , , , , ,

March 29, 2013 · 2:22 pm

GCC 4.8 released

GCC 4.8 has been released. This version uses C++ in its implementation (previously it was C only).

Leave a comment

Filed under C++

Tagged as ,

March 27, 2013 · 6:37 pm

How to use smart pointers in C++

Good question about how to use c++ smart pointers posted on Stack Overflow. I haven’t used std::weak_ptr, but the idea of using it to return an “observing” pointer that you can later check for expiry and obtain a std::shared_ptr sounds like a better approach that returning a raw pointer.

Leave a comment

Filed under C++

Tagged as

March 22, 2013 · 12:59 pm

WordPress App mangles my code!

I’ve noticed that whenever I use the WordPress App on my iPhone or iPad to edit a technical post that includes some code, the snippet I’ve carefully slaved over gets mangled. In particular, anything that uses templates in C++ (or generics in F#) will be affected, for example

vector<int> myData;

becomes

vector; myData;

The only answer at the moment is to be disciplined and restrict myself to editing code-based posts in the Web editor, which doesn’t destroy my content.

1 Comment

Filed under C++, Technology

Tagged as , ,

March 21, 2013 · 12:30 pm

Stephan Lavavej’s make_unique proposal

Stephan Lavavej has submitted a proposal to the C++ Standards committee for make_unique (the std::unique_ptr equivalent to std::make_shared for std::shared_ptr).

make_unique’s presence in the Standard Library will have several wonderful consequences. It will be possible to teach users “never say new/delete /new[]/delete[]” without disclaimers. Additionally, make_unique shares two advantages with make_shared (excluding the third advantage, increased efficiency). First, unique_ptr<LongTypeName> up(new LongTypeName(args)) must mention LongTypeName twice, while auto up = make_unique<LongTypeName>(args) mentions it once. Second, make_unique prevents the unspecified-evaluation-order leak triggered by expressions like foo(unique_ptr<X>(new X), unique_ptr<Y>(new Y)). (Following the advice “never say new” is simpler than “never say new, unless you immediately give it to a named unique_ptr”.)

It’s a really useful utility as demonstrated in this video.

Leave a comment

Filed under C++

Tagged as , ,

March 13, 2013 · 6:59 pm

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++

Tagged as , , ,