100% agree. It almost feels insulting to say that C++ programmer will only use std::list and a C programmer will only use a hand made doubly linked list. This almost feels like an interview question: > Which is faster and uses less memory? A generic double linked list or a hand made double linked list?

This is a data structure, optimization, software development problem. The reason we use any 3rd party generic (in C OR C++) doubly linked list is because it helps code the problem faster. Any time you use a component you need to be aware of its overhead. After profiling my C++ code if I found that the std::list was taking up all my memory and all my cpu time I would then evaluate the algorithms I am using and pick the data structure that best fits that be that a custom link list or something else such as the above mentioned boost library.

You even have to nitpick the example about erase being expensive. When using std::list why isn't the code passing around the iterators rather than the person object? And for the memory of std::list overhead why didn't he use std::list<person>?

There is no problem using a hand made C style doubly link list in your C++ code for the core part of your application for performance reasons. Being a C++ program doesn't mean you can't use C style code or even have asm snippets. Following the same logic as the blog ZeroMQ should have been written in ASM and not C because it could have been faster, or the reverse it should have been written in Ruby because it would have been coded in a quarter of the time (but at the trade of slower runtime)

As for the conclusion I would say that the inefficiency is still in ZeroMQ code as the author doesn't fully understand C++.

Why not pass iterators? Consider the case where the object is contained in two lists. You would have to pass a pair of iterators. What if it is in 3 lists? Etc.

Agreed, but for the example the object only needs to live in one list (as shown by the fact that it could have been a C struct that contained the next/prev pointers) so passing iterator would have been sufficient and would have solved the O(n) problem(s?) he was having.

Exactly, the C example could not be contained in more than one list at a time, so if this is a concern, the C solution wouldn't work either.

Yup. It's possible to do that. My point was that if you want to do that you break the encapsulation, i.e. contained object would have to know about its container(s). This applies to Boost intrusive lists as well AFAICS.

Which is entirely true, and is often the case when performance is a goal - abstractions must be broken. But that is not an argument for or against C++.

I've given an example of the language extension that would solve the problem at the end of the article.

C++ already allows such a thing using the "curiously recurring template pattern" (http://en.wikipedia.org/wiki/Curiously_recurring_template_pa...), often now called "mixins":

  class person
  {
  protected:
      int age;
      int wieght;
  };

  template <class Base>
  class people: public Base
  {
  private:
      Base *prev;
      Base *next;
  };

  people<person> plist;

Your language extension sounds a lot like the friend keyword.

That's what I thought at first, but friend is for when you want class A to be able to view private things of class B. That is, B needs to know ahead of time what A is interested in. He wants B to remain ignorant of what A wants - he wants A to be able to insert new fields into B. But we can accomplish the same thing with mixins.