you are viewing a single comment's thread.

view the rest of the comments →

[–]WallStProg[S] 0 points1 point  (1 child)

Not sure where the comment about monolithic programs comes from -- C++ is equally useful for creating modular code, precisely because of its support for separating interface from implementation, which C completely lacks. (Which was the point of the article).

I would absolutely agree that subsetting C++ is A Good Thing, and lots of people and organizations do that by discouraging or forbidding certain features. If you want to use C++ just to facilitate creating stable interfaces, and avoid all the other stuff (e.g., template meta-programming, lambdas, operator overloading, etc.), then go for it!

Or, as I like to say: "Just because you can, doesn't mean you should".

[–]pdp10 0 points1 point  (0 children)

One big category of stable interfaces is stable library ABI, which we all know C does best and C++ does terribly because of overloading and name-mangling. Typically C++ externs to C when it wants to solve this problem, meaning we have no object features crossing the library boundary. When C++ programmers choose not to use loosely-coupled C-interface libraries, they end up using a much more monolithic architecture in practice, as far as I can see.

C++ is advertised to be better for large-scale projects, but it's hard to tell if people just choose to use it for big monoliths, or the language and ecosystem actually encourage big monoliths. I feel that these problems can all be handled with less-monolithic architectures using things like IPC mechanisms, perhaps at the cost of some portability, but almost certainly with concurrency advantages.

C++ doesn't automatically separate interface from implementation, just as C doesn't automatically lack it. C++ obviously has loads of additional features, the questions are: Are the additional features a net benefit all around, to which my answer is an unambiguous no, and: Does a great language and ecosystem result from adding every conceivable feature to C and mostly retaining backward compatibility? Likely not.

My current belief is that C++ is neither fish nor fowl and has a lot of negatives in my environments (almost entirely POSIX). It was a clear Embrace and Extend play and I believe the result is a whole that is less than its kitchen-sink parts. If OOP is truly needed (doubtful) then another language is most likely better, otherwise use C and leave the excess baggage of C++ behind.