If you’re interested in software synthesizers in general or generating digital representations of DTMF tones and don’t want to waste many CPU cycles when generating sine waves, keep on reading.

Generating sampled sine waves without invoking the math library’s sin function for every sample is actually fairly simple. I will show two approaches of doing that with differing pros and cons and finally a version that combines the advantages of both.

Approach1: Imagine the 2D plane, a unit circle, and a point on that circle that rotates around the origin (see below). If you take the y-coordinate of that point, send this to the soundcard as one sample, rotate the point by an angle of a and repeat these steps you’ll hear a sine wave with a frequency of a*fs/(2*pi) Hz where fs is the sampling rate in Hertz. We only need to compute the rotation matrix in advance depending on the desired frequency. After that we need 4 multiplications and two additions per sample. Not so bad. But it’s also not really that fast.

Since we are only interested in one component of this point coordinate but we’re computing the other one as well, one might ask “Can we improve this and make it faster?”. And yes, there’s a way to do it.

Approach2: Instead of rotating the point by computing the product of a rotation matrix and a vector we can write the next point as a linear combination of the previous two points, see the picture below.

In this example, p2 can be computed using p2 = q + (q-p0) = 2 q – p0 where the point q is simply a scaled version of p1, namely q = cos(a) p1. If we put this together, we’ll arrive at the following linear recurrence equation

The nice thing about it is that to compute the y-coordinate of the new point we don’t need any previous x-coordinates. In addition, we saved a multiplication per component. The factor 2 cos(a) can be computed in advance, so, we’re able to compute additional sine wave samples with only one multiplication and one addition per sample. Actually, this variant is an oscillating IIR filter with a pair of complex conjugated poles on the unit circle. Usually, this is something you would avoid because such filters are unstable or “self-oscillating” to use another term. But in this case we exploit this oscillation property.

Are we done yet? Almost. What if we want to reset the phase of the oscillator or change the frequency without resetting the phase? How is that supposed to work? Admittedly, this is not that easy if we only remember the last two samples and the weighting factor 2 cos(a). Also, we have to keep in mind that calculations with floating point numbers involves rounding errors. It is quite possible that the amplitude of the sine wave will increase or decrease due to rounding errors. So, once in a while we should normalize it. Normalization is also not that trivial if you rely on the recurrence equation alone.

I think the most elegant solution is a combination of both approaches. We can use the current point including x-coordinate and the rotation matrix as the oscillator’s state for easier phase, frequency and amplitude manipulations. But when the user is interested in generating many samples at a time, we unroll the loop to produce a block of samples using the linear recurrence equation. Also, instead of vectors and rotation matrices we can simply use complex numbers. Finally, here’s the C++0x source code of my sine generator. To keep it short but still flexible, I made use of C++0x’s new lambda feature:

#ifndef SINE_GENERATOR_HPP_INCLUDED
#define SINE_GENERATOR_HPP_INCLUDED

#include <cmath>
#include <complex>

class sine_generator
{
    std::complex<double> phase;
    std::complex<double> rotation;

    template<typename Sink>
    void internal_generate(int count, Sink sink);

public:
    sine_generator() : phase(1),rotation(1) {}

    void set_frequency(double rad)
    { rotation = std::polar(double(1),rad); }

    void reset_phase(double rad)
    { phase = std::polar(double(1),rad); }

    template<typename OutputIter>
    void generate(int count, OutputIter begin)
    {
        internal_generate(count,[&](double smp){
            *begin = smp; ++begin;
        });
    }

    template<typename ForwardIter, typename BinOp>
    void generate(int count, ForwardIter begin, BinOp binop)
    {
        internal_generate(count,[&](double smp){
           *begin = binop(*begin,smp); ++begin;
        });
    }
};

template<typename Sink>
void sine_generator::internal_generate(int count, Sink sink)
{
    std::complex<double> rot_forx = pow(rotation,12);
    phase /= abs(phase); // prevent drifting off due to rounding errors
    // use linear recurrence for generating the samples
    double const fy = 2 * real(rotation);
    double const fx = 2 * real(rot_forx);
    double y0 = imag(phase);
    double x0 = real(phase);
    double y1 = imag(phase*conj(rotation));
    double x1 = real(phase*conj(rot_forx));
    double tt; // temporary variable
    while (count >= 12) {
        // 4*3 = 12 samples in a row ...
        for (int k=0; k<4; ++k) {
            // output       | compute next sample
            sink(y0); tt = fy*y0-y1;
            sink(tt); y1 = fy*tt-y0;
            sink(y1); y0 = fy*y1-tt;
        }
        // update x as well ...
        tt = fx*x0-x1; x1 = x0; x0 = tt;
        count -= 12;
    }
    phase = std::complex<double>(x0,y0);
    while (count-- > 0) {
        sink(imag(phase));
        phase *= rotation;
    }
}

#endif // SINE_GENERATOR_HPP_INCLUDED 

Here’s an example program that uses the sine generator:

#include <iostream>
#include <vector>
#include <functional>

#include "sine.hpp"

using std::vector;
using std::cout;
using std::plus;

int main()
{
    const int buffsize = 160;
    vector<double> buffer(buffsize);

    sine_generator sg;

    sg.set_frequency(440 * 2*3.141592653589793 / 8000);
    sg.reset_phase(0);
    // overwrite buffer with sine wave ...
    sg.generate(buffsize,buffer.begin());

    sg.set_frequency(880 * 2*3.141592653589793 / 8000);
    sg.reset_phase(0);
    // mix another sine into the buffer ...
    sg.generate(buffsize,buffer.begin(),plus<double>());

    for (int i=0; i<buffsize; ++i) {
        cout << buffer.at(i) << '\n';
    }
}

- P

• Fact 1: Concepts have been removed from the C++0x standardization effort. See Doug Gregor’s blog post.
• Fact 2: C++0x still includes a whole lot of other core language and library features.

Fact 1 is as saddening as it is a relief, to be honest. Not all is lost, though. We don’t get modular type checking in C++0x. But we can restrict templates via SFINAE which just got more powerful with the addition of decltype and the extension of SFINAE to expressions. What follows is a reminder of how this used to look in good ol’ C++98. In this case it’s a simple pointer wrapper:

  template<typename T>
  class ptr
  {
    T* p;
    template<typename> friend class ptr;
  public:
    ptr(T* p) : p(p) {}

    template<typename U>
    ptr(ptr<U> const& x, typename enable_if<
        is_convertible<U*,T*>::value
    >::type* =0)
    : p(x.p) {}

    T& operator*() const {return *p;}
    T* operator->() const {return p;}
    T* get() const {return p;}
  };

“What’s with the enable_if?” you may ask. This is “SFINAE” in action. If the compiler considers instantiating the constructor for some types T and U where U* is not convertible to T* we’d like the compiler to ignore this function. We can do this by using enable_if for selecting the type of an additional default parameter. enable_if<...>::type is only a valid type if the condition — the first parameter to enable_if — holds. Otherwise, the class won’t contain a typedef and when there is no such typedef the compiler has a hard time figuring out the constructor’s prototype. Since it deduces U and enable_if<...>::type depends on U such an error qualifies as “deduction failure” and makes the compiler just ignore the constructor. Great! This is exactly what we want! This way we can constrain templates and kick them out of the overload set before it tries to instantiate them and even before the compiler applies overload resolution.

Without this SFINAE trick the compiler will still complain when someone tries to convert a ptr<int> to a ptr<double>, for example. But it complains rather late after trying to instantiate the conversion constructor. Since int* is not convertible to double* it will point us to the initializer list — specifically p(x.p) — instead of pointing us directly to the offending line that requrested a ptr<int> to ptr<double> conversion. This is not as nice because it exposes implementation details and usually leads to many more lines of error messages. But exposition of implementation details is not the only problem. If we can’t eliminate functions from the overload set we might get ambiguity errors. For example, the set might contain two function template specializations that are deemed equally good in terms of overload resolution. But only one function can be instantiated, the other one will trigger a compilation error because some template parameters don’t satisfy all constraints. Since overload resolution is applied before instantiation the function call is ambiguous even though there’s only one candidate whose body is well-formed.

So, at first glance, it looks like SFINAE is just as good as a concept-”requires clause” when it comes to constraining a function template. Unfortunately, there are only a few things we can check for in C++98. Luckily, this changes with C++0x.

  template<typename T> struct meta {
    static T&& src();
    static void sink(T);
  };

  template<typename T>
  class ptr
  {
    .....
    template<typename U, typename =
      decltype( meta<T*>::sink( meta<U*>::src() ) )>
    ptr(ptr<U> const& x) : p(x.p) {}
    .....
  };

This example shows a constructor with a default template argument which would have been illegal in C++03. This allows us to get rid of spurious default parameters. The expression inside decltype() tries to pass a pointer of type U* to a function that accepts a pointer of type T*. The implementation of the type trait class is_convertible is based on the same idea. If U* is implicitly convertible to T* the declared type of this expression will be void which is the sink function’s return value type. If U* is not convertible to T* we have a “deduction failure” and the compiler will just ignore the function. I also could have just reused the is_convertible type trait like this

  template<typename U, typename = typename
    enable_if<is_convertible<U*,T*>::value>::type >
  ptr(ptr<U> const& x) : p(x.p) {}

This version is probably more readable. But the point I was trying to make with the former example was that it’s basically possible to check for the “well-formedness” of arbitrary expressions via decltype.

With a bit of macro trickery I was able to write a little header file that contains type trait classes for many many expressions that emulate the concepts HasPlus, HasDereference, HasAssign, Convertible, HasConstructor, etc. I call these “basic expression concepts”. Anything else can be built on top of these via composition. With a couple of other helper templates I managed to make composition fairly easy. This is what my “ForwardIterator concept” looks like, for example:

  template<typename Iter> struct ForwardIterator
  : and_<
    SemiRegular<Iter>, // copiable, assignable
    EqualityComparable<Iter>,
    HasDereference<Iter>,
    SameType<typename HasPreincrement<Iter&>::result_type,Iter&>
    Convertible<typename HasPostincrement<Iter&>::result_type,Iter>
  > {
    typedef typename HasDereference<Iter>::result_type reference;
  };

Every “basic expression concept” exposes a static const bool named value which is true if the expression is well-formed and false otherwise. In addition, it contains a typedef for result_type that either matches the expressions type or is equivalent to invalid_type (an empty struct). The use of invalid_type instead of a missing typedef prevents compilation errors and eases composition. So far, this looks like a nice framework for constraining templates. If there is interest, I could show you the whole 300 line header file. It also includes a nice macro that lets you write code like this:

  template<typename Iter, REQUIRES(ForwardIterator<Iter>)>
  void foo(Iter a, Iter b) {
    // ...
  }

Conclusions: Extended SFINAE and decltype will make generic programming more enjoyable and possibibly more accessible to the masses. We can’t emulate modular type checking or concept-based overloading well, though. Constraints for class templates are even easier to check for with the help of static_assert and appropriate trait classes.

- P

How would you write a function that accepts a string (with call-by-value semantics, source is not modified) and returns a reversed string by value? Perhaps something like this?

  // version 1, C++98
  std::string flip_str(std::string const& x)
  {
    std::string result = x;
    std::reverse(result.begin(),result.end());
    return x;
  }

You might have chosen to accept the parameter as reference-to-const to avoid unnecessary copying like I did above. But is this really the best thing we can do? To answer this, let’s check what and how a compiler is allowed to optimize (elide copies):

• If a function returns a function-local object (including temporary) it is allowed to elide the copy construction of the function’s result (return value optimization).
• If an object obj of type X is initialized with a temporary of type X, the compiler is allowed to elide this copy and make obj an alias for this temporary. This includes the initialization of pass-by-value function parameters.

Many C++ compiler actually perform these optimizations in many situations. So, in order to write efficient code we should try to exploit this.

If you check the implementation of flip_str version 1 again you’ll notice that I manually created a copy of the string, named result. In this case it’s easy for compilers to perform the named return value optimization. The return expression directly refers to the local object result. But we havn’t exploited temporaries as function arguments. What about this version?

  // version 2, C++98
  std::string flip_str(std::string x)
  {
    std::reverse(x.begin(), x.end());
    return x;
  }

In version 2 we let the compiler worry about how x should come to life. In case the function is invoked with an lvalue argument the compiler will make sure that x refers to a copy. In case it’s a temporary the compiler might be able to elide the copy (x might alias the temporary object). So far so good. What about RVO? You could argue that x is a local variable. But to implement the mentioned copy elision optimizations the compiler probably generated a function that actually takes two addresses behind the scenes — one for the pass-by-value parameter x and one for the to-be-constructed return value. In version 2 the line “return x;” will then copy-construct the return value from x, so no NRVO is done. In C++0x we could simply write

  // version 3, C++0x (relying on a fast move constructor)
  std::string flip_str(std::string x)
  {
    std::reverse(x.begin(), x.end());
    return std::move(x);
  }

Because std::string is a rather small object that only manages the character array through an internal pointer, move constructing strings can be expected to be much faster than copy constructions — unless your std::string implementation uses copy-on-write. Still, it should be at least a bit faster. C++98 doesn’t support move construction directly. But there is a trick to get a similar behaviour in this case. Instead of a move construction we can use swap and rely on NRVO:

  // version 4, C++98
  std::string flip_str(std::string x)
  {
    std::string result; // empty string, expected to be fast
    result.swap(x); // swapping, expected to be fast
    std::reverse(result.begin(), result.end());
    return result; // NRVO applicable
  }

Swapping is a kind of two-way moving. If your type supports fast swapping you should consider writing such a swap member function along with a free inline function and/or a specialization of the std::swap template so that algorithms can benefit from it.

Finally, let’s verify how many times the string‘s copy constructor is invoked in the following example code:

  // test code
  #include <iostream>
  #include <algorithm>
  #include <string>

  using std::string;

  string source() {return "Hello World!";}

  // insert flip_str version 1, 2, or 4

  int main() {
    string hw = flip_str(flip_str(source()));
    std::cout << hw << '\n';
  }

To verify how many times the copy c’tor of string is invoked we could replace the inclusion of the <string> header and the using std::string; declaration with the following dummy class:

  // string replacement for testing
  struct string {
    string()
      {std::cout<<"string::string()\n";}
    string(char const*)
      {std::cout<<"string::string(char const*)\n";}
    string(string const&)
      {std::cout<<"string::string(string const&)\n";}
    ~string()
      {std::cout<<"string::~string()\n";}
    void swap(string & with)
      {std::cout<<"string::swap(string &)\n";}
    char* begin() {return 0;}
    char* end() {return 0;}
  };

With this replacement and the g++ compiler I obtained the following results:

  Output for flip_str version 1 and 2:
  string::string(char const*)
  string::string(string const&)
  string::string(string const&)
  string::~string()
  string::~string()
  string::~string()

The output for version 1 and 2 is exactly the same in this case. Here it is for version 4:

  Output for flip_str version 4:
  string::string(char const*)
  string::string()
  string::swap(string &)
  string::string()
  string::swap(string &)
  string::~string()
  string::~string()
  string::~string()

The use of version 1 results in two copy constructions (total). The same is true for version 2. The use of version 4 didn’t involve any copy constructions. Just two default constructions and two swaps.

Conclusions:
For types that have a fast default constructor and a fast associated swap function we can exploit the compilers’ copy elision capabilities to increase performance. Other examples for these kinds of types include most STL containers (vector, deque, list, set, map, …).

- P

[Edit 2009-08-18: The link doesn't seem to work anymore. However, Dave Abrahams has started to refine, extend, and convert it into a series of blog posts on his new site ]

- P

Occasionally I happen to see a piece of C++ code from an eager author that tries to utilize rvalue references but doesn’t understand them and gets it wrong. I remember that I had trouble fully grasping the rvalue reference concept. But now, it seems like that was way in the past. I can hardly remember why it was so difficult to understand rvalue references.

It may have something to do with the sources people use to learn about this feature. For example I wouldn’t consider the C++0x wikipedia article to be a good introduction for rvalue references. It seems too short for that. But this wikipedia article is a nice overview of what kind of features can be expected.

Let me just mention the real sources worth reading:

• N1377: Move Proposal (2002)
• N1385: Perfect Forwarding Problem (2002)
• N2027: A Brief Introduction to Rvalue References (2006)
• N2812: A Safety Problem with Rvalue References (2008)
• N2844: Fixing a Safety Problem with Rvalue References (Revision 1, 2009)
• Rvalue References 101by Dave Abrahams

I would recommend N2027 as an introduction and Dave Abraham’s article for more practical details including exception safety and return value optimizations.

How do you know whether you got something wrong? Well, if you feel the need to declare a function that returns a reference (be it lvalue reference or rvalue reference) to a function-local object, you got it wrong:

  std::string&& wrong() {
     std::string r = "foo";
     r += "bar";
     return std::move(r);
  }

  std::string right() {
     std::string r = "foo";
     r += "bar";
     return r;
  }

This is an exampe adapted from a piece of code from another author who shall remain nameless. Part of the original author’s confusion is probably due to the name of the function move and the fact that it returns an rvalue reference. Truth is, the function move doesn’t move anything. It just converts an lvalue reference to an unnamed rvalue reference. Only when this unnamed rvalue reference is later used as source in constructing a new object it might actually be a move-construction. But it could also be a copy-construction in case the type doesn’t support moving. In this example you actually don’t need any C++0x specific syntax to benefit from movable string objects. Firstly, returning references to function-local objects is still a no-go. Rvalue references don’t make that any less true. Secondly, the std::move() call is unnecessary. In fact, it may even prevent a common optimization called NRVO. Since this optimization is even better than a move-construction of the return value you should not disable NRVO by being “smart”. The new language rules already force compilers to move-construct return values from function-local objects in case they don’t support (N)RVO or simply can’t apply NRVO in a specific case.

I also saw an early example by Howard Hinnant (one of the authors of the rvalue reference proposal) in which he wrote a function that returned an rvalue reference. It didn’t refer to function-local objects but it referred to a reference parameter object which could have been a temporary and thus led to a dangling reference. He later said that he considers this example to be buggy and dangerous.

  string operator+(string const& a, string const& b) {
     string result;
     result.reserve( a.length() + b.length() );
     result += a;
     result += b;
     return result;
  }

  #ifdef WRONG

  string&& operator+(string && a, string const& b) {
     a += b;
     return move(a);
  }

  #else // correct version following ...

  string operator+(string && a, string const& b) {
     a += b;
     return move(a);
  }

  #endif

The version named “wrong” in this example has an advantage and a disadvantage: It allows the recycling of temporary objects in an expression like get_directory() + "/" + get_name() + ".png" but it also allows the user to bind a reference (rvalue reference or just an ordinary reference to const) to the result which leads to a dangling reference. The 2nd version is much better in terms of safety because of a special rule that makes the compiler extend the life-time of the returned temporary in some cases. Instead of recycling a temporary new temporaries will be move-constructed from old temporaries. This is believed to be a good trade-off.

In this situation we actually need std::move because a named rvalue reference behaves just like an lvalue. Anything that has a name or is an lvalue reference behaves like an lvalue. This includes a named rvalue reference.

Conclusions:

• Read a high-quality introduction to rvalue references before using this feature
• Never ever return references to non-static function-local objects.
• As a rule of thumb: Avoid returning rvalue references to reference parameters. The functions that do so are std::move and std::forward. They serve a special purpose.
• Don’t use std::move on a non-static function-local object in a return expression. The compiler takes care of it already and may be even able to elide the move (NRVO).
• Don’t use std::move on expressions that are known to return an rvalue (temporary object) already. If you do it may disable the RVO optimization.

- P

“function” is a useful library feature of Boost, TR1, and the upcoming C++ standard library. It’s basically a class template mimicing the behaviour of a function pointer. But it’s much more flexible because it applies to any “callable object” — function pointers and objects with overloaded function call operator. Also, the signatures don’t have to match perfectly as long as the parameters and return values are implicitly convertible. I’m going to show you how this library feature can be implemented with C++0x features — including variadic templates and rvalue references. But before going into any details let me give an example of how code that uses this “function” library might look like. In case you’re already familiar with this library feature you can skip the following piece of code and paragraph of text.

  #include <iostream>
  #include <ostream>

  #include "function.hpp"

  using std::cout;
  using std::endl;

  int plus(int a, int b) {
     return a+b;
  }

  int minus(int a, int b) {
     return a-b;
  }

  struct accumulate_products {
     int* pacc;
     accumulate_products(int* p) : pacc(p) {}
     int operator()(int a, int b) const {
        *pacc += a*b;
        return *pacc;
     }
  };

  int main() {
     function<int(int,int)> f = plus;
     cout << f(23,17) << endl;
     f = minus;
     cout << f(23,17) << endl;
     int accum = 0;
     f = accumulate_products(&accum);
     f(1,2);
     f(3,4);
     f(5,6);
     cout << accum << endl;
  }

As you might have noticed, the template parameter is actually a function signature. This example shows how we can assign function pointers to this object as well as some other function object.

As far as the C++ language is concerned this function signature is only one template parameter. Do we even need variadic templates for this? Yes, we do. We do because we want to support functions that take any number of parameters. This is what “variadic” is all about. What I’m going to do is to partially specialize the class template “function” with a template taking a variable number of type parameters. One for the return type and zero or more for the function’s parameter types. The rvalue reference feature is used to achieve both: move semantics and perfect forwarding. You may also notice some other tricks: “C++ type erasure” for runtime polymorphism, “copy & swap” for efficient and exception-safe assignment. Without further ado, here’s the content of the file “function.hpp”:

  #ifndef FUNCTION_HPP_INCLUDED
  #define FUNCTION_HPP_INCLUDED

  #include <utility>    // std::move, std::forward
  #include <algorithm>  // std::swap

  template<typename R, typename ... P>
  class abstract_callable
  {
  public:
     virtual ~abstract_callable() {}
     virtual R operator()(P ... p) = 0;
     virtual abstract_callable* clone() const = 0;

     template<typename F>
     // requires std::CopyConstructible<F>
     //       && std::Callable<F&,P...>
     //       && std::Convertible<std::Callable<F&,P...>::result_type,R>
     class wrapper /*[[check_names]]*/ : public abstract_callable
     {
     public:
        explicit wrapper(F const& f) : func(f) {}
        explicit wrapper(F && f) : func(std::move(f)) {}
        R operator() /*[[override]]*/ (P ... p) {
           return func(std::forward<P>(p) ...);
        }
        abstract_callable* clone /*[[override]]*/ () const {
           return new wrapper(*this);
        }
     private:
        F func;
     };
  };

  template<typename Signature>
  class function;

  template<typename R, typename ... P>
  class function<R(P...)>
  {
     typedef abstract_callable<R,P...> ac_type;
  public:
     typedef R result_type;

     function() : ptr(0) {}

     template<typename F>
     // requires std::CopyConstructible<F>
     //       && std::Callable<F&,P...>
     //       && std::Convertible<std::Callable<F&,P...>::result_type,R>
     function(F f) : ptr(0) {
        typedef typename ac_type::template wrapper<F> wrapper_t;
        ptr = new wrapper_t(std::move(f));
     }

     function(function const& f) : ptr(f.ptr->clone()) {}
     function(function && f) : ptr(f.ptr) {f.ptr=0;}
     ~function() { delete ptr; }

     void swap(function & f) {
       using std::swap;
       swap(ptr,f.ptr);
     }

     function& operator=(function f) {
       swap(f);
       return *this;
     }

     R operator()(P ... p) const {
       return (*ptr)(std::forward<P>(p) ...);
     }
  private:
     ac_type* ptr;
  };

  template<typename Signature>
  inline void swap(function<Signature> & f1, function<Signature> & f2) {
     f1.swap(f2);
  }

  #endif // FUNCTION_HPP_INCLUDED

There you go! This compiles with the option -std=c++0x and seems to work (I didn’t test it that much).

Try implementing it with C++03 (current C++) and you’ll end up writing many more lines to support up to N function parameters. For every number of parameters you need to write a specialization. Sure, with a bit of macro trickery you can reduce the typing effort but the number of lines of code the preprocessor will emit is still very high. Also, without perfect forwarding you have to think about how parameters are accepted and forwarded to the next function. There’s no perfect solution for that in C++03.

Besides variadic templates and rvalue references I hinted at two other features. Have you spot it? I commented them out with because GCC does not yet support concepts and attributes. The idea behind these kinds of attributes is to make the compiler check the member functions’ names and reject the code if something doesn’t add up. But this has not yet been voted into the draft. It’s just a proposal for now. The concepts part makes the compiler type-check the templates some more and generate error messages that are hopefully human-readable in case the user tries to assign incompatible function pointers/objects.

Finally, I’d like to mention that this implementation is just a simple demonstration. There’s some room for improvement. I think it’s reasonable to expect that a good standard library implementation will outperform this simple version for “small” function objects such as raw function pointers and reference closures.

- P

  struct foo {
    foo();
  private:
    foo(const foo& rhs);
  };

  void func1(const foo&);

  void func2() {
    foo o;
    func1( o ); // ok
    func1( foo() );  // ill-formed, foo's copy-ctor is private
  }

Although an rvalue is allowed to bind to a reference-to-const, the C++ standard allows a compiler to copy an rvalue to another temporary rvalue before binding it to a reference-to-const. Obviously, you need to have a public copy constructor for that.

I really fail to see the merit in this rule. It seems that every available C++ compiler does not create an extra temporary object here and some of these compilers don’t even bother to report an error in this situation (g++ version 3.4.5 accepts the above code).

Fortunately, the upcoming version of the C++ standard removes the CopyConstructible requirement for reference binding. It makes the code above well-formed.

Source: this usenet thread

- P

I recently added two other books to my personal library: “Effective C++” and “C++ Coding Standards”. It took me only 3 weeks to finish both books. That means they were interesting and insightful.

Now, it’s these four C++ books that are in my posession:

• The C++ Programming Language (Special Edition) by Bjarne Stroustrup
• Modern C++ Design by Andrei Alexandrescu
• Effective C++ (Third Edition) by Scott Meyers
• C++ Coding Standards by Herb Sutter & Andrei Alexandrescu

I wouldn’t mention them here if I didn’t like them.

- P

Concepts and rvalue references are two new features that are going to be included in the next official version of the C++ language with high probability. I’m not going to mention the basics behind those two features because it has been done before in other articles. Try this google video or this article for an introduction to concepts by Doug Gregor and this article for an introduction to rvalue references by Howard Hinnant et al.

I already wrote a post on concepts and rvalue references here which discussed some problems when concepts are combined with rvalue references. It turned out that David Abrahams and Doug Gregor were also aware of the first issue I addressed. They published an article one day before I wrote about it. In this post I’m going to address other arguments (consistency and intuitivity) for why I think their proposed resolution is a good idea and what other language modification can increase consistency. Before I go into the last bit I will shed some light on what function requirements actually mean and how they can be satisfied.

Update 2009-02-1:[ It turns out you can't exprapolate the meaning of function requirements from the concept_map checking rules because they don't cover all use cases in constrained contexts (see hole in concepts system). So, keep this in mind while reading the rest of this article.]

Let’s recap: Under current rules an rvalue reference can bind to both rvalues and lvalues. This is likely to cause trouble in cases where we rely on overload resolution between & and && to pick the correct function when concept requirements or SFINAE is involved and a const& overload is removed silently. I’m in total agreement with the article by Abrahams and Gregor and their proposed resolution. Also, the current rules w.r.t. the meaning of reference types and reference qualifiers is slightly inconsistent, especially among different contexts including concepts. The proposal by Abrahams et al improves the situation in terms of consistency, too.

Reference types: & may bind to lvalues only. const& may also bind to rvalues. && is allowed to bind to both: rvalues and lvalues. The current proposal N2800 also includes an extension of the rvalue reference proposal to *this for member functions. However, it is not 100% consistent with respect to the meaning of && as used in the basic proposal. The ref qualifer & added after a member function declaration prevents the function from being callable on rvalues. The ref qualifier && prevents the member function from being callable on lvalues. In isolation this seems like a very reasonable way to go for member functions and ref qualifiers since the lack of a ref qualifier makes the function callable in both cases. But the meaning of && is obviously slightly different. The proposed resolution by Abrahams and Gregor — making && generally bind only to rvalues — would unify the meaning of && here. This is a good thing — after all, they are called rvalue references.

Reference types in concepts: The meaning of reference types and ref qualifiers for function requirements in concepts is special. A function requirement is not the same as a function prototype for which a function definition must exist that uses exactly the same signature. A function requirement is more easily satisfied. Think of function requirements as “invocation signatures”. They define what kind of invocation expressions are guaranteed to be well-formed. Here is an example:

  concept HasFoo<typename T> {
    void foo(T);
  }

  long foo(long);

  concept_map HasFoo<int> {} // OK

You see that it’s OK to have a function with a slightly different signature. The important thing is that the requirement only guarantees a specific invocation expression to be well-formed. An int can be implicitly converted to a long and the function’s result is always “convertible” to void. Implicit conversion is not the only thing that might differ. The function foo could also have accepted a const& parameter as long as the invocation expression implied by the concept’s function requirement is well-formed. In this case the expression is foo(p) where p is of type T. For T=int this expression is obviously well-formed because of long foo(long). Question: What do you think is the meaning of the following function requirement:

  concept HasFooRvalRef<typename T> {
    void foo(T&&);
  }

Under current rules a function that is declared like this accepts both: rvalues and lvalues. You know that by now. But in the context of concepts this is a function requirement. It is satisfied — according to section 14.9.2.1 — if the expression foo(x) is well-formed where x is an rvalue of type T. So, the only thing this function requirement guarantees is that the function foo can be invoked with an rvalue argument of type T. Note: There is no word on lvalues. Invoking foo with an lvalue argument of type T is not part of this concept and thus can’t be used in restricted templates unless there is also some other requirement specifically allowing this. Again, the proposed resolution by Abrahams and Gregor would unify the meaning of && here.

Finally let’s look at how member function requirements can be satisfied. Remember that a member function that is declared without a ref qualifier can be invoked on rvalues and lvalues. What do you think the following concept means?

  concept HasMemberFoo<typename T> {
    void T::foo();
  }

  template<HasMemberFoo T>
    requires DefaultConstructible<T>
  void test(T& lvalue_ref) {
    lvalue_ref.foo(); // OK?
    T().foo(); // OK?
  }

The question is: Will this compile? To answer this we need to check again section 14.9.2.1 of N2800. It says that the expression ‘E’ that needs to be well-formed in order to satisfy this member function requirement is x.foo() where x is an lvalue of type T. So, the concept doesn’t say anything about the function foo being callable on rvalues despite its requirement’s appearence. Actually, there is no difference between this concept and the following one:

  concept HasMemberFooRef<typename T> {
    void T::foo() &; // <-- added ref qualifier
  }

This is because the implied expression ‘E’ that needs to be well-formed is exatly the same. Only in the case of && as a ref qualifier instead the x in the expression is treated as an rvalue of type T — which in turn doesn’t say anything about lvalues. But this is actually no problem because it is what we expect from the && qualifier for member functions. So, the latter case is consistent.

In case you’re still with me you will probably agree with me that the satisfaction rule for a member function requirement that lacks a ref qualifier is counter-intuitive. Such a requirement looks like a promise for being able to call the function on rvalues as well as lvalues just like it is the case in good old C++98. This is why I’d like to propose changing this satisfaction rule a bit. In terms of consistency and intuitivity it seems best to require that such a member function requirement is satisfied only when it can be invoked on lvalues and rvalues. Instead of requiring only one expression “E” to be well-formed we would require two expressions “E1″ and “E2″ to be well-formed that only differ in x being an lvalue in E1 and an rvalue in E2. This change of the rule would not render the C++ language less expressive as far as I can tell. But it would certainly increase consistency with respect to the behaviour of ref qualifiers (or lack thereof) for member functions when both contexts (declaration versus requirement) are compared.

If you want to comment on my proposal to change the rules in 14.9.2.1 please consider writing a response for this usenet thread.

- P

]]>