Sure, most of the benefit of OO is in the structure and organization it brings. But no, it's far more than, as you're making it sound, the compiler is passing around an implicit argument on your behalf.
I agree with his point that the difference between OOP-style C and code written in an object-oriented language is language support. I have read some very OOP-style C, and it is extremely centered around chunks of data (objects.) The idea that code should be organized around data structures goes way back. The terminology in this Fred Brooks quote shows how old the idea is:
Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.
In object-oriented C, it is even true that most functions are closely associated with a single structure, as if they are methods, though of course it isn't as cut and dried as it is in languages where that concept is rigidly enforced.
Possibly unrelated, but I've also seen procedural C that is verging on OO, showing an interesting state of evolution: pieces of data are implicitly grouped together, in that they always appear together in function signatures, but not grouped into structures. As a trivial example, if a point had x, y, and z coordinates in space, any function needing one of those coordinates would take all three throughout the entire codebase. Instead of
because points were regarded as aggregates that should be passed around together. This made it much simpler to remember function signatures, and it communicated the intent to treat certain chunks of data as aggregates. (I think this technique was used in Fortran before C even existed.) I imagine that from there it was a very short step to structs.
Almost everything in the history of OO language features has boiled down to support for practices that were first developed and used without language support, often in C. If I remember correctly (remember reading, not being there) people attempted to differentiate between public and private data and methods in C (using macros and/or something similar to the the C++ pimpl trick.)
I agree with his point that the difference between OOP-style C and code written in an object-oriented language is language support. I have read some very OOP-style C, and it is extremely centered around chunks of data (objects.) The idea that code should be organized around data structures goes way back. The terminology in this Fred Brooks quote shows how old the idea is:
Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.
In object-oriented C, it is even true that most functions are closely associated with a single structure, as if they are methods, though of course it isn't as cut and dried as it is in languages where that concept is rigidly enforced.
Possibly unrelated, but I've also seen procedural C that is verging on OO, showing an interesting state of evolution: pieces of data are implicitly grouped together, in that they always appear together in function signatures, but not grouped into structures. As a trivial example, if a point had x, y, and z coordinates in space, any function needing one of those coordinates would take all three throughout the entire codebase. Instead of
you would see because points were regarded as aggregates that should be passed around together. This made it much simpler to remember function signatures, and it communicated the intent to treat certain chunks of data as aggregates. (I think this technique was used in Fortran before C even existed.) I imagine that from there it was a very short step to structs.Almost everything in the history of OO language features has boiled down to support for practices that were first developed and used without language support, often in C. If I remember correctly (remember reading, not being there) people attempted to differentiate between public and private data and methods in C (using macros and/or something similar to the the C++ pimpl trick.)