Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Steve Robb

Steve Robb Fuz

Niner since 2009

C++ library developer
  • Stephan T. Lavavej - Core C++, 8 of n

    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

  • E2E: Herb Sutter and Erik Meijer - Perspectives on C++

    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>')

  • Stephan T. Lavavej: Everything you ever wanted to know about nullptr

    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.

  • Stephan T. Lavavej: Everything you ever wanted to know about nullptr

    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!