4 ms·

I've always felt that object-oriented programming as a concept (that is, define structures and then define functions to operate on them together) is useful: obj

I've always felt that object-oriented programming as a concept (that is, define structures and then define functions to operate on them together) is useful: object-oriented programming as a language design is not. Once you understand what encapsulation, inheritance and polymorphism are, you're much better off using them as guidance to structure your program in an otherwise procedural language like C than wrestling with a few dozen new keywords and an opaque specification.

acqq 7y ago
I use C++ for decades, but I used it always for the projects that were supposed to last long. With that limitation, I've constantly avoided two things: 1) dependence on external C++ libraries, especially boost. 2) trying to always have the code using the latest changes in the standard proposals or the standards. With these two limitations, and a lot of additional internal "practices" it's possible to maintain a long-running C++ project without doing what I consider "wrong" stuff. Note: I grew up on assembly, so I was always biased by considering what the optimal code should be as presented to the CPU, after the compilation. The smaller the project and the environment around the project is, these my preferences could be relaxed. There are surely use cases where "anything could go." But then, the question is always, why not something "more convenient" than both C and C++? But now I also almost think that if I would be forced to reduce these my "hard projects" "rules and practices" to a minimum number of words, I would probably state it "only C allowed."
StillBored 7y ago
Well, using C++ as a C with objects has always been a choice. One I personally believe in. That means you basically write a C program, then when it makes sense you create c++ classes/templates as needed. At first this sounds like the C++ features are infrequently used, but the last major project I wrote like this, probably 90% of the code was encapsulated. But there was very little class->class communication outside of a few global classes due to the use of a dbus like abstraction allowing all the individual classes to communicate out of band. (sort of like a collection of micro services if you will all running in the same process as different threads using a global message broker).
Koshkin 7y ago
C++ is a multi-paradigm language, and programming in it does not force you into the object orientation. Sure, there is a lot of encapsulation going on in the standard library, but it does not mean that you have to follow the same approach in code you write (although I find that it is the ability to specify destructors that separates C++ from the plain old C, and you cannot do that if you do not write classes).
augustk 7y ago
> I've always felt that object-oriented programming as a concept (that is, define structures and then define functions to operate on them together) is useful: object-oriented programming as a language design is not. What you describe here are abstract data types. Unless it involves inheritance and/or dynamic binding I wouldn't call it object-oriented programming.

acqq 7y ago

I use C++ for decades, but I used it always for the projects that were supposed to last long. With that limitation, I've constantly avoided two things: 1) dependence on external C++ libraries, especially boost. 2) trying to always have the code using the latest changes in the standard proposals or the standards. With these two limitations, and a lot of additional internal "practices" it's possible to maintain a long-running C++ project without doing what I consider "wrong" stuff. Note: I grew up on assembly, so I was always biased by considering what the optimal code should be as presented to the CPU, after the compilation. The smaller the project and the environment around the project is, these my preferences could be relaxed. There are surely use cases where "anything could go." But then, the question is always, why not something "more convenient" than both C and C++? But now I also almost think that if I would be forced to reduce these my "hard projects" "rules and practices" to a minimum number of words, I would probably state it "only C allowed."

StillBored 7y ago

Well, using C++ as a C with objects has always been a choice. One I personally believe in. That means you basically write a C program, then when it makes sense you create c++ classes/templates as needed. At first this sounds like the C++ features are infrequently used, but the last major project I wrote like this, probably 90% of the code was encapsulated. But there was very little class->class communication outside of a few global classes due to the use of a dbus like abstraction allowing all the individual classes to communicate out of band. (sort of like a collection of micro services if you will all running in the same process as different threads using a global message broker).

Koshkin 7y ago

C++ is a multi-paradigm language, and programming in it does not force you into the object orientation. Sure, there is a lot of encapsulation going on in the standard library, but it does not mean that you have to follow the same approach in code you write (although I find that it is the ability to specify destructors that separates C++ from the plain old C, and you cannot do that if you do not write classes).

augustk 7y ago

> I've always felt that object-oriented programming as a concept (that is, define structures and then define functions to operate on them together) is useful: object-oriented programming as a language design is not. What you describe here are abstract data types. Unless it involves inheritance and/or dynamic binding I wouldn't call it object-oriented programming.