This is a short of http://www.stroustrup.com/Myths-final.pdf
Myth 1: “To understand C++, you must first learn C”
C is almost a subset of C++, but it is not the best subset to learn first because C lacks the notational
support, the type safety, and the easier-to-use standard library offered by C++ to simplify simple tasks.
Consider a trivial function to compose an email address:
Busted!
Myth 2: “C++ is an Object-Oriented Language”
3. Myth 2: “C++ is an Object-Oriented Language”
C++ supports OOP and other programming styles, but is deliberately not limited to any narrow view
of “Object Oriented.” It supports a synthesis of programming techniques including object-oriented and
generic programming. More often than not, the best solution to a problem involves more than one style
(“paradigm”). By “best,” I mean shortest, most comprehensible, most efficient, most maintainable, etc.
Busted!
Myth 3: “For reliable software, you need Garbage Collection”
In short:
Never use new or delete. Use some classes which does the memory management for you, e.g. std::vector. For short living object, create them on the stack, Instead on the heap with new. Use destructor to clean up memory (and other resources like file handles) if the lifetime of an object comes to an end.
If you have to pass an object around, don't use raw pointer. If it is possible, don't use pointer at all. If there exist only one owner at a time, use the move magic with rvalue reverences. If the object is shared by more than one owner, use std::shared_pointer to store a pointer. It implements a reference counting and deletes the object of nobody owns them anymore. Use auto and make_shared<> for syntactic sugar.
Naked deletes are dangerous – and unnecessary in general/user code. Leave deletes
inside resource management classes, such as string, ostream, thread, unique_ptr, and shared_ptr.
For resource management, I consider garbage collection a last choice, rather than “the solution” or an ideal:
1.Use appropriate abstractions that recursively and implicitly handle their own resources. Prefer such objects to be scoped variables.
2. When you need pointer/reference semantics, use “smart pointers” such as unique_ptr and
shared_ptr to represent ownership.
3. If everything else fails (e.g., because your code is part of a program using a mess of pointers
without a language supported strategy for resource management and error handling), try to
handle non-memory resources “by hand” and plug in a conservative garbage collector to handle
the almost inevitable memory leaks.
Busted!
Myth 4: “For efficiency, you must write low-level code”
I have seen sort run 10 times faster than qsort. How come? The C++ standard-library sort is
clearly at a higher level than qsort as well as more general and flexible. It is type safe and parameterized
over the storage type, element type, and sorting criteria. There isn’t a pointer, cast, size, or a byte in
sight. The C++ standard library STL, of which sort is a part, tries very hard not to throw away information. This makes for excellent inlining and good optimizations.
Generality and high-level code can beat low-level code. It doesn’t always, of course, but the sort/qsort comparison is not an isolated example. Always start out with a higher-level, precise, and type safe version of the solution. Optimize (only) if needed.
Busted!
Myth 5: “C++ is for large, complicated, programs only”
C++ is a big language. The size of its definition is very similar to those of C# and Java. But that does not
imply that you have to know every detail to use it or use every feature directly in every program.
After all, C++ is designed for flexibility and generality, but not every
program has to be a complete library or application framework.
Busted!
Read the paper for detailed examples.
Busted!!