Concepts are supposed to bring soundness in through constrained templates. Concepts look awfully a lot like type classes; they export functions and types, and are parameterized, and act as constraints on generic functions and other concepts. I checked the draft specification [2], and it even seems to permit parameterizing concepts on type constructors, just like Haskell! (er, C++ calls them class templates, not type constructors. to-may-to, to-mah-to)

But I worried I may be mistaken about concepts, as I’ve searched through google and literature and have yet to find a single example in literature demonstrating the use of template template concepts.

In case you’re curious what this might look like, here’s an educated guess:

concept Monad<template <> class m> {
  template<typename T, typename U>
  m<U> mbind(m<T>, function<m<U>(T)>);
 
  template<class T>
  m<T> mreturn(T);
};
 
template <template <typename> class m,
          class T,
          class U,
          class Iter>
requires M<m>
requires InputIterator<Iter, U>
m<T> foldM(Iter begin, Iter end, T i, function<m<T>(T, U)> f)
{
    if(begin == end)
        return mreturn(i);
    else
        return mbind(f(i, *begin), [=](T result){
            Iter next = begin;
            ++next;
            return foldM(next, end, result, f);
        });
}

Have template template concepts been covered thoroughly somewhere, and I’ve just missed it?

• [1] “C++ templates/traits versus Haskell typeclasses” (2005), by Sunil Kothari, Martin Sulzmann.
• [2] “Proposed Wording for Concepts (Revision 5)” (2008).
• [3] “Trip Report: Exit Concepts, Final ISO C++ Draft in ~18 Months” (2009), Herb Sutter.
• [4] “ConceptClang: An Implementation of C++ Concepts in Clang” [pdf]

They reported that if they compiled code which calculated: 1130149156 >> -05701653 it generated different results on 32bit and 64bit operating systems. On 32bit machines it reported 0 but on 64bit machines, it reported 0x21a.

This is one of various areas of “undefined behavior” for which you can ask 2 engineers what it should do and get 3 answers, at least one being that “but I know there must be one!” I think I know where at least 2 of the answers are coming from …

The Hardware shift

On x64, Larry mentions that the sar instruction is used to carry out the operations. This instruction is not new to the x86 architecture, and in that architecture line’s early days you did not waste die space. So what’s cheap?

Enter the barrel shifter. It’s cheap, it’s small, you pick the maximum power-of-2 shift you want, and that’s what you pay for. For a 16-bit shift, you can support shifts of 0 to 15 and pay for 4 stages. If you want to shift out all 16, you might think “add another stage” — but it gets worse! It only takes rotation as input. If you need to identify greater shifts than 31, then you’re toast.

No, what you consider doing is detect shifts > 15, and add a an extra stage to mask away the entire output. But wait, it’s 1972, and you don’t have either the die space nor the extra cycles to waste on a conditional masking stage (masking to 4 bits of shift input is free — you just don’t connect the other 12 input bits to anything). You just tell the programmer to never shift too much, use the bottom most bits, and ignore the rest. (1 >> 128) == 1.

In time the processor is expanded to support 32-bit quantities and 64-bit quantities, but each time you need to remain compatible, so the sar instruction continues to mask away the upper bits.

The Programming Language

I’m gonna gloss over the whole “undefined behavior” thing. Enough others have discussed it. Even languages or implementations which aim to minimize it will occasionally miss edge cases or fall short.

And C takes a very brutal route of making a great many things “undefined behavior” in the name of permitting performance shortcuts. For instance, signed arithmetic overflow yields undefined behavior. This might seem strange now, but at the time 2′s compliment arithmetic was not common. Choosing 2′s compliment wrap-around would have introduced perf penalties on 1′s compliment architectures as they did not generally include native 2′s compliment instructions, and vice-versa. A modern spin on this are special purpose DSP chips that default to saturating arithmetic.

In any case, I imagine a similar case stands for shifting. One architecture may prefer precise shifting, but x86 prefers to take shifts in modulo. Rather than specify one behavior and penalize compilation on all other hardware, the C language says instead “this area off limits — if you want a particular slow-but-precise behavior, implement it yourself”

The Software Shift

The 32-bit x86 CRT routine mentioned was _allshr (the extra leading underscore comes from cdecl calling convention on x86), and you can find its source in your Visual C++ product installation, under %programfiles%/Microsoft Visual Studio 10.0/vc/crt/src/intel/llshr.asm. It leads off:

;
; Handle shifts of 64 bits or more (if shifting 64 bits or more, the result
; depends only on the high order bit of edx).
;
        cmp     cl,64
        jae     short RETSIGN

Interesting — for large shifts, it bails early. Following it is another branch, switching between different implementations for 0-31 and 32-63 bit. In any case, the resulting 3 code paths are short, with the cl >= 64 path being the shortest of all.

Now, the designer could have considered masking instead of comparing — but for random shift amounts, that would have been a longer code sequence to execute*. And by most reasonable interpretations, returning the sign bit is the right answer.

So there you have it

Each implementation is most efficient and reasonable, when and where it was designed, and both are permitted by a language standard that valued efficiency above most else. And in that respect, both implementations were perfect … at least, they were when originally written.

* yes, the conditional branch is probably a bigger cost than the savings… today. While I don’t know when this code was written, it mentions PROC NEAR, leading me to think that perhaps it comes from a time before superscalar architectures, where branches were cheap(er) and arithmetic was costly. You might be want to change it now, but that decision opens up back-compat questions.

#include <iostream>
using namespace std;

int fibonacci(int x) {
    int a=0, b=1, temp;
    while(x?(--x,temp=a,a=b,b=temp+b):0);
    return a;
}

int main() {
    int i = 0;
    while(i<10&&(cout<<"fib("<<i<<")="<<fibonacci(i)<<'n',++i));
}

Yeah. That was terrible. Terrible awesome. But looking back, I’m realizing that some of the comma abuse is superfluous:

int fibonacci(int x){
    int a=0, b=1;
    while(x?(--x,a=((b=a+b)-a)):0);
    return a;
}

Don’t let anyone check in code like this, ever.

Native client is 50KB download?  Wild. It really is just a gatekeeper, runtime library separate.

Of course, I would love to get away from x86.  LLVM, or ARM, or even Amd64.  x86 makes me a sad panda.

This is one of those “religous wars” in programming language theory; return code handling (RCH) vs exception handling (EH).  Firstly, I am biased.  Secondly, I will try to remain objective as well, partitioning observations of code using these mechanism from how I feel this reflects on the utility of either mechanism.  I tend to _prefer_ EH in general, but not universally, and generally follow the viewpoint that “exceptions are for exceptional things”.  With that aside…

Raymond Chen wrote an article a while back on RCH vs EH^[2]. There, he points out accurately some facts about code review of RCH and EH, concluding that it’s generally harder to conclude the failure-safety of some example the RCH code than some comparable EH code.

He’s right.  And he’s wrong.  His article is incomplete.  Lets start with defining the playing field.

Return Code Handling

Below, we have two versions of RCH-style code. All failures are communicated via return code. The left version is an erronous example, the failure paths have not yet been considered. The right version has corrected this fault.

BOOL ComputeChecksum(LPCTSTR pszFile, DWORD* pdwResult)
{
    HANDLE h = INVALID_HANDLE; 
    HANDLE hfm = INVALID_HANDLE; 
    void *pv;
    DWORD dwHeaderSum;

    h = CreateFile(...);

    hfm = CreateFileMapping(h, ...);

    pv = MapViewOfFile(hfm, ...);

    CheckSumMappedFile(... &dwHeaderSum, pdwResult);

    UnmapViewOfFile(pv);
    CloseHandle(hfm);
    CloseHandle(h);
    return TRUE;
}

BOOL ComputeChecksum(LPCTSTR pszFile, DWORD* pdwResult)
{
    HANDLE h = INVALID_HANDLE; 
    HANDLE hfm = INVALID_HANDLE; 
    void *pv = NULL; 
    DWORD dwHeaderSum;
    BOOL result = FALSE;

    if ( (h = CreateFile(...)) == INVALID_HANDLE)
        goto cleanup;
    if ( (hfm = CreateFileMapping(h, ...) 
          == INVALID_HANDLE ) )
        goto cleanup;
    if ( (pv = MapViewOfFile(hfm, ...)) == NULL )
        goto cleanup;

    CheckSumMappedFile(... &dwHeaderSum, pdwResult);
    result = TRUE;

    cleanup:
    if (pv) UnmapViewOfFile(pv);
    if (hfm != INVALID_HANDLE) CloseHandle(hfm);
    if (h != INVALID_HANDLE) CloseHandle(h);
    return result;
}   

The left side looks very clean, and very clearly does no RCH, so according to Chen’s method it is clearly incorrect. According to [2], the left one is ‘Really Easy’ to write, and ‘Really Easy’ to recognize as being incorrect. The lack of an if-statement every 2 lines is a red flag. Basically, you must explicitly write every possible success and failure code path, even the “uninteresting” ones.

Let’s move on to the EH example from Chen’s post.

Exception Handling (old style)

Bellow is adaptation of both the incorrect EH code from his article, along with a possible fix.

NotifyIcon* CreateNotifyIcon()
{
    NotifyIcon* icon; 

    icon = new NotifyIcon();

    icon.set_text("Blah blah blah");
    icon.set_icon(new Icon(...), GetInfo());
    icon.set_visible(true);

    return icon;
}

NotifyIcon* CreateNotifyIcon()
{
    NotifyIcon* icon = 0;

    icon = new NotifyIcon();
    try {
        icon.set_text("Blah blah blah");
        icon.set_visible(true);
        Info info = GetInfo();
        icon.set_icon(new Icon(...), info);
    } catch (...) {
        delete icon; throw;
    }
    return icon;
}

I totally agree with any and all critics that the above style of code is tough to diagnose. If any of { set_text, set_icon, set_visible, or get_info } can throw, the left code is totally busted. The code to the right is tricky… by moving GetInfo to a separate line, and set_icon to the end, the Icon object can’t be leaked (presumably set_icon is responsible for freeing the Icon in failure conditions). The try-catch will delete NotifyIcon and propogate the exception, but not without having made this program a pain to debug – we will see two exception raise events now instead of just one.

Even worse, tomorrow this code could become incorrect again – if the copy-constructor for Info can throw, the right side code is still wrong. I bet you didn’t think of that. Think you’re an expert at this? Try item #18 in Exceptional C++^[3]. I think my first time I found about 16 code paths in the 3 lines of C++ code, barely teetering into ‘Guru’ category, but I spent like 15 minutes on it. Normally you have 5 seconds during a code review, and you won’t find all 23 code paths in 5 seconds. You have to do better than analyzing ever code path.

Applying Raymon Chen’s categories, getting to the correct code is “Really Hard”, and I hope the audience agrees with me. It is hard. Any line of code, any subexpression could throw, and we have to look at all those possible cases. RCH certainly looks better. Sure, we’d have to have like 9 ‘if’ statements to bring the above code in line, but at least then we could see that we covered all the code paths. But there is no general rule we can apply to see if it is trivially incorrect. In RCH, a line without a conditional branch is suspect. In EH (old style), a line without a try-catch after resource acquisition is suspect.

I call this ‘old style’ because it looks a lot like how you’d handle exceptions in C#, or in C++ without any library support back in 1990. Stephan T. Lavavej makes a distinction between “archaic C++” and “modern C++”^[4]. And Raymond Chen notes in parting words, “Yes, there are programming models like RAII and transactions, but rarely do you see sample code that uses either.” – let’s remedy this situation.

Exception Handling (modern)

On the left, we have some bad RAII exception handling code, to parallel Chen’s original bad example. On the right, the ‘fixed’ version.

shared_ptr<NotifyIcon>
CreateNotifyIcon()
{
    NotifyIcon*
      icon( new NotifyIcon() );

    icon->set_text("Blah blah blah");

    icon->set_icon(
        shared_ptr<Icon>( new Icon(...) ),
        GetInfo());

    icon->set_visible(true);

    return icon;
}

shared_ptr<NotifyIcon>
CreateNotifyIcon()
{
    shared_ptr<NotifyIcon> 
        icon( new NotifyIcon() );

    icon->set_text("Blah blah blah");

    shared_ptr<Icon> 
        inner( new Icon(...) );
    icon->set_icon(inner, GetInfo());

    icon->set_visible(true);

    return icon;
}

I’m changing the rules. I don’t care how many branches there are, success or failure branches. What I do care about is that, at every point of time, there is exactly one owner for ever resource, and that in a general failure condition, that owner will take care of the resource.

That is the fundamental change. Modern C++ code using RAII does not generally have any explicit code for failure conditions. General failures are always handled non-locally. Local resource management is immediately handled by automatic objects, using RAII. Any raw resources (such as allocating a new object) must immediately be handed off to an RAII object.

Lets take a closer look at what I find wrong with the left example.

• First line, we have a raw pointer. Bad. RAII rule: raw pointers == suspect code.
• Second line, set_text. No raw resources. Good.
• Third line, shared_ptr is mixed in with another call. Bad. Move to a separate line.
• Last line, set_visible, also good.

How do we know we are done? When there are only two kinds of statements – RAII object initialization, and useful code that doesn’t create unadorned resources. Now, it is admittedly hard to get some RAII classes right in the first place, but that only needs to be done once per class, instead of once per use.

While it is still hard to see all the code paths, it becomes really easy to check if the developer has finished EH. Any resource allocation without RAII will tell you that the developer didn’t finish. Sure, bad RCH code pops out like a rose in a weed garden, but with RAII you can usually skip writing the bad code in the first place – just jump directly to shared_ptr<T>, or shared_factory<HANDLE, close_handle>::type, or scope_guard<T>, etc. You can skip writing the bad code at all, and do all your failure handling via RAII.

Final Thoughts

So, we have a new table for recognizing code:

And here’s how I believe modern EH with RAII fits in Raymond Chen’s table.

Finally, I’ll leave you with my interpretation of RCH vs. EH (modern).

HRESULT
CreateNotifyIcon(NotifyIcon** ppResult)
{
    NotifyIcon*      icon = 0;
    Icon*            inner = 0;
    const wchar_t *  tmp1 = 0;
    HRESULT          hr = S_OK;

    if ( SUCCEEDED(hr) ) {
        icon = new (nothrow) NotifyIcon();
        if ( !icon ) hr = E_OUTOFMEM;
    }

    if ( SUCCEEDED(hr) )
        hr = icon->set_text("Blah blah blah");

    if ( SUCCEEDED(hr) ) {
        inner = new (nothrow) Icon(...);
        if ( !inner )
            hr = E_OUTOFMEM;
        else {
            Info info;
            hr = GetInfo( &info );

            if ( SUCCEEDED(hr) )
                hr = icon->set_icon(inner, info);
            if ( SUCCEEDED(hr) )
                inner = NULL;
        }
    }
    if ( SUCCEEDED(hr) )
        hr = icon->set_visible(true);

    if ( SUCCEEDED(hr) ) {
        *ppResult = icon;
        icon = NULL;
    } else {
        *ppResult = NULL;
    }

    cleanup:
    if ( inner ) delete inner;
    if ( icon ) delete icon;
    return hr; 
}

shared_ptr<NotifyIcon>
CreateNotifyIcon()
{
    shared_ptr<NotifyIcon> icon;//[5]
    shared_ptr<Icon>       inner;

    icon.reset( new NotifyIcon() );
    icon->set_text("Blah blah blah");

    inner.reset( new Icon(...) );
    icon->set_icon(inner, GetInfo());
    icon->set_visible(true);

    return icon;
}

Footnotes:

1 – C++ FAQ Lite, Section 17 “Exceptions and error handling” http://www.parashift.com/c++-faq-lite/exceptions.html

2 – Raymond Chen, “Cleaner, more elegant, and harder to recognize” http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.aspx

3 – Herb Sutter, “Exceptional C++”, http://www.amazon.com/Exceptional-C%2B%2B-Engineering-Programming-Depth/dp/0201615622/

4 – Stephan T. Lavavej, aka STL, “Modern C++” http://nuwen.net/14882.html

5 – some may note that auto_ptr (or unique_ptr in C++0x) may provide better efficiency, and safely auto-converts to shared_ptr. That is another alternative.  Just don’t use raw ptrs and make sure to review Effective C++ on auto_ptr safety.

As a refresher, memoization is a dynamic programming technique used to optimize the time to solve problems where partial problems overlap frequently.  For example, in the recursive definition of the Fibonacci sequence, F(x) = { 1 : x < 2,  F(x-1)+F(x-2) : x>=2 }, at each stage, you compute the solution by taking the results from two separate computations.

So, walking briefly through, get the C++ bootstrapping out of the way.  To start, we include the standard module’s we’ll be using:

#include <iostream>
#include <iomanip>
#include <map>

Next up, the memoizer — this is a helper class that will record the results for us. 

template <
    class Result, 
    class Arg,
    class ResultStore = std::map<Arg, Result>
>
class memoizer1{
public:
    // accelerate 'f' by remembering partial results
    template <class F>
    const Result& operator()(F f, const Arg& a){
        typename ResultStore::const_iterator it = memo_.find(a);
        if(it == memo_.end()) {
            it = memo_.insert(make_pair(a, f(a))).first;
        }
        return it->second;
    }
private:
    ResultStore memo_;
};

We’ll separate the definition of fibonacci function from the public surface so that the memoizer can be applied later

int fib(int);

namespace {
    // instrumentation, track number of uses
    int total_ops = 0;

    // implementation
    int fib_(int n){
        ++total_ops;
        if(n == 0 || n == 1) 
            return 1;
        else
            return fib(n-1) + fib(n-2);
    }
}

Lastly the driver function will decorate the implementation with a memoizer, and a prompt loop.  You should be able to copy-paste the code into a cpp file, comple, then run.

// driver function
int fib(int n) {
    static memoizer1<int,int> memo;
    return memo(fib_, n);
}

using namespace std;

int main(){
    cout << "fibonacci numbers, memoized, ctrl+z to quitn";
    for(;;) {
        cout << "enter integer: ";
        int x;
        if(!(cin >> x))
            break;

        total_ops = 0;
        int y = fib(x);

        cout << "fib(" << x << ") == " << y << endl;
        cout << "cost was " << total_ops << endl;
    }
}

And that’s the complete program.  Trying it with a few inputs, you’ll see few number of operations.  To see the non-memoized results, you need only comment out the code for ‘fib()’ and have it invoke ‘fib_’ directly — the results will slow to a halt around x=30 to 35.

By using a look up table, each time ‘fib’ is invoked with a given value of ‘x’, the result is stored so it doesn’t need to recurse again.  A hash table, or even a dynamically sizing array (std::vector) could have also been used in this case, but may not be appropriate for other problem spaces.