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) depe

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."