- Lists can be treated as a separate abstract data type. As long as the client code (e.g., the code that works on my_entry above) respects this data abstraction, there is no encapsulation problem. (Programmers who cannot maintain this discipline should not be programming in C.)
- You eliminate code duplication (currently, you have to write the pointer manipulation code for each kind of object that might be on a list).
- You can change the type of list without having to change the client code (except to change the type of node).

Of course the my_entry code has to know about where its representative list_nodes are, so it's still intrusive in that sense, but that's okay.

This polymorphic linked structure trick is a standard C programming idiom (though known to distressingly few C programmers), and good programming practice.

First, I'm not sure what you mean by bad at resizing. What particularly about it is bad?

Re vector vs list, cache misses are a drastically significantly more important performance impact than anything else these days & you're guaranteed them when using a list unless you do lots of jumping through hoops to allocate everything in a contiguous array (but then why not vector?).

I highly recommend you watch http://channel9.msdn.com/Events/Build/2014/2-661 (the performance stuff starts roughly around the 20 minute mark) & is language agnostic (true for C++/C/Java, etc).

Additionally, in C++11, if you declare your move constructors noexcept (or use the default one or omit destructor, move/copy contructors & move/copy assignment operators), then resizes of vectors can be much faster (if the move constructor is faster than the copy one) since the container doesn't need to copy your objects, it'll just move them.

C++11 lets you also express your non-assignable types without resorting to pointers by declaring the type to be move only (thus Person can live on the stack or moved to live in the heap):

 class Person { public: ~Person(); Person(const Person& o) = delete; Person(Person&& o) noexcept : // initialize member variables with the resources from o { // modify o so that it no longer owns any resources // but leave it in a destructible state } Person& operator=(const Person&) = delete; Person& operator=(Person&& o) noexcept { Person tmp(std::move(o)); swap(*this, tmp); return *this; } private: friend void swap(Person&p1, Person& p2) noexcept; }; 

 class Person { public: Person(); // don't specify destructor or move/copy constructors/assignment operators // & this type is implicitly move-only due to _data being move-only, it's exception-safe // & everything is automatically annotated noexcept for you private: std::unique_ptr<PersonData> _data; }; 

It will not protect against all conditions, especially not a memory leak in another running process, but it could keep things going long enough to print dire warnings to the console, stderr, etc, and optimistically, allow your app to survive long enough to realloc() to restore the size of the "spare" memory pool.

What it will do is give you something useful to do to recover from malloc() when it returns a null - namely realloc() "spare" to something smaller to free up the memory you need. Hopefully.

Conclusion… never use std::list. But to go as backwards as to use C… I think it's taking it a bit far.

The solution given in the aforementioned article is to use so called "expression templates" which wrap the parts of the expression and solve the order of operations in the compile time, reordering them in a way that the compiler can then optimize it further. This compiles to the code which could be hand-crafted by a C programmer, but it requires a real mess of templates to emulate in C++ what I'd call "lazy-evaluated expressions". So it requires a lot of jumping through hoops to hack one's way around the encapsulation and to make the code efficient again, as it would be in C (but retain the type-safety of C++, which cannot be done in C, you need to admit). And I wonder, too, if this is really a flaw of OOP or just its implementation in C++.

Using list I get 24 bytes. I'm not sure where the extra few bytes comes from but that may be solved using a different implementation. Templates/oops doesn't cause extra allocations http://ideone.com/qGp2Am

Anyway, I am all for computing as much as possible in compile-time, however, there always remain couple of pesky little things that must be computed in run-time ;)

If by stressing the multi-paradigm character of C++ you mean that I should write plain old C and compile it with C++ compiler, sure, but then there's this pesky little dependence on libstc++ which gets pretty annoying, especially on embedded platforms.

Please mind that I am not against OO paradigm itself. The idea that people tend to think in terms of objects rather than functions is a profound insight, maybe the deepest one made in the history of programming languages. The problem is that the abstract notion of "object" is in reality downgraded to a simple "continuous chunk of memory" concept. While that works OK in most cases, there are cases where the abstraction leaks. For example: intrusive containers. Here a single chunk of data is split between two objects (container & the item). Another example: state machines. People tend to think about states as objects (they have well specified behaviours, each has a set of methods (events) etc. However, all the states in the state machine share the same data. Yuck!

So, I guess, the question is rather whether OO paradigm can be extended to take account of these cases.

Btw, given that you seem interested in various techniques to make things work in C++, have you ever come over some neat trick to implement state machines?

Here is your problem - you are trying to fit round peg into square hole. Despite of what you might have learned, and practised, C++ is not a "object oriented programming language"; from the horse's mouth www.stroustrup.com (slash) oopsla.pdf . It is a multiparadigm programming language. It supports concepts such as decoupling, reusability and interfaces via many different means of which OOP is just one. E.g. standard template library depends on implicit interfaces without inheritance (you know what "begin()" and "end()" do, without having to rely on hypothetical IContainer class), reusability in procedural style works surprisingly well in connection with templates, defining implementation detail classes in a implementation files rather than in headers does decoupling pretty well, selection of code execution paths based on non-type template parameters often gives better results than inheritance etc.

Never mind, you are an old dog now, it would be silly of me to try to teach you new tricks. Just say one thing: I used C++ some 20 years and almost gave up 10 years ago because OOP felt too limiting and clumsy (I've been programming in Lisp before). Then I read "Exceptional C++" series from Herb Sutter and this opened my eyes - there are more tools in C++ tool chest than in any other language, but somehow I've missed large proportion of those!

My conclusion after passing the whole way is that C++ is for rapid development, not for system-level code.

The fundamental problem, I believe, is that not all the problems align nicely with object-oriented model (e.g. state machines, rigorous error handling, low-level optimisation etc.) Of course, you can *not* use OO model in C++, but the it just looks silly. C, on the other hand, being so basic and low-level aligns well with any paradigm you can think of. And, of course, writing OO code in C is easy.

Btw, some interesting research was done in PARC. "Aspect oriented programming" — an attempt to capture various aspects of a program (e.g. object model, failure model, state machines) using different languages and then compose the partial descriptions of the system into a single executable. It's tricky though. However smart the guys in PARC were I think the problem was just too hard in this case.