Andrei Alexandrescu

Martin Nowak found a bug in my generalized palindrome implementation, sigh. There are many possible fixes, his proposed one being among the simplest.

The idea here is that if the range is left at exactly one element, it can't be reduced from both sides (one size suffices).

bool palindrome(Range)(Range range) {
    for (; !range.empty; range.popFront(), range.empty || range.popBack()) {
        if (range.front != range.back)
            return false;
    }
    return true;
}

@c9xeo: Apologies, you're right; I tried to simplify from a larger example I gave at C++ and Beyond and ended up bloating myself. The correct code is:

template <
  typename T,
  template<class...> class... Policies
>
class ICantBelieveItsNotButter;

Thanks for the correction!

@c9xeo: Actually the code is correct as is. Similarly, when you define a function that takes a pointer to a function you don't need to specify names for the inner parameters:

    void fun(void (*pFun)(int xyz));

is the same as

    void fun(void (*pFun)(int));

I got word that the video is in processing and will come out later today. Thanks for your interest!

@Garfield: Thanks for your comment. I believe I've argued my point properly, and my understanding is that Herb agreed with it. As @mcmcc mentioned, it's all rooted in the inescapable reality that creating a new composite object is sometimes more expensive than modifying an existing object. This issue gets compounded by repeated execution. As an example, we all know we do good to repeatedly refill the "current line" when reading text from a large file, as opposed to creating a new string upon each read. Rvalue references repair what could be considered a large gratuitous waste - but they don't do miracles, and we shouldn't expect them to.

Thanks, "true". Erwin Unruh indeed. In our defense, his name contains all of the letters in "Uwe" :o).