Steve Robb

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!