OOP doesn\u2019t imply using function pointers.<\/i><\/p>\n
The essence of OOP is polymorphism, which you can achieve in C through function pointers.<\/p>\n
What about just having a plain structure and associate functions to it ? This is OO. In C, it forces you to adopt conventions like prefixing all your function names with the class name,\u2026<\/i><\/p>\n
I assume you\u2019re refering to encapsulation, and I don\u2019t see having to adopt a convention of prefixing your function with a object name (you\u2019re not forced to) is a big deal unless you hunt and peck.<\/p>\n
\u2026and explicitely dereference all the member variables whenever you access them. <\/i><\/p>\n
I assume you\u2019re referring to having to pass in a pointer to structure and then using -> to dereference within a function. I don\u2019t see how that\u2019s a problem.<\/p>\n
What about access rights ? There\u2019s no way in C to forbid access to certain members of a structure. You have to document them in some way, by adding a comment next to the mmbers you consider private. And its not enforced by the compiler, thus errors can creep up. <\/i><\/p>\n
Programmers should be using the public API. having public, protected, and private is no silver bullet.<\/p>\n
Yes, programming using interface is useful, but there are lots of cases where objects with zero runtime overhead, but that implicitely do various housekeeping stuff, are very useful. Or even, classes that are there only to keep your code from getting full of long and messy functions, but amount to nothing at runtime.<\/i><\/p>\n
Interfaces with virtual functions have a runtime cost, and these functions can\u2019t be inlined. They\u2019re not a silver bullet.<\/p>\n
You don\u2019t pay for what you don\u2019t use in C also\u2026unlike Java where you\u2019re relying on the runtime to be smart about all methods being virtual.<\/p>\n
And what about error management anyway ? You have to think of freeing resources everywhere, and C has no mechanism whatsoever to help you to do it. I don\u2019t think it\u2019s much better than an exception system, even if it has not so hard to avoid pitfalls. <\/i><\/p>\n
Exceptions are useful, even though it has been pointed out that C++ exceptions have some major warts.<\/p>\n
I understand your point, but I don\u2019t think it\u2019s really C++ fault. It\u2019s more that since it allow to do these things more easily, it\u2019s tempting to over-complicate stuff. I myself prefer straightforward code where I know what each classes actually do, and not have a vast amount of layers of abstraction if I don\u2019t need them.<\/i><\/p>\n
Yes, you can do everything in C that you do in C++, like object programming and stuff.<\/p>\n
The purpose of C++ isn\u2019t to let you do things that can\u2019t be done in C, it\u2019s to simplify your life. Indeed, it can complicate it instead, but not if used properly.<\/p>\n
Pretty much agree on these points. Shallow hierarchies and favoring composition are the way to go.<\/p>\n
I\u2019ve written lots of C++ code in my lifetime (more than any other language). I think I somewhat grok proper OO. I\u2019ve got Stroustrup\u2019s 3rd edition I\u2019ve got the GOF Design Patterns book, and think patterns are useful.<\/p>\n
I guess my biggest problem with C++ is the syntax, the overcomplification of the language that seems to stem from it\u2019s legacy of needing to be C-backward compatible, can\u2019t stand C++ streams, and think much of the standard library API is bad.<\/p>\n