I work with C++ on embedded computer vision systems, and we mostly build our own low-level image processing libraries. Elements of this philosophy are quite popular in our company in building libraries, i.e. code meant to be reused between projects. The only item that stands out is the following:
Don't use C++ runtime wrapper for C runtime includes (<cstdio>, <cmath>, etc.), use C runtime instead (<stdio.h>, <math.h>, etc.)
I don't have any idea why it may be useful.
Since we often deal with scientific image processing, there's a heavy use of templates, but no “esoteric” metaprogramming, and it does not contradict this “orthodox” manifesto.
On the system design side, we mostly compose our systems out of rather heavy objects encapsulating separate testable subsystems. These objects exclusively use smart pointers and often exceptions and can use RTTI if it somehow aids postmortem analysis (e.g. including type_info in exceptions). Also, multi-threading also lives here, and it is usually heavily-modern-C++-flavored Intel TBB and/or simple message queues.
On the whole, it is Java-like on the top level, C-like on the bottom, templates at the basement, and whatever language helps best to stabilize the whole structure.
ADD: Overall, these “orthodox” qualities have significant effect on whether the library should be accepted by us in a serious project. I.e. mostly for this reason OpenCV use is mostly limited to prototypes and auxiliary software. However, Eigen and TBB are the exceptions, since they provide great features while being very well maintained with respect to reliability and compatibility.
Don't use C++ runtime wrapper for C runtime includes (<cstdio>, <cmath>, etc.), use C runtime instead (<stdio.h>, <math.h>, etc.)
I don't have any idea why it may be useful.
Since we often deal with scientific image processing, there's a heavy use of templates, but no “esoteric” metaprogramming, and it does not contradict this “orthodox” manifesto.
On the system design side, we mostly compose our systems out of rather heavy objects encapsulating separate testable subsystems. These objects exclusively use smart pointers and often exceptions and can use RTTI if it somehow aids postmortem analysis (e.g. including type_info in exceptions). Also, multi-threading also lives here, and it is usually heavily-modern-C++-flavored Intel TBB and/or simple message queues.
On the whole, it is Java-like on the top level, C-like on the bottom, templates at the basement, and whatever language helps best to stabilize the whole structure.
ADD: Overall, these “orthodox” qualities have significant effect on whether the library should be accepted by us in a serious project. I.e. mostly for this reason OpenCV use is mostly limited to prototypes and auxiliary software. However, Eigen and TBB are the exceptions, since they provide great features while being very well maintained with respect to reliability and compatibility.