[pubby]

The reason this guy thinks std::list is buggy is because he's using it incorrectly. There's not reason to write removal functions like delete_person when they already exist with list::remove, list::erase, find, search, etc. There's no reason to use std::list<foo*> either when std::list<foo> and std::list<std::unique_ptr<foo>> work just as well.

His example code is very dubious as it looks like C-with-classes rather than C++, mostly due to the lack of RAII.

Intrusive lists are still worth knowing and using, it's just that the author's reasoning was terrible. I found the Boost.Intrusive page to be much more knowledgeable: http://www.boost.org/doc/libs/1_35_0/doc/html/intrusive/intr...

[jemfinch]

The reason you think this guy is using std::list incorrectly is because you're not thinking about his requirements. Instead of spending a few seconds to understand why he would keep a std::list<foo* >, you immediately ran back to HN to make a comment about it.

He's a game programmer. He's keeping pointers to instances because these entities are part of an inheritance hierarchy[0]. That level of indirection is essential to his problem and completely unavoidable. On the other hand, std::list<std::unique_ptr<foo>> wouldn't change anything at all about the particularly inefficient memory arrangement of std::list<foo* >; std::unique_ptr is, after all, just a class with one pointer member.

When smart people write things you think are obviously dumb, you should invest some additional time trying to understand the context of their statements before writing them off. You'll learn more, and you won't come off as a flippant junior developer.

[0] http://www.codeofhonor.com/blog/tough-times-on-the-road-to-s...

[pubby]

> The reason you think this guy is using std::list incorrectly is because you're not thinking about his requirements.

The reasoning and requirements for him using intrusive lists was quite clear to me. The remaining article that starts at "Using intrusive lists" I found quite interesting and insightful.

My entire argument is against his evidence backing up statements like, "If you’re a programmer who uses the C++ STL std::list, you’re doing it wrong." It's unfair to improperly use std::list, compare it to a better solution, and then make a sweeping generalization. That's just outrageous.

[jemfinch]

It's clear from the subtitle of the blog ("Game design, game programming, deployment automation and more"), the title of the specific blog post, ("Avoiding game crashes related to linked lists"), and the very next paragraph of your quotation ("Based on watching the successes and failures of programmers writing games like Starcraft and Guild Wars...") that the author is talking about a very specific technique applied to a very specific sort of programming, and yet you're still complaining that he is making "a sweeping generalization"?

Stop wasting your time and ours arguing about an interpretation of his words the author never intended. Such literalistic argument-making serves only to mislead and misdirect, and it contributes nothing to the conversation.

[pubby]

Shot him a quick email for clarification:

> "Is "std::list considered harmful" in the general field of C++ or are you only talking about the very specific game programming field you used it for?"

> "I think it's harmful for all programming, but if you read the comments you'll find almost as many different opinions on the subject as comments!

The problem is that manually managing lists is error-prone, which is why I use a solution that automatically handles them; I think all programs, not just games, would benefit from their use."

[jd]

I don't think it's fair to say the author's reasoning is terrible. A blogpost is always written for some specific audience, and in this case it looks like the blog post was targeted at programmers generally, not C++ experts. I agree that constructs like std::some_container<T*> are almost never the optimal solution. And yes, with RAII locks can be freed in the destructor, which rules out a class of mistakes.

The main things to take away from the blogpost were, I think, the concept of intrusive lists, to think about what objects look like in memory, and how you can construct code so that an object can be part of multiple containers and can remove itself from all of them when it's destroyed. Those are certainly concepts worth talking about, and so I think the blogpost was pretty great.

[gsg]

If you read the article with more sympathy, you will notice that he is using RAII, I think rather cleverly, to automate removal of an object from the intrusive lists contained within it. This is a interesting improvement over the venerable list.h style approach most C programmers take.

As for std::list... it's useless.

[SeanDav]

If you bothered doing a bit of research rather than jumping on some sort of bandwagon you would have realized:

- "this guy" is actually a highly experienced and competent programmer.

- He programs games, with often very specific domain requirements and challenges. Try to understand context before making sweeping generalizations.

[pubby]

Where did I make a sweeping generalization? I definitely where the author made some!

[bradleyjg]

This article is one in a series dealing with problems that arose out of programming Starcraft in the mid-90s. There was no unique_ptr back then, and it was rare to find even junior programmers that were native c++'ers.

[pubby]

Actually this seems to be from Guild Wars which was from 2005. IIRC when he talked about Starcraft developement the team just used pointer structs with no abstractions.