Steve Robb

Oddly enough, today I just added the first do-while loop into our year-old codebase.  It's not something I like to do often, but it's occasionally useful.  It was the do-while-false idiom which some people may not be aware of:

http://blog.slickedit.com/2007/05/do-while-false/

The idea is to introduce a non-looping block from which you can break in order to perform simple 'local exception handling' when errors occur.  In my case, I was reading a nested JSON object returned from Facebook and if any part of it wasn't in the format I expected, I wanted to ignore it:

do {
    auto& picture = json["picture"];
    if (!picture.IsObject())
        break;

    auto& pictureData = picture["data"];
    if (!pictureData.IsObject())
        break;

    auto& pictureUrl = pictureData["url"];
    if (!pictureUrl.IsString())
        break;

    // Do something with pictureUrl.GetString() here
} while (false);

The alternatives would be:

• Actual exceptions - overkill, much uglier, slower and not an option in my exceptions-disabled codebase.
• Invert the conditions and have increasingly-indented code - ugly and doesn't scale.
• goto the end of the block - not terrible, but goto is not politically-correct.  Also, I think the block makes the intended scope of the feature clearer.
• Introducing a function which you can return from early - probably not too bad in this case, but often you need to pass a lot of the context from the original function to make it work.  Also, the function has no real meaning in and of itself - it is only being used to avoid a goto or do-while-break construct.

do-while-false also has benefits in multi-statement macros:

http://kernelnewbies.org/FAQ/DoWhile0

Great interview, but Herb makes a surprising mistake around 19 minutes in.  They're talking about this kind of construct:

template <typename T>
class C : public T
{
};

... and Herb refers to it as the Curiously Recurring Template Pattern.  The CRTP actually looks like this:

class C : Base<C>
{
};

What they are talking about is a Parameterised Base Class:

http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Parameterized_Base_Class

('C<T> inherits T' vs 'C inherits T<C>')

Hi Damien,

Thanks for replying and I understand all of your points.  Let me just clarify that when I said 'worse than NULL', I meant bigger and uglier in the code, e.g. MYLIBRARY_NULLPTR or something, as opposed to the semantics which are obviously much better.

However, in general, a C++ library author (such as myself) cannot know in advance whether or not his library will be used in a C++/CLI build or not and, to prevent this being a problem, needs to avoid anything that will cause portability issues.  In this case, avoiding nullptr in favour of 'good old 0'.  Obviously this would only be where the semantics don't matter; fortunately, in a template library, you tend to only need to care about the types coming in, rather than the ones you use in the implementation.  But it would've been nice as a self-documentation feature.

Template libraries already have to deal with different compilers (and versions of each compiler) for different reasons; it would've been nice if this otherwise-great new feature didn't have to be avoided or made a special case.

Regarding the problems with nullptr and C++/CLI.  Does this mean that a third-party template library that uses nullptr (rather than __nullptr) in its headers will be unable to be included in any C++/CLI project?

This is a perfectly feasible situation even in interop code, where you have a C++/CLI type wrapping a C++ type which contains a member from this template library.

This would seem to leave the template library little choice but to define a macro to map to either nullptr or __nullptr depending on whether it's a C++/CLI build or not (which it shouldn't care about, since it's a pure C++0x library), which ends up being worse than the NULL macro!