Bill Dog's Journal: class template inheriting from specialization of itself?!?

I'm going thru a book called "C++ Gotchas". It uses a very good format -- a collection of 99 relatively stand-alone articlettes, each only a couple or four pages long. A big advantage being that I can read one or two points before bed each night, without having to consciously devote say an hour at a time to absorb a complete chapter (to complete the thought) as with a regular book. The downside of the book is that the content hasn't been the greatest. And a big part of that has been its not exactly textbook-quality code. For Gotcha #83 that I quit in the middle of, night before last, confounded by what I saw, he has:

template <class T> class PtrList;
 
template <> class PtrList<void> {
  public:
    void append( void *elem )
        { impl_.push_back( elem ); }
// . . .
  private:
    std::list<void *> impl_;
};
 
template <class T>
class PtrList : private PtrList<void> {
  public:
    PtrList()
        {}
    ~PtrList()
        {}
    void append( T *newElem );
// . . .
};
 
template <typename T>
inline void
PtrList<T>::append( T *newElem )
    { PtrList<void>::append( newElem ); }
 
PtrList<Employee> staff;
staff.append( new Techie );

So first he's forward declaring the (so far) incomplete type PtrList<T>. Then he defines a template specialization of it, PtrList<void>. Then he proceeds to finish defining PtrList<T> by privately inheriting from PtrList<void>. Why? Private inheritance is a syntactic variant of composition, where just straigtforward composition is usually preferred. I can't seem to fathom what the benefit(s) are of this design, "containing" a template of oneself that holds a container of void pointers, versus just one class template that contains a std::list< T* >.

That's why it's a gotcha

[Marxist Hacker 42]

The positive aspect is that you've now got a recursively searchable linked list, in which every node points to a full copy of the list as well as to it's parent and child.

The negative aspect is that this is complete bunk and will lead to circular references that will turn your recursion into an infinite loop.

Re:

[Bill Dog]

The topic of the gotcha (maybe I shouldn't have left that out) was just to not confuse ownership and wind up with memory leaks, when you have a container of pointers. Which is why such a violently obtuse implementation distracts from the topic, and detracts from the quality of the book overall, IMO.

As to your guess, Employee's details were not specified, so it is unknown whether it contains a pointer that could be set to point to the beginning of the list it lives in. I can't really imagine what that pointe

Re:

[Marxist Hacker 42]

The topic of the gotcha (maybe I shouldn't have left that out) was just to not confuse ownership and wind up with memory leaks, when you have a container of pointers. Which is why such a violently obtuse implementation distracts from the topic, and detracts from the quality of the book overall, IMO.

I'd agree, that's a stupid way to do it. There's a much easier way that I learned early on in C class- forget to allocate enough memory.

As to your guess, Employee's details were not specified, so it is unkno

Re:

[Bill Dog]

Something far too many C and C++ programmers forget is that a pointer's data type (regardless of apparent data type) is always pointer- a memory location-

That manifests itself in (lack of) good object-oriented design, too, in a way. Too many C++ programmers focus too much on the type of object something is pointing to, and will do things like add type codes as properties of the objects, and then code up humongous switch-case statements to do something depending on the object type. Proper OOD is to think in