C++ for dinosaurs
C++ for dinosaurs
Guide for readable, maintainable, reusable and faster code
About the Book
There are certain programming habits that tend to produce unreadable and low-performance code. These habits are inherited from dated code, or passed on from trainer to trainee.
Readability should be the prime aspect of your code, because it has the highest return on effort, compared to other techniques which aim to improve your product's quality.
- Quality: Bugs are found mostly by reviewing other people's code. You can't review somebody else's code if you cannot read it. Bugs are not found by unit-tests, because unit-tests are created to capture errors that we know they exist in the code. Unit-tests only catch bugs that have been re-introduced.
- Efficiency: Maintenance takes about 80% of developers' time. Therefore, spending some time for writing better code will save you up a lot of time when you have to maintain it.
- Performance: Unreadable code is difficult to reason about. Therefore any opportunities for optimisation that may exist are often impossible to notice and fix.
I describe six basic techniques that you can follow in order to eliminate these habits. These techniques can be learned one at a time, improving your coding level progressively. At the end, you will have developed a programming style that
- is more readable,
- leads to more maintainable code,
- promotes reusability, and
- often leads to faster code.
All these qualities are not mutually exclusive, you will often achieve all of them at the same time.
The techniques are easy and therefore
- students can apply them
- it helps smooth transition from C to C++, without having to change programming paradigm
- it allows C++ programmers to write using native idioms, instead of writing like C, Java, or Fortran.
C++ for dinosaurs is also available as a printed book at lulu.com.
About the Author
Table of Contents
-
Preface
-
- Who is this book for
- How to read this book
- Why this book was written
- Acknowledgements:
-
-
Discussion
-
1 Understanding why a style change is needed
- 1.1 Elements of wasteful programming style
- 1.2 Why is C++ a better choice than C for most cases ?
- 1.3 Why people don’t switch to C++ ?
- 1.4 Object oriented approach critique
-
2 Steps for embracing a better coding style
- 2.1 Step 1: Use readable syntax for function arguments
- 2.2 Step 2: Use the STL containers
- 2.3 Step 3: Do not write raw for-loops
- 2.4 Step 4: Algorithms should read like pseudocode
- 2.5 Step 5: Make use of the roll/unroll behaviour
- 2.6 Step 6: Revamp your callback methods
-
3 Efficiency advantages using STL and C++
- 3.1 Templates are faster than macros
- 3.2 Efficiency of std::string vs char*
- 3.3 Order of complexity does not reflect performance
- 3.4 Old speed issues that don’t exist anymore
- 3.5 map vs unordered_map
-
4 Am I doing it right ?
- 4.1 bind-mania
- 4.2 loving low-level data structures
- 4.3 for_each everywhere
- 4.4 replicating STL algorithms
-
1 Understanding why a style change is needed
-
Learning the details
-
5 Expressing intent using STL algorithms
- 5.1 Customising algorithms with comparators
- 5.2 Customising algorithms with predicates
- 5.3 Copying algorithms
- 5.4 How are algorithms implemented ?
- 5.5 What is the fastest way to learn STL algorithms ?
-
6 Callable Objects
- 6.1 Using functions as callable objects
- 6.2 Using function objects as callable objects
-
6.3 Using
std::bind()to create callable objects - 6.4 Lambda functions as callable objects
- 6.5 When to use each type callable functions:
-
6.6
std::bindby example
-
7 Avoid using low-level strings
- 7.1 Problem description
- 7.2 The solution
-
8 Understanding cache issues
- 8.1 Running costs of a program
- 8.2 Data access costs
- 8.3 Costs depending on data structures
- 8.4 Instruction Pipeline
- 8.5 Side-stories
-
9 Converting a .c module into a .cpp
- 9.1 Ensure header is readable by C++
- 9.2 Mark external functions as extern “C”
- 9.3 Replace implicit casts from void *
-
9.4 Replace
<math.h>with<cmath>
- 10 References
-
5 Expressing intent using STL algorithms
About the Publisher
This book is published on Leanpub by Nick Economidis
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.
You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!
So, there's no reason not to click the Add to Cart button, is there?
See full terms...
80% Royalties. Earn $16 on a $20 book.
We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
