While the value of UNIX is at least questionable, not even adhering to UNIX standards is worse.

C has one considerable advantage over C++ regarding efficiency for the average UNIX programmer: man pages.

One day I started searching for whether someone has fixed this problem. And the search was successful.

Finally I do not have to try to remember the whole STL in detail.

Generic Programming

Admittedly, I don't really know what to write about this topic. Programming is generic by nature: You specify a list of instructions to be applied to abstract input.

Well, "Generic Programming" is in vogue, which is not surprising since it allows for better abstraction. Better abstraction than the average mainstream language provides, that is. "Generic Programming" is nothing more than hacking statically typed languages with a more dynamic approach.

To state the obvious again, here's a tiny example.

// C++ std::max
template <class T> const T& max(const T& a, const T& b)
{
    return b < a ? a : b;
}

"Same algorithm in Smalltalk"
maxOf: a and: b
    b < a ifTrue: [ ^a ] ifFalse: [ ^b ].

"Or, using proper OOP:"
max b
    self < b ifTrue: [ ^self ] ifFalse: [ ^b ].

It is somewhat funny that major languages and/or their compilers have problems implementing features to allow for "Generic Programming" -- and monstrous standards and a complex and inconsistent syntax are problems, too. Languages like Smalltalk support this approach out-of-the-box, programmers use it intuitionally.

Let's just let the term "Generic Programming" die -- it is the most natural form of programming and deserves special treatment only in flawed languages.

C++ vs. logic

Ever declared a destructor pure virtual? Do so and try to compile and link it.

I'll spare you from trying it out. Despite being pure virtual, a destructor has to be implemented anyways.

You can have a pure virtual destructor, but it is not pure virtual. Thank you very much.

SIGSEG

Write a program the Unix way -- C or its bastard offspring C++, no unit testing and lots of sharp pointers -- and what will you get? Segmentation fault.

I think that a segfault is the most common reason for programs to crash -- and the worst approach to achieve memory protection.

The application is killed without been given a chance to recover or even print a description of what went wrong. If a segfault is trapped the application is left in an undefined state. It can try to print a description or do something else, but nobody knows what will happen.

This could have been solved much cleaner and more practical by throwing an exception at the point of failure.