4 ms·

Point taken on how for_each works for linked lists. I'm (obviously) not a C++ expert and it shows in that context. I suppose the thrust of my opinion is that a

Point taken on how for_each works for linked lists. I'm (obviously) not a C++ expert and it shows in that context. I suppose the thrust of my opinion is that a lot of code depends on the fact that it iterates over a linked list, which is safe in many contexts. The idea that callers could substitute container types which break its assumptions seems unwelcome to me. Nobody provides the wrong fields to list_for_each_entry because they get very nasty compiler errors if they try. But anybody can plug a new container type into a for each statement and get new behavior that silently breaks the assumptions of the original code. I suppose that could be protected by a better type system though. There's a lot to improve on C even for kernel dev, and "C is greatest" isn't a hill I'm willing to die on :)

kllrnohj 5y ago
> But anybody can plug a new container type into a for each statement and get new behavior that silently breaks the assumptions of the original code. How would it be "silent"? You're changing the container at the point where you're making any assumptions about it. This would just fall under normal code review purview, just like code reviews are how Linux enforces that anyone even used this linked list macro in the first place. C certainly doesn't care if you use list_for_each_entry for your container iteration, after all. But it'd be a lot easier to replace these linked lists with a vector that has the same observable contract if C++ was used, just would be way faster to iterate on.