Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
E2E: Herb Sutter and Erik Meijer - Perspectives on C++
Jan 17, 2011 at 8:13 AMGreat 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
Oct 29, 2009 at 6:14 AMHi 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
Oct 23, 2009 at 5:39 AMRegarding 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!