Matt Bond wrote:

use good architecture/inheritance/coding concepts (DRY, SOLID, encapsulation, etc.),

Except that all of these things can be done to excess. Too often I've waded through ponderous codebases that have unnecessary levels of abstraction, or encapsulation (getter and setter provided for the same attribute - why not just make the attribute public). I think these things have a U curve of complexity/cost tradeoff - some of these things are useful/necessary, but more of a good thing, is not necessarily a good thing.

Matt Bond wrote:

Keep all things as simple as possible, but no simpler. -said someone, somewhere

Exactly

It failed because on my virtual classes i had functions like getc and putc. Shouldn't be a problem, right? Wrong. Because somebody decided to take every C library function and wrap it with a macro, such that getc was #define getc __getc or some garbage like that. max and min are like that. My code is peppered with #undef max #undef min just because a certain OS platform decided to define these as macros.

Actually, I often do. A classic example is defining an Iterator class for a container type. It makes more sense to have the Iterator class definition be part of the container class definition (and hence called MyVector::Iterator, for example, than to create a separate MyVectorIterator, and typedef the Iterator type in MyVector. Another example is a Pimpl pattern, although in this case the embedded class is just a declaration on the public interface, and the actual definition is in the implementation file.

In one place I worked, the error message "member not found" was display to one of the (male) PHBs. The story of the PHB's member having gone missing went around like wildfire.

I have no problem with the independent subsystems being mocked. There are relatively few of these. In examples I've seen, every single class implements an interface, and every interacting class is mocked, leading to triple the number of classes, and a nightmare to read and/or debug the code. Way too much! Re friendship violating Liskov, then so much the worse for Liskov. Friendship has its place and uses, but shouldn't be overused - just like global variables, mutable members and dependency injection.

Quite easily. Options include: 1. Black box testing - test the assembled class with its dependencies, based on whatever attributes are publicly visible. 90% of the time this is all that is needed. 2. White box testing - test the assembled class with its dependencies, but also declare internal state as protected, and have the test fixture inherit from the class being tested. 3. White box testing - instead of declaring the internal attributes protected, declare an internal class Test and make it friends with the class being tested. The actual implementation of the test class can be deferred to the unit test code. All of the above I have used in a unit testing environment, and are way simpler to understand, debug and otherwise maintain than dependency injected/mocked code. The only time mocking is really needed is when it is impractical to instantiate the dependency in the CI environment. Examples might include a full database, or something that depends on network resources.

The compiler takes care of calling the correct overload. I really don't understand the problem. Pros of the generic solution: - no virtual function overhead Con: - the interface contract is more implicit Other than that, both approaches are about equally as complex and difficult to debug. Better if mocking is not used unless necessary.

Why? How difficult is it to adopt the old semantics of a given dependency, and shim a a new replacement library when it becomes necessary to jump ship. I have done this a few times, though not often. Seems like deferring the pain ('YAGNI') until it becomes necessary is optimal overall.

"because you can't write a unit test with a mocked dependency without using this paradigm." An alternative is to use generic programming aka "static polymorphism", and inject dependencies via template parameters. No need for interfaces. Not saying this is a good choice, but it is certainly a choice.

DI is only really useful for mocking. Not everything needs to be mocked. Just use the real classes and test the ensemble, and only mock things that are heavy (eg the database).

Hell no! If you must put the second conditional for documentation purposes, make it a comment if (cond) ... else // if (!cond) ... or if (cond) ... else // cond ... I've seen that style used for conditional compilation, not so much for braces. #if cond ... #else ... #endif //cond

It's not a matter of garbage collection. Java, C# and even Python have finalisers that support adding code that is executed when an object is reaped by the GC. This becomes essential when providing a C++ implementation of an object in the target language (say via Emscripten) to arrange for the C++ destructor to be called when the owning object is destroyed by the garbage collector. Lack of finalisers mean the C++ implementation is limited to PODs (plain ordinary data types), whcih is pretty damn limiting.

Big one for me - lack of destructors or finalisers.

Actually, if g(p) returns void, then this is definitely allowed. Makes generic programming easier, with less boilerplate, and faster compilation. Not sure what is supposed to happen if g(p) is something other than void - it should really be a syntax error.

I use dolphin, which come preinstalled on my OpenSUSE distro. Works a treat on Android phones - iPhones are still the regular PITA they've always been.

Funny story - there was a time about 4 years ago when our internet suddenly went to shit - as in sometimes it was fine, other times it was totally unusable. This went on for a week, until I noticed that the rubbish performance started just after my son woke up in the morning. Then it occurred to me that the start of the troubles coincided with a new laptop he'd bought. So then I took a look, and I realised that the Windows installed on that system was set up to upload the contents of the user home directory to the new fangled "One Drive" system, supposedly for backup purposes. Of course, my son had around 30GB of gaming data stored in that directory, and we were still on ADSL at the time (A standing for asymmetric, upload speeds being a paltry 100kbps or so), so this was going to take a month of Sundays, and of course ultimately fail, because MS is not generous enough to hand out multi GB of data for free. I had to google the shit out of that problem to find out how to disable this on his system.

Oscilloscope for checking for faulty power supplies is a good idea - I ended up buying a cheap second hand one for exactly this purpose. A big alternative is a bin of spare parts. You can quite quickly isolate a faulty component if you can swap out components that are hopefully themselves good. Trouble is most people, even if they have multiple computers like me, the machines span different hardware generations, each of which have incompatible connectors between CPUs, memory modules, draw different amounts of power etc.

Maybe they're using emacs! Not joking, by the way.

Rick York wrote:

Use of literal values annoys me a lot. Especially when that hard-coded value needs to be changed.

Only if the literal value is a parameter that can potentially have different values. Too often I've seen things that are as silly as static const int two=2; static const string emptyString=""; or maybe static const string fooBar="fooBar"; So there are limits to when replacing hard coded values by identifiers is a good idea.

That explains why I've had unalloyed success with Windows 10 - I run it on a virtual machine on a Linux host.